Protocolo RGB ++ y el futuro de Bitcoin: perspectivas de Cipher de Bitcoin Singapur 2024

El 9 de marzo, durante la conferencia Bitcoin Singapore 2024, coorganizada por Nervos Foundation y ABCDE, Cipher, fundador de CELL Studio y autor del protocolo RGB++, presentó un discurso de apertura titulado "Descripción general y perspectivas del protocolo RGB++".

A continuación se muestra un resumen de los puntos principales de la presentación de Cipher:

Desafíos que enfrenta el Protocolo RGB

El protocolo RGB existe desde hace muchos años, pero no ha tenido una adopción generalizada debido a varios factores:

Desafíos con las operaciones interactivas

En transacciones que involucran BTC , ETH , etc., el receptor solo necesita proporcionar una dirección y el remitente puede transferir fondos hoy o mañana, lo cual es muy conveniente. Por el contrario, cada transacción RGB requiere que el destinatario emita primero una factura. Luego, el remitente debe construir una transacción RGB y generar una prueba del historial de activos para enviarla al destinatario. Al recibir esta prueba, el destinatario debe realizar la validación del lado del cliente (CSV). Después de una validación exitosa, deben almacenar esta prueba para futuras transacciones.

Por lo tanto, las transacciones RGB no solo dependen de que ambas partes estén en línea sino también de que ambas partes almacenen datos históricos relevantes. Esto plantea un obstáculo importante para los productos orientados al consumidor.

Problemas de disponibilidad de datos (DA)

En las transacciones RGB es imprescindible adjuntar el comprobante histórico del activo. Si se pierde esta prueba, es tan crítico como perder una clave privada. La cuestión de quién ayudará a los usuarios a salvar sus activos es un problema de disponibilidad de datos. En el protocolo RGB original, destinado a preservar la privacidad, nadie más almacena activos para los usuarios, lo que significa que los usuarios deben asumir la responsabilidad de su propio almacenamiento de datos.

Incluso con un almacenamiento de datos adecuado, considere un escenario en el que Alice quiera transferir activos RGB a Bob. ¿Cómo le envía la prueba histórica de estos bienes? ¿Usando correo electrónico o Whatsapp? Claramente, transmitir a través de cualquier canal centralizado es inapropiado y requiere el uso de un canal P2P especializado. Sin embargo, los canales P2P plantean cuestiones de confidencialidad: ¿por qué alguien ayudaría a transmitir estos datos confidenciales? Esto lleva a una serie de cuestiones complejas.

Problemas de interoperabilidad

Los propios usuarios conservan los datos de prueba históricos de los activos RGB y los transmiten al receptor durante las transacciones, pero no se ponen a disposición del público. Esto da como resultado que los datos se dispersen entre cada individuo de la red. Para alguien que construye una plataforma comercial, ya sea centralizada o descentralizada, se necesitan datos de múltiples fuentes para mantener el estado global de RGB. Hay algunos proveedores de servicios RGB que centralizan y almacenan estos datos para los desarrolladores de aplicaciones, pero este enfoque disminuye la privacidad de RGB. A pesar de esta solución, persisten desafíos, como facilitar las transferencias de datos entre varios proveedores de servicios que poseen datos RGB de diferentes usuarios.

Problemas con el entorno de ejecución de scripts/contratos inteligentes

Existen desafíos importantes asociados con los entornos de ejecución de scripts o contratos inteligentes en RGB. Utiliza una máquina virtual (VM) llamada AluVM, pero los detalles específicos de su lenguaje de programación aún no se han finalizado. Además, las herramientas de desarrollo críticas, como los compiladores y depuradores, no están completamente desarrolladas. También carece de apoyo para estados compartidos y contratos descentralizados (sin propietario). En la actualidad, es evidente que AluVM se encuentra todavía en sus primeras etapas.

Por lo tanto, RGB se enfrenta a numerosos problemas complejos, cada uno de los cuales requiere tiempo y esfuerzo considerables. Estos desafíos contribuyen significativamente a los retrasos en la implementación efectiva de RGB.

Una descripción general del protocolo RGB++

Las transacciones RGB están estrechamente vinculadas a las transacciones de Bitcoin mediante un proceso de mapeo. Además, las transacciones RGB exigen una infraestructura fuera de la cadena, que abarque disponibilidad de datos (DA), validación del lado del cliente, redes P2P, máquinas virtuales, estados compartidos y contratos descentralizados. Al considerar una infraestructura de este tipo, naturalmente nos viene a la mente la cadena de bloques, dadas sus capacidades en gestión de datos, validación, integración de máquinas virtuales, redes P2P, incentivación y contratos inteligentes. El concepto del protocolo RGB++ se basa en esta intuición fundamental y propone el uso de la cadena de bloques CKB basada en el modelo UTXO y completa de Turing como sustituto de la infraestructura fuera de la cadena requerida por RGB.

