protocolo RGB: los usuarios deben realizar la verificación de datos por sí mismos

El protocolo RGB es un protocolo de activos P2P especial y un sistema informático bajo la cadena de Bitcoin. Es similar a un canal de pago en algunos aspectos: los usuarios necesitan ejecutar el cliente ellos mismos y verificar su propio comportamiento de transferencia (Verificar por ti mismo). Incluso si solo eres un receptor de activos, primero debes asegurarte de que no haya errores en la declaración de transferencia del remitente de activos antes de que la declaración de transferencia pueda tener efecto. Obviamente, esto es completamente diferente de la forma tradicional de enviar y recibir activos. Lo llamamos “transferencia interactiva”.

¿Por qué debería ser así? La razón es que, para garantizar la privacidad, el protocolo RGB no adopta el "protocolo de consenso" en las cadenas de bloques tradicionales como Bitcoin y Ethereum. (Una vez que los datos pasan por el protocolo de consenso, serán observados por casi todos los nodos de la red, y la privacidad no está garantizada). ¿Cómo garantizar que los cambios en los activos sean seguros sin un proceso de consenso que involucre a un gran número de nodos? Aquí se utiliza la idea llamada "Verificación del cliente" (Verificación por ti mismo). Debe ejecutar el cliente usted mismo y verificar personalmente los cambios de activos relacionados con usted. Supongamos que hay un usuario RGB llamado Bob que conoce a Alice y Alice quiere transferir 100 tokens TEST a Bob. Después de que Alice genere la información de transferencia de "Alice a Bob", primero debe enviar la información de transferencia y los datos de activos involucrados a Bob, y dejar que él la verifique personalmente para asegurarse de que sea correcta antes de ingresar al proceso posterior y, finalmente, se convierte en una transferencia RGB válida. De esta forma, el protocolo RGB permite a los usuarios verificar personalmente la validez de los datos, sustituyendo al algoritmo de consenso tradicional. Pero sin consenso, los datos recibidos y almacenados por diferentes clientes RGB son inconsistentes. Todo el mundo solo almacena sus propios datos de activos localmente y no conoce el estado de los activos de los demás. Al mismo tiempo que protege la privacidad, esto también constituye una "isla de datos". Si alguien dice tener 1 millón de tokens TEST y quiere transferirte 100.000, ¿cómo puedes creerlo? En la red RGB, si alguien quiere transferirle dinero, primero debe mostrar una prueba de activos, rastrear la fuente histórica de los activos desde la emisión inicial hasta los múltiples cambios de manos y asegurarse de que el token que se le transferirá esté limpio. Esto es como cuando recibes billetes de origen desconocido y le pides a la otra parte que explique la fuente histórica de estos billetes y si fueron fabricados por el emisor designado, para evitar la falsificación de moneda.

(Fuente de la imagen: Coinex)

Los procesos anteriores ocurren bajo la cadena de Bitcoin, y estos procesos por sí solos no pueden hacer que RGB esté directamente relacionado con la red de Bitcoin. En este sentido, el protocolo RGB adopta una idea llamada “sello de un solo uso” para vincular los activos RGB a UTXO en la cadena de Bitcoin. Siempre que el UTXO de Bitcoin no sea consumido dos veces, los activos RGB vinculados no serán gastados dos veces. De esta manera, la red de Bitcoin se puede utilizar para prevenir la “Reorganización” de los activos RGB. Por supuesto, este compromiso debe ser publicado en la cadena de Bitcoin y se utiliza el opcode OP_Return.

Aquí tienes un resumen del flujo de trabajo del protocolo RGB:

1. Los activos RGB están vinculados a Bitcoin UTXO, y Bob posee ciertos Bitcoin UTXOs. Alice quiere transferir 100 tokens a Bob. Antes de recibir los activos, Bob le dice a Alice de antemano qué Bitcoin UTXO de Bob se debe usar para vincular estos activos RGB.

(Fuente de la imagen: Geekweb3/GeekWeb3)

1. Alice construye un datos de transferencia de activos RGB "Alice a Bob", junto con las fuentes históricas de estos activos, y se los da a Bob para su verificación.
2. Después de que Bob confirma localmente que los datos están bien, envía un recibo a Alice, diciéndole que la transacción puede continuar.
3. Alice construye los datos de transferencia RGB de "Alice a Bob" en un Árbol de Merkle, y publica la Raíz de Merkle en la cadena de Bitcoin como un Compromiso. Podemos entender simplemente el Compromiso como el hash de los datos de transferencia.
4. Si alguien quiere confirmar en el futuro que la transferencia mencionada anteriormente 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 hay una transacción correspondiente en la cadena de Bitcoin Commitment (hash de los datos de transferencia), eso es todo.

