Con la creciente popularidad de RGB++ y la emisión de activos relacionados, las discusiones sobre los principios de los protocolos RGB y RGB++ se han convertido gradualmente en un tema de interés para más personas. Sin embargo, se ha comprendido que para entender RGB++, primero se debe comprender el protocolo RGB. El protocolo RGB original tiene una estructura algo técnica, con materiales de referencia dispersos, y hasta la fecha no ha habido mucho material de referencia sistemático y fácil de entender. Geek Web3 ha publicado anteriormente dos interpretaciones sistemáticas de RGB y RGB++ (disponibles en el historial de nuestra cuenta pública), pero según la retroalimentación de la comunidad, estos artículos eran extensos y demasiado complejos. Con el fin de permitir que más personas comprendan rápidamente los protocolos RGB y RGB++, el autor de este artículo completó apresuradamente una breve interpretación en lenguaje sencillo de RGB y RGB++ durante un evento en Hong Kong. Se puede leer en solo unos minutos, con el objetivo de ayudar a más entusiastas de la comunidad a comprender mejor y de manera más intuitiva RGB y RGB++.

Protocolo RGB: los usuarios necesitan verificar personalmente los datos

El Protocolo RGB es un tipo especial de protocolo de activos P2P, que opera bajo el sistema computacional de la cadena Bitcoin. En cierto modo, es similar a los canales de pago: Los usuarios necesitan ejecutar su cliente personalmente y verificar las acciones de transferencia relacionadas consigo mismos ("Verificar por ti mismo"). Incluso si solo eres un receptor de activos, primero debes confirmar que la declaración de transferencia del remitente es correcta antes de que la transferencia pueda tener efecto. Este enfoque, conocido como "transferencia interactiva", es notablemente diferente de los métodos tradicionales de transferencia y recepción de activos. ¿Por qué es necesario esto? La razón es que el protocolo RGB, para salvaguardar la privacidad, no utiliza el "protocolo de consenso" que se encuentra en blockchains tradicionales como Bitcoin y Ethereum (donde los datos, una vez en el protocolo de consenso, son observados por casi todos los nodos en la red, lo que hace que la privacidad sea difícil de proteger). Sin un proceso de consenso que involucre a un gran número de nodos, ¿cómo se pueden asegurar los cambios de activos para que sean seguros? Aquí es donde entra la idea de "verificación del cliente" ("Verificar por ti mismo"). Debes ejecutar tu cliente y verificar personalmente los cambios de activos relacionados contigo.

Por ejemplo, consideremos a un usuario RGB llamado Bob que conoce a Alice. Alice quiere transferir 100 tokens TEST a Bob. Después de generar la información de transferencia "Alice a Bob", Alice envía la información de transferencia y los datos de activos relacionados a Bob para que él los verifique personalmente. Solo cuando Bob confirma que todo es correcto, la transferencia procede a convertirse en una transferencia RGB válida. Por lo tanto, el protocolo RGB requiere que los usuarios verifiquen la validez de los datos por sí mismos, reemplazando los algoritmos de consenso tradicionales. Sin embargo, sin consenso, los datos recibidos y almacenados por diferentes clientes RGB son inconsistentes. Todo el mundo solo almacena datos de activos relevantes para ellos mismos localmente y no conoce el estado de los activos de los demás. Si bien esto protege la privacidad, también crea "islas de datos". Si alguien afirma tener 1 millón de tokens TEST y quiere transferirte 100.000, ¿cómo confías en ellos? En la red RGB, si alguien quiere transferirle activos, primero debe proporcionar una prueba de activos, rastreando el historial de activos desde la emisión inicial hasta las múltiples transferencias, asegurándose de que los tokens que desea transferirle sean legítimos. Es como cuando recibes billetes inexplicables, le pides al remitente que explique la historia de estos billetes, si fueron emitidos por el emisor designado, para evitar la falsificación de dinero.

(Fuente de la imagen: Coinex)

El proceso anterior ocurre bajo la cadena de Bitcoin, y estos pasos por sí solos no establecen una conexión directa entre RGB y la red de Bitcoin. Para abordar esto, el protocolo RGB emplea el concepto de "sellos de un solo uso," que vinculan los activos RGB a UTXOs (Salidas de Transacción No Gastadas) en la cadena de Bitcoin. Mientras la UTXO de Bitcoin no sea gastada dos veces, los activos RGB vinculados no estarán sujetos a pagos dobles, aprovechando así la red de Bitcoin para prevenir la "Reorganización" de activos RGB. Por supuesto, esto requiere la publicación de Compromisos en la cadena de Bitcoin y el uso del opcode OP_Return.

Veamos el flujo de trabajo del protocolo RGB:

1. Los activos RGB están vinculados a los UTXO de Bitcoin, y Bob posee ciertos UTXO de Bitcoin. Alice quiere transferir 100 tokens a Bob. Antes de recibir los activos, Bob informa a Alice qué UTXO de Bitcoin suyo debería usarse para vincular estos activos RGB.

