Autor: Fausto y Wuyue, de GeekWeb3 y BTCEden

El anuncio del lanzamiento de la capa RGB++ este mes, julio de 2024, marca la transición completa del protocolo RGB++ lanzado anteriormente de la teoría a un producto de ingeniería. Con su gran visión de construir un ecosistema BTCFi en BTC, CKB, Cardano y otras cadenas públicas pan-UTXO (salida de transacciones no gastadas), el lanzamiento de RGB++ Layer también ayuda a introducir escenarios más específicos y prácticos para la plataforma, convirtiéndola así en el foco. de atención para innumerables personas.

Basada en el protocolo RGB++, la capa RGB++ utiliza enlace isomórfico y Leap para proporcionar una experiencia de interacción entre cadenas "sin puentes" para activos nativos RGB++ o inscripciones/runas entre BTC, CKB, Cardano y otras cadenas públicas de tipo UTXO. Aprovecha el entorno de contrato inteligente completo de Turing de CKB para crear las condiciones necesarias para que Bitcoin emita activos e implemente funciones complejas de DeFi. Teniendo en cuenta que el ecosistema integral de abstracción de cuentas de CKB lo respalda y es compatible con cuentas y billeteras de Bitcoin, también allana el camino para la adopción a gran escala de BTCFi.

Este artículo tiene como objetivo ayudar a comprender los principios generales de funcionamiento y las características funcionales de la capa RGB++. También destaca los cambios que traerá la capa al ecosistema BTCFi en función de sus cuatro características distintivas.

1. El protocolo RGB++ como base teórica de la capa RGB++

El protocolo RGB++ se lanzó en enero para reemplazar la "verificación del lado del cliente" del protocolo RGB con la verificación en cadena CKB. Utiliza CKB como un indexador descentralizado, delegando tareas como el almacenamiento de datos y la verificación del origen de los activos a CKB, y este último actúa como capa de verificación y capa de disponibilidad de datos (DA) para el protocolo RGB. Esto es para ayudar a resolver problemas de transacciones no gastadas (UX) y defectos desfavorables en escenarios DeFi en el protocolo RGB.

De acuerdo con el concepto de "encapsulación única", la unión isomórfica de RGB++ utiliza Cell, un UTXO extendido en la cadena CKB, como portador de datos para activos de tipo inscripción/runa para establecer una relación vinculante con los UTXO en la cadena Bitcoin para heredar la seguridad de Bitcoin.

Por ejemplo, si Alice quiere transferir algunos tokens de PRUEBA a Bob, puede generar una declaración que vincule la celda que almacena información de activos de PRUEBA a uno de los UTXO de Bitcoin de Bob. Si Bob quiere transferir los tokens TEST a otra persona, también se debe transferir el UTXO de Bitcoin vinculado. De esta manera, existe una relación vinculante de 1 a 1 entre la celda que transporta datos de activos RGB++ y el UTXO de Bitcoin. Mientras el UTXO de Bitcoin no se gaste dos veces, el activo RGB++ vinculado no se puede gastar dos veces. Con este mecanismo, los activos RGB++ han heredado la seguridad de Bitcoin.

La capa RGB++ es un producto de la implementación de ingeniería del protocolo RGB++. Sus dos características principales son la unión isomórfica y la cadena cruzada sin puente Leap.

2. Enlace y salto isomórfico: emisión de activos y capa de cadena cruzada sin puentes para BTCFi

Para comprender la unión isomórfica y el enfoque Leap, es esencial explicar el modelo celular de CKB. Una celda es un UTXO extendido con múltiples campos, como LockScript, TypeScript y Data. LockScript funciona de manera similar al script de bloqueo de Bitcoin, utilizado para la verificación de permisos; TypeScript es similar al código de contrato inteligente, mientras que Data se utiliza para almacenar datos de activos.

Si desea emitir activos RGB++ en la cadena CKB, primero cree una celda y escriba el símbolo del token y el código del contrato en los campos correspondientes. Luego puedes descomponer la celda y distribuirla a muchas personas, al igual que la división y transferencia de Bitcoin UTXO.

Con la similitud estructural de Cell con los UTXO de Bitcoin y la similitud de CKB con el algoritmo de firma de Bitcoin, los usuarios pueden manipular activos en la cadena CKB utilizando billeteras de Bitcoin. Como propietario de una celda, puede configurar su secuencia de comandos de bloqueo para que su condición de desbloqueo sea consistente con la de un UTXO de Bitcoin, lo que le permite manipular directamente las celdas en la cadena CKB utilizando la clave privada de una cuenta de Bitcoin.