RGB ++ introduce un concepto llamado tecnología de enlace isomórfico . Cada transacción de Bitcoin incluye una salida. En el caso de una transacción RGB, es necesario incluir un segmento OP_RETURN dentro de la salida de Bitcoin. Este segmento contiene datos hash específicos, denominados compromiso. Si este compromiso coincide con el hash de una transacción en otra cadena de bloques pública, y si las entradas y salidas de ambas transacciones son isomórficas (lo que significa que se corresponden en estructura) y suponiendo que la UTXO (salida de transacción no gastada) de esta cadena de bloques alternativa posee un sistema computacional completo de Turing y capacidades de almacenamiento de estado, entonces la transacción en la cadena de bloques de Bitcoin se integra o vincula completamente con la transacción en esta otra cadena de bloques. La cadena de bloques CKB (Common Knowledge Base) cumple estos requisitos previos. Por lo tanto, realizar una transacción en Bitcoin equivale efectivamente a realizar una transacción correspondiente en la cadena CKB. Cualquier cambio en el estado de la transacción de Bitcoin refleja un cambio en el estado de la transacción en la cadena CKB, adhiriéndose a las restricciones del contrato presentes en CKB. Esto resume la esencia de la tecnología de unión isomórfica. Sin embargo, este concepto abarca numerosos aspectos técnicos complejos, incluido el mantenimiento de la coherencia transaccional y la prevención del doble gasto, que no se profundizan en detalle en este momento.

La tecnología de enlace isomórfico permite mejorar las capacidades estatales de Bitcoin. Por ejemplo, consideremos el btc_utxo#1 ilustrado en el siguiente diagrama. Este UTXO (salida de transacción no gastada) de Bitcoin generalmente muestra solo dos estados: un script de bloqueo y una cantidad, este último representa el saldo. Sin embargo, en la celda azul correspondiente en la cadena de bloques CKB (Common Knowledge Base), como se muestra en el diagrama, las capacidades son más amplias. A diferencia de la funcionalidad limitada de Bitcoin UTXO para mostrar simplemente el saldo, esta celda isomórfica en la cadena CKB puede almacenar no solo datos de saldo sino también otros tipos de datos.

Además del componente de datos, el Cell posee un tipo de escritura. Este script tiene un propósito específico: define las condiciones bajo las cuales se reciben los activos e impone restricciones sobre los tipos de activos.

Además, la celda contiene un script de bloqueo, que en este caso está vinculado explícitamente a btc_utxo#1. Este vínculo implica que la celda en la cadena de bloques CKB se puede gastar solo si se gasta btc_utxo#1.

En la plataforma CKB, hemos implementado un nodo ligero de Bitcoin. Una vez que se inicia una transacción de Bitcoin, es capturada por un mecanismo de retransmisión, que luego transfiere esta transacción como una forma de prueba a la cadena de bloques CKB. Este proceso implica verificar la presencia de la transacción en el nodo ligero de Bitcoin y garantizar que el compromiso sea isomórfico con la transacción.

A través de este enfoque, ampliamos significativamente las funcionalidades de Bitcoin. Allana el camino para la emisión de una amplia gama de activos directamente en Bitcoin y facilita la expansión de contratos completos de Turing.

La ventaja de este enfoque es que hemos introducido con éxito secuencias de comandos completas de Turing en el ámbito de Bitcoin, manteniendo al mismo tiempo un estado de seguridad casi idéntico al de la Capa 1 (L1) de Bitcoin. Esto se debe a que todos los registros históricos, transacciones y compromisos están vinculados a través de la cadena UTXO en Bitcoin L1.

La compensación, sin embargo, es una ligera disminución de la privacidad. En el caso de RGB, los datos están dispersos entre usuarios individuales, lo que dificulta que otros accedan a los datos RGB de cualquier usuario en particular. Con RGB++, todos los datos fuera de la cadena se publican en la cadena de bloques CKB, que mantiene estos estados, lo que lleva a una reducción de la privacidad. Sin embargo, el peor de los casos es sólo una reducción del nivel de privacidad que se encuentra en las transacciones de Bitcoin; no expone direcciones IP ni información de identidad personal.

De hecho, podríamos implementar una capa de privacidad mejorada en CKB. Hace cuatro años, colaboramos con la comunidad Grin para escribir un artículo sobre el uso de la tecnología Mimblewimble en CKB para crear esta capa de privacidad mejorada. En el futuro, podríamos integrar esta capa en RGB++, permitiendo no solo ocultar los montos de las transacciones sino también cortar los vínculos en el historial de transacciones. La privacidad resultante sería mayor que la del RGB.