Bitcoin aquí actúa como el registro histórico de la red RGB, pero solo se registra en el registro el hash/raíz de Merkle de los datos de transacción en lugar de los datos de transacción en sí. Gracias a la validación del lado del cliente y al sellado único, el protocolo RGB tiene una seguridad extremadamente alta; dado que la red RGB está compuesta por clientes de usuarios dinámicos en una forma P2P libre de consenso, puedes cambiar la contraparte en cualquier momento sin enviar solicitudes de transacción a un número limitado de nodos, por lo que las redes RGB son extremadamente resistentes a la censura, esta forma organizativa es más resistente a la censura que las grandes cadenas públicas como Ethereum.

(Fuente de la imagen: BTCEden.org)

Por supuesto, la seguridad extremadamente alta, la resistencia a la censura y la protección de la privacidad conllevan costos obvios: los usuarios deben ejecutar el cliente para verificar los datos por sí mismos. Si la otra parte le envía algunos activos que han cambiado de manos decenas de miles de veces y tienen una larga historia, debe verificarlos todos bajo presión.

Además, cada transacción requiere múltiples comunicaciones entre las dos partes. La parte receptora primero debe verificar la fuente de los activos del remitente y luego enviar un recibo para aprobar la solicitud de transferencia del remitente. Durante este proceso, al menos tres mensajes deben ser intercambiados entre las dos partes. Este tipo de "transferencia interactiva" es seriamente inconsistente con la "transferencia no interactiva" a la que la mayoría de las personas están acostumbradas.

¿Puedes imaginar a alguien que quiera transferirte dinero, pero que debe enviarte los datos de la transacción para su verificación, y solo después de recibir tu mensaje de recibo se pueda completar el proceso de transferencia?

Además, hemos mencionado que la red RGB no tiene consenso y cada cliente es una isla, lo cual no es propicio para migrar escenarios de contratos inteligentes complejos en la cadena pública tradicional a la red RGB, ya que el protocolo Defi en Ethereum o Solana se basa en un libro mayor globalmente visible y transparente en datos. ¿Cómo optimizar el protocolo RGB, mejorar la experiencia del usuario y resolver los problemas mencionados? Esto se ha convertido en un problema inevitable para el protocolo RGB.

RGB++: La verificación del lado del cliente se convierte en custodia optimista

El protocolo llamado RGB++ propone una nueva idea. Combina el protocolo RGB con cadenas públicas que admiten UTXO como CKB, Cardano y Fuel. Este último sirve como capa de verificación y capa de almacenamiento de datos para los activos RGB, y convierte los datos originalmente procesados por los usuarios en el trabajo de verificación y se entrega a plataformas de terceros/cadenas públicas como CKB. Esto equivale a reemplazar la verificación del cliente con una “plataforma descentralizada de verificación de terceros”, siempre y cuando confíes en las cadenas públicas como CKB, Cardano, Fuel, etc. Incluso si no confías en ellos, también puedes volver al modo RGB tradicional.

RGB++ y el protocolo RGB original son teóricamente compatibles entre sí.

Para lograr los efectos mencionados anteriormente, necesitamos usar una idea llamada “vinculación isomórfica”. Las cadenas públicas como CKB y Cardano tienen su propio UTXO extendido, que es más programable que el UTXO en la cadena BTC. La “vinculación isomórfica” consiste en utilizar el UTXO extendido en las cadenas de CKB, Cardano y Fuel como “contenedores” para los datos de activos RGB, escribir los parámetros de activos RGB en estos contenedores y mostrarlos directamente en la cadena de bloques. Cada vez que ocurre una transacción de activos RGB, el contenedor de activos correspondiente también puede mostrar características similares, al igual que la relación entre entidades y sombras. Esta es la esencia de la “vinculación isomórfica”.

(Fuente de la imagen: RGB++ LightPaper)

Por ejemplo, si Alice posee 100 tokens RGB y UTXO A en la cadena de Bitcoin, y también tiene un UTXO en la cadena CKB, este UTXO está marcado con "Saldo de tokens RGB: 100", y las condiciones de desbloqueo están relacionadas con UTXO A.

Si Alice quiere enviar 30 tokens a Bob, primero puede generar un Compromiso. La declaración correspondiente es: transferir 30 de los tokens RGB asociados con UTXO A a Bob, y transferir 70 a otros UTXOs que ella controla.

