Instrucciones vernáculas:
Comprenda el diseño de los protocolos RGB y RGB++ en un artículo
Con la popularidad de la emisión de RGB++ y activos relacionados, la discusión sobre los principios de los protocolos RGB y RGB++ se ha convertido gradualmente en un tema de preocupación para más personas. Pero todo el mundo sabe que para entender RGB++, primero hay que entender el protocolo RGB.
El protocolo RGB original es un poco oscuro en términos de estructura técnica y los materiales de referencia están dispersos. Hasta ahora, no hay muchos materiales de referencia sistemáticos y fáciles de entender.
Protocolo RGB: los usuarios deben realizar la verificación de datos ellos mismos
El protocolo RGB es un protocolo especial de activos P2P y un sistema informático fuera de la cadena Bitcoin. Es similar a un canal de pago en algunos aspectos: los usuarios deben ejecutar el cliente ellos mismos y verificar su propio comportamiento de transferencia (verificarlo usted mismo). Incluso si usted es solo un destinatario de activos, primero debe asegurarse de que no haya errores en la declaración de transferencia del remitente de activos antes de que la declaración de transferencia pueda entrar en vigencia. Obviamente esto es completamente diferente a la forma tradicional de enviar y recibir activos, lo llamamos "transferencia interactiva".
¿Por qué esto es tan? 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 de activos sean seguros sin un proceso de consenso que involucre una gran cantidad de nodos? Aquí se utiliza la idea llamada "Verificación del cliente" (Verificar usted 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 de PRUEBA a Bob. Después de que Alice genera la información de transferencia de "Alice a Bob", primero debe enviar la información de transferencia y los datos de los activos involucrados a Bob, y dejar que él los verifique personalmente para asegurarse de que sean correctos antes de ingresar al proceso posterior, y finalmente se convierte en una transferencia RGB válida. Por lo tanto, el protocolo RGB permite a los usuarios verificar personalmente la validez de los datos, reemplazando el algoritmo de consenso tradicional.
Pero no hay consenso y los datos recibidos y almacenados por diferentes clientes RGB son inconsistentes. Todos solo almacenan sus propios datos de activos localmente y no conocen el estado de los activos de los demás. Esto protege la privacidad y al mismo tiempo forma una "isla de datos". Si alguien afirma tener 1 millón de tokens TEST y quiere transferirte 100.000, ¿cómo puedes creerle?
En la red RGB, si alguien quiere transferirle dinero, primero debe mostrar prueba de activos, rastrear la fuente histórica de los activos desde la emisión inicial hasta múltiples cambios de manos y asegurarse de que el token que se le va a transferir está bien. Esto es como cuando recibe Cuando recibe billetes de banco no identificados, le pide a la otra parte que explique el origen histórico de estos billetes y si fueron fabricados por el emisor designado, para evitar la falsificación de moneda.
Los procesos anteriores ocurren fuera de la cadena de Bitcoin y estos procesos por sí solos no permiten 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 Bitcoin. Mientras el UTXO de Bitcoin no se consuma dos veces, los activos RGB vinculados no se duplicarán. que la red Bitcoin se puede utilizar para evitar la "Reorganización" de los activos RGB. Por supuesto, esto requiere emitir un Compromiso en la cadena Bitcoin y utilizar el código de operación OP_Return.
Clasifiquemos el flujo de trabajo del protocolo RGB:
1. Los activos RGB están vinculados a Bitcoin UTXO y Bob posee ciertos Bitcoin UTXO. Alice quiere transferir 100 tokens a Bob. Antes de recibir los activos, Bob le dice a Alice de antemano qué UTXO de Bitcoin de Bob debería usarse para vincular estos activos RGB.
* Alice construye datos de transferencia de activos RGB "Alice a Bob", junto con las fuentes históricas de estos activos, y se los entrega a Bob para su verificación.
* 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 realizarse.
* Alice construye los datos de transferencia RGB de "Alice a Bob" en un árbol Merkle y publica la raíz de Merkle en la cadena Bitcoin como un Compromiso. Podemos entender simplemente el Compromiso como el hash de los datos de transferencia.
* Si alguien quiere confirmar en el futuro que la transferencia de "Alice a Bob" mencionada anteriormente realmente ocurrió, debe hacer dos cosas: obtener la información completa de la transferencia de "Alice a Bob" en la cadena Bitcoin y luego verificar si existe en la cadena Bitcoin El Compromiso correspondiente (hash de datos de transferencia) es suficiente.
Bitcoin aquí actúa como el registro histórico de la red RGB, pero en el registro solo se registra la raíz hash/Merkle de los datos de la transacción, no los datos de la transacción en sí. Debido al uso de verificación de cliente y sellado único, el protocolo RGB tiene una seguridad extremadamente alta porque la red RGB está compuesta por clientes de usuarios dinámicos en un formato P2P sin consenso, puede cambiar la contraparte en cualquier momento sin realizar transacciones; Las solicitudes se envían a un número limitado de nodos, por lo que la red RGB es extremadamente resistente a la censura. Esta forma organizativa es más resistente a la censura que las grandes cadenas públicas como Ethereum.
Por supuesto, el costo de la seguridad extremadamente alta, la resistencia a la censura y la protección de la privacidad también es obvio: los usuarios tienen que ejecutar el cliente para verificar los datos ellos mismos si la otra parte envía algunos activos que han cambiado de manos decenas de miles de veces. una larga historia, también tienes que verificar todo bajo presión;
Además, cada transacción requiere múltiples comunicaciones entre las dos partes. La parte receptora debe primero verificar el origen de los activos del remitente y luego enviar un recibo para aprobar la solicitud de transferencia del remitente. Durante este proceso, se deben pasar al menos tres mensajes entre las dos partes. Este tipo de "transferencia interactiva" es seriamente inconsistente con la "transferencia no interactiva" a la que la mayoría de la gente está acostumbrada. ¿Te imaginas que si alguien quiere transferirte dinero, tiene que enviarte los datos de la transacción para verificarlos y obtenerlos? ¿Su recibo? ¿Se puede completar el proceso de transferencia solo después de recibir el mensaje?
Además, hemos mencionado que la red RGB no tiene consenso y cada cliente es una isla, lo que no favorece la migración de escenarios complejos de contratos inteligentes en cadenas públicas tradicionales a la red RGB porque todos los protocolos Defi en Ethereum o Solana dependen de A. Libro de contabilidad globalmente visible y transparente para los datos. ¿Cómo optimizar el protocolo RGB, mejorar la experiencia del usuario y resolver los problemas anteriores? Esto se ha convertido en un problema inevitable para el protocolo RGB.
RGB++: la validación del cliente se convierte en hosting optimista
El protocolo llamado RGB++ presenta 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 realizados originalmente. por parte de los usuarios El trabajo de verificación 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 que confíe en cadenas públicas como CKB y Cardano. , Combustible, etc., si no confía en ellos, también puede volver al modo RGB tradicional.
RGB++ y el protocolo RGB original son teóricamente compatibles entre sí.
Para lograr los efectos mencionados anteriormente, es necesario utilizar una idea llamada "unión isomórfica". Las cadenas públicas como CKB y Cardano tienen su propio UTXO extendido, que es más programable que el UTXO de la cadena BTC. La "vinculación isomorfa" consiste en utilizar UTXO extendido en las cadenas CKB, Cardano y Fuel como "contenedores" para datos de activos RGB, escribir los parámetros de los activos RGB en estos contenedores y mostrarlos directamente en la cadena de bloques. Siempre 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 del "enlace isomórfico".
Por ejemplo, si Alice posee 100 tokens RGB y UTXO A en la cadena Bitcoin, y también tiene un UTXO en la cadena CKB, este UTXO está marcado con "Saldo de token RGB: 100" y las condiciones de desbloqueo están relacionadas con UTXO A. .
Si Alice quiere darle 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 UTXO controlados por ella.
Luego, Alice gasta UTXO A en la cadena 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 con 30 tokens (para Bob), otro. tiene 70 fichas (controladas 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 nodos de red como CKB o Cardano mediante consenso, sin la intervención de Bob. En este momento, CKB y Cardano sirven como capa de verificación y capa DA bajo la cadena de Bitcoin.
Los datos de los activos RGB de todos se almacenan en la cadena CKB o Cardano, que tiene características verificables globalmente y favorece la implementación de escenarios Defi, como fondos de liquidez y protocolos de promesa 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 busca la máxima seguridad y privacidad, puede volver al modo RGB tradicional; Si te importa esto, puedes usar RGB++ de forma segura. El modo depende completamente de tus necesidades personales. (De hecho, con la poderosa integridad funcional de cadenas públicas como CKB y Cardano, ZK se puede utilizar para implementar transacciones privadas)
Cabe destacar 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 una gran cantidad de nodos que dependen de protocolos de consenso, es confiable y está libre de errores. Si no confía en CKB, también puede seguir el proceso de verificación y comunicación interactiva en el protocolo RGB original y ejecutar el cliente usted mismo.
Según el protocolo RGB++, los usuarios pueden usar directamente cuentas de Bitcoin para operar sus propios contenedores de activos RGB en cadenas UTXO como CKB/Cardano sin cadena cruzada. Solo necesitan usar las características de UTXO en las cadenas públicas anteriores para establecer las condiciones de desbloqueo. del contenedor Cell Simplemente configúrelo para que se asocie con una determinada dirección de Bitcoin/Bitcoin UTXO. Si ambas partes de la transacción de activos RGB confían en la seguridad de CKB, ni siquiera necesitan publicar con frecuencia Compromisos en la cadena de Bitcoin. Después de completar muchas transferencias RGB, pueden enviar un Compromiso a la cadena de Bitcoin. Esto se denomina "transacción". La función plegable "" puede reducir los costos de uso.