Las características destacadas anteriormente también se pueden implementar entre CKB, BTC y otras cadenas públicas UTXO. Por ejemplo, puede usar una cuenta Cardano para reescribir datos de activos en la cadena CKB, y los derechos de control de los activos RGB++ se transfieren de una cuenta BTC a una cuenta Cardano sin un puente entre cadenas. Recuerde que la vinculación de activos RGB++ a UTXO en cadenas públicas como Bitcoin, Cardano, Liquid, etc. (similar a cómo se vinculan las cuentas bancarias a los números de teléfono e identificaciones de los clientes en casos de la vida real) es para evitar el doble gasto.

También cabe señalar que los activos RGB++ son un conjunto de datos que necesitan almacenamiento multimedia, como en una base de datos. Las celdas de la cadena CKB pueden servir como base de datos. Luego, la verificación de permisos podría configurarse para permitir el acceso a cuentas de diferentes cadenas públicas como BTC y Cardano para reescribir datos de activos RGB++ en la cadena CKB.

El "Salto" y la cadena cruzada sin puentes propuestos por RGB++ Layer se basan en la tecnología de enlace isomórfico. Sirven para "volver a vincular" los UTXO vinculados a activos RGB++. Por ejemplo, si sus activos anteriormente estaban vinculados a UTXO de Bitcoin, ahora pueden volver a vincularse a UTXO en Cardano, Liquid, Fuel y otras cadenas. Como resultado, los permisos de control de activos se transfieren de las cuentas BTC a Cardano u otras cuentas.

Desde la perspectiva del usuario, esto equivale a un encadenamiento cruzado de activos, en el que CKB desempeña un papel similar al de un indexador y una base de datos. Sin embargo, a diferencia de los métodos tradicionales de cadena cruzada, "Leap" solo cambia el permiso para modificar los datos de los activos, mientras que los datos en sí todavía están almacenados en la cadena CKB. Este método es más conciso que el modelo Lock-Mint y elimina la dependencia de los contratos de activos mapeados.

Enfoque de implementación técnica de la unión isomórfica

Suponiendo que Alice tiene 100 tokens de PRUEBA cuyos datos se almacenan en la Celda#0 y tiene una relación vinculante con UTXO#0 en la cadena de Bitcoin. Para transferir 40 tokens de PRUEBA a Bob, necesita dividir la celda n.° 0 en dos celdas nuevas, donde la celda n.° 1 contiene 40 tokens de PRUEBA que se transferirán a Bob y la celda n.° 2 contiene 60 tokens de PRUEBA que aún controla Alice.

En este proceso, el BTC UTXO#0 unido a la Celda#0 debe dividirse en UTXO#1 y UTXO#2 y luego unirse a la Celda#1 y la Celda#2 respectivamente. Entonces, cuando Alice transfiere la celda n.° 1 a Bob, también puede transferir BTC UTXO n.° 1 a Bob con un solo clic para lograr transacciones sincrónicas en las cadenas CKB y BTC.

La importancia central de la unión isomórfica es su adaptabilidad. Esto es particularmente clave ya que Cell de CKB, eUTXO de Cardano y UTXO de Bitcoin son todos modelos UTXO, y CKB es compatible con los algoritmos de firma de Bitcoin/Cardano. Los métodos de operación de UTXO en las cadenas Bitcoin y Cardano también funcionan para Cells en la cadena CKB. De esta manera, las cuentas de Bitcoin/Cardano se pueden usar directamente para controlar simultáneamente los activos RGB++ en la cadena CKB y sus UTXO de Bitcoin/Cardano vinculados, logrando transacciones sincrónicas 1:1.

Siguiendo el escenario anterior de transferencia de Alice a Bob, el flujo de trabajo general es el siguiente:

1. Alice construye datos de transacción CKB localmente (aún no en la cadena), especificando que la celda n.° 0 se destruirá, se generará la celda n.° 1 que se enviará a Bob y la celda n.° 2 se conservará para ella;

   
   

2. Alice genera una declaración localmente, vinculando la Celda#1 a UTXO#1 y la Celda#2 a UTXO#2, y enviando tanto la Celda#1 como el UTXO#1 a Bob;

   
   

3. Luego, Alice genera un Compromiso (similar a un hash) localmente, correspondiente al contenido original, incluida la declaración del paso 2 + los datos de la transacción CKB generados en el paso 1;

   
   

4. Alice inicia una transacción en la cadena de Bitcoin, destruye el UTXO#0, genera el UTXO#1 para enviarlo a Bob, se queda con el UTXO#2 y escribe el Compromiso con la cadena de Bitcoin en forma de código de operación OP_Return;

   
   