(Fuente de la imagen: Geekweb3/GeekWeb3)

1. Alice construye los datos de transacción para la transferencia de activos RGB "Alice a Bob", junto con la historia de estos activos, y se lo da a Bob para su verificación.
2. Después de que Bob confirma que los datos son correctos localmente, envía un recibo a Alice, informándole que la transacción puede proceder.
3. Alice construye los datos de transferencia RGB "Alice to Bob" en un árbol de Merkle y publica la Raíz de Merkle en la cadena de Bitcoin como un Compromiso. Simplemente podemos entender el Compromiso como el hash de los datos de transferencia.
4. Si alguien en el futuro desea confirmar que la transferencia de “Alice a Bob” realmente ocurrió, debe hacer dos cosas: obtener la información completa de la transferencia de “Alice a Bob” en la cadena de Bitcoin y luego verificar si el Compromiso correspondiente (el hash de los datos de la transferencia) existe en la cadena de Bitcoin.

Bitcoin sirve como el registro histórico para la red RGB, pero el registro solo registra la raíz hash/Merkle de los datos de transacción, no los datos de transacción en sí. Debido a la adopción de verificación del lado del cliente y sellos de un solo uso, el protocolo RGB ofrece una seguridad extremadamente alta. Dado que la red RGB está compuesta por clientes de usuarios dinámicos de manera P2P, sin consenso, puedes cambiar las contrapartes de transacción en cualquier momento sin necesidad de enviar solicitudes de transacción a un número limitado de nodos. Por lo tanto, la red RGB exhibe una fuerte resistencia a la censura. Esta estructura organizativa la hace más resistente a la censura en comparación con las cadenas públicas a gran escala como Ethereum.

(Fuente de la imagen: BTCEden.org)

Por supuesto, la alta seguridad, la resistencia a la censura y la protección de la privacidad proporcionadas por el protocolo RGB también conllevan costos significativos. Los usuarios necesitan ejecutar su cliente para verificar los datos. Si alguien le envía activos con un historial de transacciones largo que involucra miles de transferencias, deberá verificarlos todos, lo que puede ser bastante engorroso.

Además, cada transacción requiere múltiples comunicaciones entre las partes. El destinatario necesita verificar la fuente de activos del remitente y luego enviar un recibo para aprobar la solicitud de transferencia del remitente. Este proceso implica al menos tres intercambios de mensajes entre las partes. Esta "transferencia interactiva" es muy diferente de la "transferencia no interactiva" a la que la mayoría de las personas están acostumbradas. Imagina que alguien necesita enviarte dinero y tener que enviarte los datos de la transacción para que los inspecciones, esperando tu mensaje de recibo antes de completar el proceso de transferencia.

Además, como mencionamos anteriormente, la red RGB carece de consenso y cada cliente opera de forma aislada, lo que dificulta migrar escenarios complejos de contratos inteligentes de las cadenas públicas tradicionales a la red RGB. Esto se debe a que los protocolos DeFi en Ethereum o Solana dependen de registros globalmente visibles y transparentes. Cómo optimizar el protocolo RGB, mejorar la experiencia del usuario y abordar estos desafíos se convierte en un problema inevitable para el protocolo RGB.

RGB++ Introduce un enfoque de custodia optimista, reemplazando la verificación del lado del cliente.

El protocolo llamado RGB++ introduce un nuevo enfoque al combinar el protocolo RGB con cadenas públicas compatibles con UTXO como CKB, Cardano y Fuel. En esta configuración, este último sirve como capa de validación y almacenamiento de datos para los activos RGB, transfiriendo las tareas de verificación de datos originalmente realizadas por los usuarios a plataformas/cadenas de terceros como CKB. Esto reemplaza efectivamente la verificación del lado del cliente con la “verificación de plataforma descentralizada de terceros.” Siempre y cuando confíes en plataformas/cadenas como CKB, Cardano o Fuel, estás listo para continuar. Si no confías en ellas, siempre puedes volver al modo RGB tradicional.

RGB++ y el protocolo original RGB son teóricamente compatibles entre sí; no se trata de uno u otro, sino más bien de que pueden coexistir.

Para lograr el efecto mencionado, necesitamos aprovechar un concepto llamado "enlaces homomórficos". Las cadenas públicas como CKB y Cardano tienen sus propios modelos UTXO extendidos, que ofrecen más programabilidad en comparación con los UTXOs en la cadena de Bitcoin. "Enlace homomórfico" es la idea de usar los UTXOs extendidos en cadenas como CKB, Cardano y Fuel como los "contenedores" para los datos de activos RGB. Los parámetros de los activos RGB se escriben en estos contenedores y se muestran directamente en la cadena de bloques. Cada vez que ocurre una transacción de activos RGB, el contenedor de activos correspondiente también puede exhibir características similares, similar a la relación entre entidades y sombras. Esta es la esencia del "enlace homomórfico".