En resumen, hemos hecho realidad la visión de RGB de una manera más sencilla y hemos ampliado aún más sus capacidades.

Liberando el potencial de los activos Bitcoin L1

A continuación se ofrece una introducción simplificada al concepto de salto.

La tecnología de unión homomórfica , que se puede aplicar a Bitcoin , es igualmente aplicable a Litecoin, Liquid y otras cadenas basadas en UTXO. Como se mencionó anteriormente, tanto en los sistemas RGB como RGB++, el beneficiario es un UTXO de Bitcoin, dotado con la autoridad exclusiva para gastar. Cuando creo una transacción RGB++ en Bitcoin, tengo la opción de designar al beneficiario no como Bitcoin UTXO, sino como Litecoin UTXO. En consecuencia, este activo 'salta' a Litecoin, ya que su posterior gasto requiere su desbloqueo mediante un Litecoin UTXO. De manera similar, este activo puede saltar a Liquid o incluso regresar a Bitcoin.

Por supuesto, hay un caso especial a considerar. Cuando un activo salta a la cadena de bloques CKB, su capa de interpretación de datos, su capa de contrato y su propiedad están todos en CKB. Esto significa que ya no depende de ninguna otra cadena y puede realizar transacciones directamente e interactuar con contratos inteligentes en CKB. Esto puede describirse como saltar a L2. En L2, los usuarios pueden realizar miles o incluso decenas de miles de transacciones hasta que alguien decida devolver el activo a Bitcoin. Esto es lo que llamamos plegado de transacciones. Ya sea RGB o RGB++, las transacciones se realizan en la cadena de bloques de Bitcoin, donde las tarifas de minería son caras. Sin embargo, una vez que un activo salta a CKB y se somete a una transacción, las tarifas se vuelven significativamente más bajas y puede regresar fácilmente a la cadena de bloques de Bitcoin en cualquier momento. Todo este proceso no depende de ningún puente de firmas múltiples ni de la confianza en ningún individuo; el único requisito es esperar algunas confirmaciones de bloques más. Saltar de la cadena de bloques de Bitcoin a la cadena de bloques de CKB requiere esperar 6 confirmaciones de bloques de Bitcoin. Para volver de la cadena de bloques CKB a Bitcoin, se necesitan 24 confirmaciones de bloques CKB para evitar reversiones de bloques.

Por eso decimos que hemos introducido un nuevo paradigma. Por supuesto, este no es un invento nuestro, sino más bien una idea que existía en los primeros materiales de RGB, donde los activos RGB podían saltar entre diferentes cadenas UTXO. Después de combinar la integridad de Turing con el salto a CKB, descubrimos que las aplicaciones potenciales son extensas y muy diferentes de la narrativa tradicional de los puentes de firmas múltiples de Ethereum.

Perspectivas de futuro

A continuación, analicemos la escalabilidad. La tasa de transacción de Bitcoin es de aproximadamente 7 transacciones por segundo (TPS), mientras que CKB alcanza un máximo de alrededor de 200 TPS. Si se tienen en cuenta los costos de ejecución del contrato y validación de scripts, el TPS podría reducirse a aproximadamente 50, lo que es menos de diez veces una expansión en comparación con Bitcoin. Esto no es suficiente, entonces, ¿cuáles son las opciones para ampliarlo? Vemos dos direcciones principales:

• Canales estatales : los canales estatales representan una solución de escalamiento definitiva, que ofrece un techo de muy alto rendimiento. Sin embargo, el desafío radica en la complejidad de implementar contratos multipartitos, lo que hace que los canales estatales sean más adecuados para transacciones de pago e interacciones entre individuos y servidores. Jan encabezará el equipo para promover la investigación en los canales estatales.

  
  

• AppChain Stack : al construir una solución de Capa 2 (L2) basada en el modelo UTXO, L2 AppChain asegurará su anclaje en CKB, alineándose isomórficamente con él. Este enfoque nos permite desarrollar estrategias de escalamiento innovadoras dentro de este nuevo paradigma. Este también es un enfoque clave para CELL Studio durante el próximo año.

  
  

Por último, me gustaría resumir la misión y la hoja de ruta de RGB++. RGB++ tiene como objetivo desarrollar módulos de protocolo fundamentales para facilitar el uso y la integración por parte de desarrolladores y usuarios externos. La hoja de ruta del protocolo RGB++ es la siguiente, y el protocolo ya está activo en la red principal de Bitoin y el SDK RGB++ se lanzó el 3 de abril.

Por Cipher, fundador de CELL Studio y autor del protocolo RGB++.