5. Una vez completado el paso 4, la transacción CKB generada en el paso 1 se envía a la cadena CKB.

Tenga en cuenta que la celda y el UTXO de Bitcoin correspondiente están vinculados isomórficamente y pueden controlarse directamente mediante cuentas de Bitcoin. Es decir, durante el proceso de interacción, los usuarios pueden realizar operaciones con un solo clic a través de cuentas Bitcoin en la billetera RGB++. Por lo tanto, los activos RGB++ vinculados a los UTXO de Bitcoin ayudan a resolver el problema del doble gasto, ya que los activos en la capa RGB++ heredan la seguridad de Bitcoin.

El escenario anterior no se limita a la unión isomórfica entre Bitcoin y CKB, sino que también se aplica a una amplia gama de cadenas, incluidas Cardano, Liquid, Litecoin, etc.

Principio de implementación y escenarios de salto admitidos

La función Leap es básicamente cambiar el UTXO vinculado a activos RGB++, por ejemplo, cambiar el enlace de Bitcoin a Cardano, después de lo cual puede controlar los activos RGB++ usando cuentas Cardano. En tal caso, aún se podría realizar una transferencia en la cadena Cardano posteriormente, dividiendo y transfiriendo el UTXO que controla los activos RGB++ a más personas. Si bien los activos RGB ++ se pueden transferir y distribuir en múltiples cadenas públicas UTXO, pueden evitar el modelo tradicional Lock-Mint de puente entre cadenas.

En este proceso, la cadena pública CKB desempeña un papel similar a un indexador, presenciando y procesando solicitudes Leap. Supongamos que desea transferir activos RGB++ vinculados a BTC a una cuenta Cardano, los pasos principales a seguir son:

1. Publicar un Compromiso sobre la cadena Bitcoin, declarando la desvinculación de la Célula ligada a la UTXO BTC;

   
   

2. Publicar un Compromiso sobre la cadena Cardano, declarando la vinculación de la Célula al Cardano UTXO;

   
   

3. Cambiar el script de bloqueo del Celular, cambiando la condición de desbloqueo de una clave privada de una cuenta Bitcoin a una clave privada de una cuenta Cardano

Tenga en cuenta que los datos de los activos RGB++ todavía se almacenan en la cadena CKB durante este proceso. La condición de desbloqueo cambia de una clave privada de Bitcoin a una clave privada de Cardano. Por supuesto, el proceso de ejecución específico es mucho más complejo que el descrito anteriormente, pero no lo detallaremos aquí.

En el salto a cadenas públicas que no son de CKB, la premisa implícita es que la cadena pública de CKB actúa como un testigo externo, un indexador y una instalación de DA. Esto se debe a que, como cadena pública, su credibilidad supera con creces los métodos tradicionales de puente entre cadenas, como la computación multipartita (MPC) y la firma múltiple.

Otro escenario interesante que se puede implementar basándose en la función Leap son las "transacciones de cadena completa". Un ejemplo de este escenario es cuando se configura un indexador en Bitcoin, Cardano y CKB para construir una plataforma comercial que permita a compradores y vendedores intercambiar activos RGB++. En tal caso, los compradores pueden transferir sus bitcoins a los vendedores y recibir activos RGB++ con sus cuentas Cardano.

Durante todo el proceso, los datos de los activos RGB++ todavía se registran en celdas que se transfieren al comprador y sus permisos de desbloqueo se cambian de la clave privada de Bitcoin del vendedor a la clave privada de Cardano del comprador.

Envoltura

Aunque la función Leap es perfecta para activos RGB++, todavía existen algunos cuellos de botella:

Para Bitcoin y Cardano, los activos RGB++ son esencialmente inscripciones/runas/monedas de colores basadas en el código de operación OP_RETURN. Los nodos de estas cadenas públicas no pueden percibir la existencia de activos RGB++, ya que CKB participa en la coordinación como indexador. En otras palabras, para Bitcoin y Cardano, la capa RGB++ admite principalmente el salto de inscripciones/runas/monedas de colores, en lugar de la cadena cruzada de activos nativos como BTC y ADA.

Como solución, la capa RGB++ introdujo Wrapper, un puente basado en pruebas de fraude y sobregarantía. Tomando el contenedor rBTC como ejemplo, conecta BTC con la capa RGB++. Un conjunto de contratos inteligentes que se ejecutan en la capa RGB++ monitorean a los guardianes del puente. Si los guardianes actúan maliciosamente, su garantía será reducida. Si se confabulan para robar BTC bloqueados, los titulares de rBTC recibirán una compensación completa.