(Fuente de la imagen: RGB++ LightPaper)

Por ejemplo, si Alice posee 100 tokens RGB y un UTXO (vamos a llamarlo UTXO A) en la cadena de Bitcoin, así como un UTXO en la cadena CKB marcado con "Saldo de tokens RGB: 100" y condiciones desbloqueadas asociadas con UTXO A:

Si Alice quiere enviar 30 tokens a Bob, primero puede generar un Compromiso con la declaración correspondiente: transferir 30 tokens RGB asociados con UTXO A a Bob y transferir 70 tokens a otro UTXO controlado por ella misma.

A continuación, Alice gasta UTXO A en la cadena de Bitcoin, publica la declaración anterior y luego inicia una transacción en la cadena CKB. Esta transacción consume el contenedor UTXO que contiene 100 tokens RGB, creando dos nuevos contenedores: uno que contiene 30 tokens (para Bob) y otro que contiene 70 tokens (controlado por Alice). Durante este proceso, la tarea de verificar la validez de los activos de Alice y las declaraciones de transacciones se completa por consenso entre nodos en redes como CKB o Cardano, sin la participación de Bob. En este punto, CKB y Cardano actúan como la capa de validación y la capa de DA (Disponibilidad de Datos), respectivamente, bajo la cadena de Bitcoin.

(Fuente de la imagen: RGB++ LightPaper)

Todos los datos de activos RGB de individuos se almacenan en la cadena CKB o Cardano, lo que proporciona una característica globalmente verificable que facilita la implementación de escenarios DeFi como piscinas de liquidez y protocolos de participación de activos. Por supuesto, el enfoque anterior también sacrifica la privacidad. Básicamente implica un equilibrio entre la privacidad y la usabilidad del producto. Si priorizas la máxima seguridad y privacidad, puedes volver al modo RGB tradicional. Si no te importan estos compromisos, puedes adoptar con confianza el modo RGB++, dependiendo enteramente de tus necesidades personales. (De hecho, aprovechando la potente funcionalidad de cadenas públicas como CKB y Cardano, las transacciones privadas pueden lograrse mediante el uso de ZK.)

Es importante enfatizar que RGB++ introduce una suposición de confianza significativa: los usuarios necesitan creer de manera optimista que la cadena CKB/Cardano o la plataforma de red compuesta por una gran cantidad de nodos a través de un protocolo de consenso es confiable y libre de errores. Si no confía en CKB, puede seguir el proceso de comunicación e verificación interactiva en el protocolo RGB original ejecutando su cliente usted mismo.

Bajo el protocolo RGB++, los usuarios pueden usar directamente sus cuentas de Bitcoin para operar sus contenedores de activos RGB en las cadenas CKB/Cardano UTXO sin necesidad de transacciones entre cadenas. Simplemente necesitan aprovechar las características de UTXOs en las mencionadas cadenas públicas y establecer las condiciones de desbloqueo del contenedor de Células asociadas con una dirección/UTXO de Bitcoin específica. Si las partes involucradas en las transacciones de activos RGB confían en la seguridad de CKB, es posible que ni siquiera necesiten publicar con frecuencia Compromisos en la cadena de Bitcoin. En cambio, pueden agregar y enviar un Compromiso a la cadena de Bitcoin después de que se hayan producido varias transferencias RGB. Esto se conoce como la característica de “plegado de transacciones”, que puede reducir los costos de transacción.

Es importante tener en cuenta que los "contenedores" utilizados en las vinculaciones homomórficas deben ser compatibles con las cadenas públicas que utilizan el modelo UTXO o tienen características similares en su infraestructura de almacenamiento de estado. Las cadenas basadas en EVM no son muy adecuadas para este propósito y pueden enfrentar muchos desafíos. (Este tema podría ser tratado en un artículo separado, ya que implica mucho contenido. Los lectores interesados pueden consultar artículos anteriores de Geek Web3 titulados "RGB++ y Homomorphic Bindings: Cómo CKB, Cardano y Fuel potencian el ecosistema de Bitcoin.“)

En resumen, las cadenas públicas o capas de extensión de funcionalidad adecuadas para implementar enlaces homomórficos deben tener las siguientes características:

1. Utilice el modelo UTXO u esquemas de almacenamiento de estado similares.
2. Ofrecer suficiente programabilidad UTXO, permitiendo a los desarrolladores escribir scripts de desbloqueo.
3. Tener un espacio de estado relacionado con UTXOs que puede almacenar estados de activos.
4. Tener puentes o nodos ligeros relacionados con Bitcoin disponibles.

Descargo de responsabilidad：

1. Este artículo es un reimpreso de [极客 Web3], Todos los derechos de autor pertenecen al autor original [Faust]. Si hay objeciones a esta reimpresión, por favor póngase en contacto con el Gate Learnequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.