Posteriormente, Alice gasta UTXO A en la cadena de Bitcoin, publica la declaración anterior y luego inicia una transacción en la cadena CKB para consumir el contenedor UTXO que lleva 100 tokens RGB y generar dos nuevos contenedores, uno que contiene 30 tokens (para Bob) y otro que contiene 70 tokens (controlado por Alice). En este proceso, la tarea de verificar la validez de los activos de Alice y la validez de la declaración de la transacción la completan los nodos de la red como CKB o Cardano a través de un consenso, sin la intervención de Bob. En este momento, CKB y Cardano actúan como la capa de verificación y la capa DA bajo la cadena de Bitcoin.

(Fuente de la imagen: RGB++ LightPaper)

Los datos de activos RGB de todos se almacenan en la cadena CKB o Cardano, que tiene características verificables a nivel mundial y es propicio para la implementación de Defi, como piscinas de liquidez y protocolos de garantía de activos. Por supuesto, el enfoque anterior también sacrifica la privacidad. La esencia es hacer un equilibrio entre la privacidad y la facilidad de uso del producto. Si buscas la máxima seguridad y privacidad, puedes volver al modo RGB tradicional; si no te importa esto, puedes usar de forma segura el modo RGB++, todo depende de tus necesidades personales. (De hecho, con la completa funcionalidad de las cadenas públicas como CKB y Cardano, ZK se puede utilizar para implementar transacciones privadas)

Debe enfatizarse aquí que RGB++ introduce una suposición de confianza importante: Los usuarios deben ser optimistas de que la cadena CKB/Cardano, o la plataforma de red compuesta por un gran número de nodos que dependen de protocolos de consenso, es confiable y libre de errores. Si no confías en CKB, también puedes seguir el proceso de comunicación interactiva y verificación en el protocolo RGB original y ejecutar el cliente tú mismo.

Bajo el protocolo RGB++, los usuarios pueden usar directamente sus cuentas de Bitcoin para operar sus contenedores de activos RGB en cadenas UTXO como CKB/Cardano sin necesidad de intercadenas. Simplemente aprovechen las características de UTXO en la mencionada cadena pública y establezcan la condición de desbloqueo del contenedor Cell asociada a una cierta dirección de Bitcoin/Bitcoin UTXO. Si ambas partes involucradas en transacciones de activos RGB pueden confiar en la seguridad de CKB, ni siquiera necesitarán emitir compromisos frecuentemente en la cadena de Bitcoin. Después de que se realicen muchas transferencias RGB, se puede enviar un Compromiso a la cadena de Bitcoin. Esto se llama la función de “plegado de transacciones”, que puede reducir los costos de uso.

Pero ten cuidado, el "contenedor" utilizado en el enlace isomórfico necesita una cadena pública que admita el modelo UTXO, o una infraestructura con características similares en el almacenamiento de estado. La cadena EVM no es adecuada y encontrará muchos obstáculos. (Este tema se puede escribir por separado e involucra mucho contenido. Los lectores interesados pueden consultar los artículos anteriores de Geek Web3)."RGB++ y Enlace Isomórfico: Cómo CKB, Cardano y Fuel Potencian el Ecosistema de Bitcoin"；

En resumen, Una cadena pública/capa de expansión de función adecuada para realizar un enlace isomórfico debería tener las siguientes características:

1. Utilice el modelo UTXO o un esquema de almacenamiento de estado similar;
2. Tiene una considerable programabilidad UTXO, lo que permite a los desarrolladores escribir scripts de desbloqueo;
3. Hay un espacio de estado relacionado con UTXO que puede almacenar el estado de los activos;
4. Hay puentes o nodos ligeros relacionados con Bitcoin;

Descargo de responsabilidad:

1. Este artículo es reproducido de [Geek Web3]], el título original es "Diseño del protocolo RGB y RGB++ en unos pocos minutos: instrucciones sencillas", los derechos de autor pertenecen al autor original [Faust], si tienes alguna objeción a la reimpresión, por favor contactaEquipo de Aprendizaje Gate, el equipo lo manejará tan pronto como sea posible de acuerdo con los procedimientos relevantes.

2. Las opiniones expresadas en este artículo representan solo las opiniones personales del autor y no constituyen ningún consejo de inversión.

3. Otras versiones del artículo en otros idiomas son traducidas por el equipo de Gate Learn. Sin hacer referenciaGate.io, copiar, distribuir o plagiar los artículos traducidos está prohibido.