Con la combinación de Leap y Wrapper, varios activos en el ecosistema BTCFi, por ejemplo, activos nativos RGB++, BRC20, ARC20, runas, etc., se pueden conectar a otras capas o cadenas públicas.

El siguiente diagrama muestra parte del proceso de uso de LeapX. Admite la interoperabilidad de casi todos los activos BTCFi convencionales con diferentes ecosistemas. Existen flujos de procesamiento correspondientes para activos emitidos de diferentes maneras y algunos utilizan contenedores o Leap.

3. CKB-VM: el motor de contrato inteligente para BTCFi

Debido a la falta de soporte para contratos inteligentes en BTCFi tradicional, solo se pueden implementar aplicaciones descentralizadas (dApps) relativamente simples en el espacio en evolución. Algunos métodos de implementación pueden tener ciertos riesgos de centralización, mientras que otros son bastante torpes o inflexibles.

Para tener una capa de contrato inteligente disponible en blockchain, CKB introdujo CKB-VM a través de la capa RGB++. Su objetivo es hacer posible que cualquier lenguaje de programación que admita la máquina virtual RISC-V se utilice para el desarrollo de contratos en la capa RGB++. Permite a los desarrolladores utilizar sus herramientas y lenguajes preferidos para desarrollar e implementar contratos inteligentes eficientes y seguros bajo un marco de contrato inteligente unificado y un entorno de ejecución.

Generalmente, los requisitos de entrada para el desarrollo de contratos inteligentes de los desarrolladores con RISC-V son relativamente bajos debido a su amplio soporte de lenguaje y compilador. Por supuesto, el lenguaje es solo un aspecto de la programación y aprender marcos de contratos inteligentes específicos es inevitable. Sin embargo, con la capa RGB ++, la lógica se puede reescribir fácilmente en JavaScript, Rust, Go, Java y Ruby, en lugar de aprender un lenguaje DSL específico para escribir contratos.

El siguiente diagrama muestra un método para transferir tokens definidos por el usuario (UDT) con CKB usando lenguaje C. Aparte de los diferentes idiomas, su lógica básica es la misma para los tokens generales.

4. Ecosistema AA nativo: conexión perfecta de BTC y RGB++

Finalmente, dado que BTCFi esencialmente proporciona diversas experiencias DeFi para activos nativos de Bitcoin, comprender el ecosistema de abstracción de cuentas detrás de RGB++ Layer junto con sus billeteras Bitcoin convencionales es un factor importante que las instalaciones periféricas de BTCFi deben considerar.

RGB++ Layer reutiliza directamente la solución AA nativa de CKB, que es compatible con las principales cadenas públicas UTXO como BTC y Cardano tanto en el lado del desarrollador como del usuario. Con la capa RGB++, se pueden utilizar diferentes algoritmos de firma para la autenticación. Es decir, los usuarios pueden manipular directamente los activos en la capa RGB++ utilizando cuentas, billeteras o métodos de autenticación BTC, Cardano o incluso WebAuthn.

Un ejemplo es el middleware de billetera, CCC, que puede proporcionar a CKB la operatividad de varias cadenas públicas para billeteras y dApps. La siguiente imagen muestra la ventana de conexión de CCC y cómo admite entradas de billeteras convencionales como Unisat y Metamask.

Otro ejemplo es la implementación de WebAuthn con JoyID, una billetera del ecosistema CKB, como representante típico. Los usuarios de JoyID pueden autenticar directamente sus cuentas a través de métodos biométricos (como huellas dactilares o reconocimiento facial) para lograr una gestión de identidad e inicio de sesión fluida y altamente segura.

Se puede decir que RGB ++ Layer tiene una solución AA nativa completa, que también puede adaptarse a los estándares de cuentas de otras cadenas públicas. Esta característica no solo facilita el soporte para algunos escenarios clave, sino que también elimina obstáculos para las UX.

Resumen

Este artículo presentó las tecnologías centrales de la capa RGB++ sin explicar varios detalles complejos.

Destaca que la capa RGB++ puede ser una infraestructura importante para realizar escenarios de interacción de cadena completa, incluidas varias monedas meme e inscripciones/runas/monedas de colores. El entorno de ejecución de contratos inteligentes basado en RISC-V de la capa también puede ayudar a crear el terreno para que crezca la compleja lógica empresarial requerida por BTCFi.

A medida que avance la Capa RGB++, se proporcionará un análisis más exhaustivo de la serie de soluciones técnicas relacionadas con el proyecto. ¡Por favor manténgase al tanto!