Explorando Soluciones de Escalado de Bitcoin: RGB

[Jose]

Nos complace comenzar una serie de artículos centrados en las soluciones de escalado de Bitcoin (BTC). Nuestro objetivo es simplificar y explicar estas tecnologías, mostrando cómo pueden hacer blockchain más rápido y más eficiente.

Planeamos cubrir todo, desde Lightning Network hasta rollups, sidechains y más, con el objetivo de darte una clara comprensión de cómo funciona cada una, sus beneficios para la velocidad y el costo, y cómo pueden escalar. En este post, nos centraremos en explorar la Solución de Escalado Bitcoin de RGB.

Este artículo también está publicado en Medium：
Explorando las soluciones de escalado de Bitcoin: RGB
Explorando las soluciones de escalado de Bitcoin: RGB++

RGB

Visión general

RGB es una plataforma de contratos inteligentes de vanguardia que aprovecha la blockchain de Bitcoin para permitir la ejecución de contratos inteligentes. Funciona a través de un paradigma de validación del lado del cliente, asegurando que los datos se almacenan fuera de la blockchain principal y la propiedad se gestiona con la robusta seguridad de los scripts de Bitcoin. Este enfoque innovador pretende ofrecer una alternativa avanzada a los sistemas tradicionales de contratos inteligentes basados en Ethereum.

Al desacoplar las funciones de los emisores de contratos, los propietarios y la evolución de los estados de los contratos, RGB crea un ecosistema multicapa que no solo es escalable y privado, sino también muy seguro para gestionar activos digitales y desarrollar aplicaciones descentralizadas.

Exploración rápida de RGB

En esta sección, nos centraremos en lo esencial y mantendremos los detalles técnicos al mínimo, para que el funcionamiento del protocolo sea fácil de entender.

Lo Básico

Las Salidas de Transacciones No Gastadas (UTXOs) son un concepto básico en el universo Bitcoin. Si no conoce este término, puede profundizar en el en esta entrada de la wiki. Por ahora, mantengamos la explicación a alto nivel.

El diseño de RGB como plataforma de contratos inteligentes está estrechamente vinculado a los UTXO. Para ilustrarlo, imagine que se emiten 100 unidades de un activo en la plataforma RGB. Estos activos están vinculados a un UTXO específico. Cuando el propietario del UTXO gasta ese UTXO, él (o ella) puede dictar el flujo de activos RGB dentro de la transacción (este mecanismo se conoce en RGB como propiedad). El siguiente diagrama proporciona una visión:

UTXO1 contiene 100 activos RGB. Una vez gastados, se transforman en UTXO2 y UTXO3 (indicados por flechas negras). La transacción también esboza la transferencia de activos RGB (flechas rojas), dividiendo las 100 unidades en 30 y 70 porciones, respectivamente vinculadas a UTXO3 y UTXO4.

Los contratos RGB están diseñados para ser versátiles, permitiendo que la lógica sea independiente de las transacciones UTXO. Esto significa que el movimiento de activos RGB no está necesariamente ligado al gasto de UTXOs.

Dado que un UTXO sólo puede gastarse una vez, cualquier activo RGB asociado a el también puede transferirse una sola vez. La seguridad de Bitcoin garantiza que los UTXO están a salvo del doble gasto y, por extensión, también lo están los activos RGB, salvaguardando la integridad del protocolo.

Este enfoque innovador se conoce en el protocolo RGB como sellos de un solo uso.

Indicando Operaciones RGB en Bitcoin

Para mantener la privacidad y mejorar las capacidades de los contratos inteligentes, RGB no graba las operaciones en texto plano en el script de Bitcoin. En su lugar, envía un valor hash asociado con la operación real al blockchain (denominado “compromiso”). Los participantes del protocolo RGB pueden entonces validar si el compromiso en la cadena de bloques coincide con la operación prevista fuera de la cadena.

No vamos a entrar aquí en la mecánica de cómo se envían los compromisos. Sin embargo, es importante señalar que el valor de compromiso correspondiente siempre estará presente en la cadena de bloques.

Este enfoque garantiza la privacidad de las transacciones RGB. Los no participantes en el protocolo RGB sólo pueden ver el siguiente comportamiento en la cadena:

Como el valor hash no puede invertirse para revelar la operación RGB original, quienes no participan en la transacción RGB desconocen la existencia de los activos.

Además, como en la cadena de bloques sólo se registra el valor hash de la operación, el tamaño de los datos presentados es siempre pequeño. Este enfoque permite realizar operaciones complejas fuera de la cadena con un costo mínimo.

Verificación del lado del cliente

El núcleo de la seguridad de RGB reside en el envío de valores hash a la cadena de bloques. El proceso de verificación de estos hashes durante las transacciones es crucial. RGB emplea una estrategia conocida como “verificación del lado del cliente” para mantener la integridad de las transacciones. Todos los datos asociados a RGB se almacenan fuera de la cadena, donde son gestionados por las partes implicadas en la transacción. Estas partes son responsables de la transmisión de los datos y, una vez recibidos, pueden verificar la legitimidad de la transacción en su cliente local.

Veamos una ilustración simplificada para comprender el papel de la verificación del lado del cliente ( por favor, ten en cuenta: esta ilustración no es una representación exacta de todos los entresijos del protocolo RGB).

Utilizando el ejemplo anterior, Bob, propietario de UTXO1, desea transferir 70 activos RGB a Alice, que posee UTXO4.

• En el transcurso de la transacción, se crean datos adicionales, datos2, y Alice recibe todos los datos de Bob, incluidos datos0, datos1 y los datos2 recién generados.
• Examinando los datos RGB (data0, data1, y data2), Alice puede rastrear los cambios de estado de los activos RGB (la línea azul punteada).
• Alice comprueba entonces la presencia de un hash de los datos RGB (data2, data1, etc.) en la blockchain y confirma si la transacción asociada ha sido validada por la red Bitcoin, asegurando así la autenticidad de los datos (la línea punteada verde). Alice debe confirmar la validez de todos los datos RGB desde el despliegue del contrato (correspondiente a la transacción en la cadena de datos0, no representada en la ilustración) hasta la transacción más reciente. Bob realiza un proceso de verificación idéntico cuando Alice recibe los activos.

El enfoque del cliente respecto a la privacidad es bastante estricto. Merece la pena señalar que incluso el ejecutor original del contrato RGB, sin acceso a los datos2, sería incapaz de discernir la transacción entre Bob y Alice.

Confianza y seguridad

Dada la importancia de la seguridad, discutiremos los diversos componentes del protocolo y las aplicaciones en las que los usuarios deben depositar su confianza, proporcionando un análisis desde la perspectiva de la “confianza”.
A menos que se indique lo contrario, asumimos que los algoritmos criptográficos básicos utilizados en el protocolo son fiables, sin tener en cuenta el impacto potencial de los ordenadores cuánticos.

• Los usuarios deben confiar en la red Bitcoin:

1. • Las transacciones en la red Bitcoin deben ser seguras frente al doble gasto; de lo contrario, los activos de RGB también podrían estar en peligro.
2. • Las transacciones de Bitcoin deben permanecer sin censura; de lo contrario, las transacciones de RGB podrían ser bloqueadas para ser añadidas a la cadena.

• Los usuarios deben confiar en el mecanismo de ejecución fuera de la cadena de RGB, incluyendo la máquina virtual y el diseño de los contratos inteligentes. Los activos RGB están vinculados a UTXOs, y mientras que sólo los valores hash de las operaciones RGB se envían a la blockchain, no hay interacción directa con los scripts de Bitcoin. En consecuencia, la blockchain no puede confirmar la validez de las transacciones RGB de ninguna manera. Si el mecanismo de ejecución fuera de la cadena encuentra un error (como un error de codificación en el motor o un fallo en la lógica del contrato), podría dar lugar a la creación de estados no válidos fuera de la cadena o a una discrepancia entre los hashes enviados y el estado RGB real. En tales casos, una vez gastada la transacción UTXO, el estado en posesión del usuario podría no ser verificable, lo que podría dar lugar a una pérdida de activos.

El protocolo RGB minimiza la confianza requerida a los usuarios. Los usuarios pueden verificar de forma independiente casi todos los aspectos del protocolo para garantizar su correcto funcionamiento. Sin embargo, esto también impone ciertas responsabilidades a los usuarios, que tienen que llevar a cabo localmente un almacenamiento de datos y una verificación bastante pesados.

Información adicional

Máquina virtual

RGB ha desarrollado una máquina virtual Turing-completa conocida como AluVM, mejorando sus capacidades.

Escalabilidad

Las transacciones de RGB están vinculadas a las de Bitcoin, lo que puede afectar al rendimiento del sistema. Para solucionarlo, se ha introducido el Bifrost protocol como mejora de la red Bitcoin Lightning, que facilita los pagos de RGB a través de la red.

TVL

Dadas las características de privacidad inherentes al RGB, el seguimiento del Valor Total Bloqueado (TVL) no es factible con los métodos actuales.

Visión general de RGB: Ventajas y desventajas

Ventajas:

• Privacidad: Los envíos de RGB en la cadena se limitan a hashes, lo que garantiza la privacidad de las transacciones mediante un sistema de verificación del lado del cliente. Sólo las partes implicadas en la transacción tienen acceso a sus detalles.
• Costes en la cadena para contratos complejos: Dado que sólo se envían valores hash a la cadena, los costes asociados en la cadena se desvinculan de la complejidad del contrato.
• Confianza: El protocolo exige una confianza adicional mínima; los usuarios tienen los medios para verificar casi todos los aspectos del protocolo.

Desventajas:

• Almacenamiento de datos: Los usuarios son responsables de almacenar los datos RGB asociados a sus transacciones. Si estos datos se pierden, puede producirse la pérdida de activos.
• Las transacciones requieren la coordinación entre varias partes. Si una de las partes no está conectada, la transacción no puede continuar, lo que complica el diseño del cliente.
• Costes de verificación elevados: Con cada transacción, los clientes deben realizar verificaciones de estado. A medida que crece el volumen de transacciones, la carga de verificación asociada puede llegar a ser significativa, aumentando potencialmente los requisitos de almacenamiento local o los costos de red al interactuar con nodos RPC u otros servicios.

Estos retos asociados al RGB pueden aumentar la complejidad del desarrollo de clientes y elevar la barrera para la adopción por parte de los usuarios.

Más detalles

En esta sección, profundizaremos en aspectos del protocolo que son menos críticos, pero que siguen siendo importantes para los lectores que deseen entender los pormenores técnicos.

Replicación de máquinas de estado y motores de computación fuera de la cadena

Uno de los retos fundamentales de la tecnología blockchain es garantizar que todos los nodos mantengan un libro de contabilidad coherente. Comenzaremos analizando un enfoque ampliamente adoptado conocido como “replicación de máquinas de estado”, que utilizan Bitcoin y otras cadenas de bloques para lograr la tolerancia a fallos. Este método se utiliza ampliamente en sistemas distribuidos para resolver el problema de la consistencia entre múltiples copias. Por ejemplo, tanto las bases de datos distribuidas como las cadenas de bloques funcionan según este principio. El proceso es sencillo:

1. Cada copia se inicializa con un estado específico como punto de partida.
2. Las transiciones de estado se producen del siguiente modo:
   . 1. Antes de recibir una nueva entrada, el estado de cada copia permanece inalterado.
   . 2. Al recibir la entrada i en el estado s, la copia pasa a un nuevo estado s’. Esta transición es determinista, lo que significa que, dada la misma entrada i y el mismo estado s, el estado s’ resultante será coherente en todas las copias.
3. Al garantizar que todas las copias comienzan con el mismo estado inicial s0 y procesan las mismas entradas (i0, i1, i2…in) en el mismo orden, sus estados finales se alinearán.

En el contexto de Bitcoin, nos referimos a este “estado” como todas las Salidas de Transacciones No Gastadas (UTXOs) dentro del sistema.

1. Cada nodo Bitcoin comienza con el bloque génesis como estado inicial.
2. Las transiciones de estado se gestionan de la siguiente manera:
   . 1. El estado del libro mayor permanece sin cambios hasta que se recibe una nueva transacción (bloque).
   . 2. Tras la recepción de una nueva transacción (bloque), el libro mayor pasa a un nuevo estado. Este proceso es determinista; dado el mismo estado del ledger y la misma transacción (bloque), el estado resultante del ledger será consistente.
3. Siguiendo este método, siempre que todos los nodos comiencen con el bloque génesis y procesen transacciones (bloques) en la misma secuencia, sus respectivos estados del libro mayor acabarán coincidiendo.

El principal reto consiste en garantizar que todos los nodos estén de acuerdo en el orden de las transacciones (bloques), que es la esencia del consenso y la base para evitar los ataques de doble gasto en la cadena de bloques.

El motor de computación fuera de la cadena de RGB aprovecha el mecanismo de consenso de Bitcoin para mantener el orden de las transacciones, evitando así el doble gasto. Los estados y las transiciones se gestionan fuera de la cadena de bloques principal. Este enfoque tiene la ventaja de separar la capa de ejecución de la capa de consenso, lo que permite la expansión funcional sin necesidad de actualizaciones de la blockchain. Sin embargo, esto también significa que la capa de consenso no realiza la validación lógica durante las transacciones. Si los datos enviados a la cadena de bloques entran en conflicto con la lógica del motor de transacciones fuera de la cadena, la transacción no será rechazada, lo que podría provocar la pérdida de activos. Algunos pueden argumentar que RGB es “parasitario” en Bitcoin, pero también puede funcionar en otras blockchains que utilizan UTXOs.

Protocolos como Inscription y Rune siguen un modelo similar, pero se enfrentan al reto adicional de la falta de una implementación estandarizada en las primeras etapas del ecosistema. Con diferentes implementaciones de motores de ejecución fuera de la cadena (indexadores), verificar los resultados puede resultar difícil.

Esquemas de compromiso

Los esquemas de compromiso son conceptos criptográficos que permiten a un individuo comprometerse con un valor, ocultarlo inicialmente y revelarlo más tarde. Estos esquemas tienen dos propiedades fundamentales:

• El valor comprometido corresponde a un ÚNICO valor original. En RGB, un compromiso en la blockchain corresponde a una operación única, lo que garantiza que se evite el doble gasto. Esta propiedad se conoce como vinculación.
• Es imposible que otros deduzcan el valor comprometido a partir del compromiso. En RGB, los observadores no pueden determinar la operación específica asociada a un compromiso en la blockchain, preservando la privacidad. Este aspecto se denomina ocultación.

El hashing es una técnica frecuentemente utilizada para diseñar esquemas de compromiso. Por ejemplo, el árbol de Merkle, un concepto bien conocido en la tecnología blockchain, es un tipo de esquema de compromiso. Los compromisos también se utilizan habitualmente en otras aplicaciones de blockchain, como el proceso de registro en dos fases de ENS, que ayuda a evitar que otros se adelanten en el registro de nombres de dominio.

Prueba de publicación

Una preocupación en la validación del lado del cliente de RGB podría ser que los participantes en la transacción no tengan acceso al estado global de los activos. Por ejemplo, mientras que Bob puede tener 100 activos, podría haber 200 activos en circulación. ¿Cómo garantiza el sistema que la ejecución del contrato no dé lugar a problemas en tales circunstancias?

RGB aborda esta cuestión con un concepto conocido como “prueba de publicación”. La idea central es que la verificación de estados en sistemas distribuidos no requiere la ejecución global por parte de todos los participantes. En su lugar, implica que las partes pertinentes verifiquen transiciones de estado específicas. En este enfoque, las transiciones de estado no se difunden globalmente, sino que se codifican en un breve compromiso criptográfico una vez que las partes implicadas reconocen el cambio (por ejemplo, mediante firmas). Como se ilustra en el diagrama siguiente, mientras que el estado global del contrato G incluye todos los nodos rojos y grises (que representan transacciones históricas), para verificar el estado del nodo P sólo es necesario examinar los nodos rojos pertinentes.

Es importante señalar que este diseño también impone ciertos requisitos al diseño de los contratos inteligentes.

Recursos relacionados

• Papel negro de RGB
• Sitio web de RGB
• Investigación de CoinEx: Breve Análisis de RGB: Un Protocolo de Contrato Inteligente Escalable y Confidencial Construido sobre Bitcoin
• Diapositivas de la presentación de RGB

RGB++

Visión general

RGB++ es una extensión del protocolo RGB, introducido por el equipo Cipher de Nervos CKB. Nervos CKB es una cadena de bloques pública que utiliza un modelo basado en UTXO, denominado “Células” dentro de su marco. Basándose en el protocolo RGB, RGB++ mapea la estructura UTXO de RGB a las Células de Nervos CKB, aprovechando las restricciones de escritura tanto en las redes CKB como Bitcoin para garantizar la exactitud de los cálculos de estado y la legitimidad de las transferencias de propiedad. El objetivo de RGB++ es abordar los retos técnicos a los que se enfrenta el protocolo RGB original en escenarios del mundo real, descargando la carga de trabajo del lado del cliente en la cadena de bloques CKB.

Descripción general del protocolo

Para mantener la accesibilidad, en esta sección evitaremos profundizar en los complejos tecnicismos del protocolo. En su lugar, explicaremos el funcionamiento del protocolo de forma sencilla.

Cómo funciona

Como extensión de RGB, es aconsejable familiarizarse con el protocolo RGB antes de continuar. La esencia de RGB++ es el cambio del enfoque tradicional de validación del lado del cliente a un modelo en el que todos los datos se publican abiertamente en la blockchain CKB de Nervos, con CKB sirviendo como motor de ejecución. Seguiremos utilizando un ejemplo del protocolo RGB para ilustrarlo, como se muestra en la siguiente figura( Por favor, tenga en cuenta: Esta figura es una representación simplificada del funcionamiento básico de RGB++ sólo con fines ilustrativos).

En el ejemplo, Bob transfiere 70 activos RGB a Alice. A diferencia de la anterior verificación del lado del cliente, todos los datos relacionados con RGB están ahora disponibles públicamente en la cadena CKB, con CKB asumiendo el papel de motor de ejecución para gestionar y mantener el estado del contrato RGB.

• Bob puede verificar fácilmente a través de Nervos CKB que tiene 100 activos RGB asociados a su UTXO1.
• Cuando Bob envía activos a Alice, no hay necesidad de compartir datos0 y datos1 con ella; Alice puede acceder independientemente al estado actual del contrato o a los datos históricos en la blockchain.
• Una vez confirmada la transacción Bitcoin que incluye el compromiso(0x345AB…D7654), Bob puede enviar una transacción con los datos RGB (data2) a CKB. Los nodos CKB, que ejecutan una versión ligera del nodo Bitcoin, verificarán la existencia del compromiso en la red Bitcoin.
• Después de que CKB procese la transacción, Alice puede ver que ahora tiene 70 activos RGB en su UTXO4.

Como resultado, la cadena CKB se encarga ahora de la mayoría de las funciones que antes gestionaba el cliente en el protocolo RGB. Esta transición reduce significativamente la carga de almacenamiento y verificación de datos para los usuarios. Sin embargo, este enfoque conlleva una contrapartida: disminuye el nivel de privacidad inherente al protocolo RGB original.

Detalles del proceso de transacción

El libro blanco del protocolo RGB++ ofrece una explicación detallada del proceso de transacción, que utilizaremos aquí, complementada con el diagrama anterior.

• Computación fuera de la cadena
  . * Bob elige el siguiente UTXO que se utilizará para la transacción de BTC, como UTXO1.
  . * Bob realiza la computación fuera de la cadena para crear una transacción RGB++ para su envío a la red CKB: CKB_TX. Esta transacción incluye los datos necesarios para los cambios en el estado RGB.
  . * Bob calcula un valor de compromiso fuera de la cadena commitment(0x345AB…D7654).

• Envío de la transacción BTC
  . * Bob crea y envía una transacción Bitcoin que gasta UTXO1, incorporando el compromiso antes commitment(0x345AB…D7654) a través de una operación OP_RETURN.

• Envío de la transacción CKB
  . * Bob envía CKB_TX a la red CKB.
  . * El estado de usuario más reciente se conserva en CKB_TX.output.data.
  . * El cambio de estado posterior (por parte de Alice) requerirá UTXO4 y la salida de CKB_TX.

• Verificación de la cadena
  . * El UTXO1 de Bitcoin se utiliza sólo una vez.
  . * A través de un Nodo Bitcoin Light, CKB verifica el valor del compromiso en la red Bitcoin y asegura que el UTXO apropiado ha sido gastado.
  . * CKB confirma que la transición de estado del contrato en su red se adhiere a las reglas predefinidas del contrato.

Confianza y seguridad

Dado que la seguridad es un aspecto fundamental de todo protocolo blockchain, analizaremos desde la perspectiva de la “confianza” los componentes del protocolo y las aplicaciones en los que los usuarios necesitan confiar, y proporcionaremos un análisis.
A menos que se indique lo contrario, consideramos que los algoritmos criptográficos clásicos utilizados en el protocolo son de confianza (sin tener en cuenta los ordenadores cuánticos).

• Los usuarios deben confiar en la red Bitcoin.
  . * Las transacciones en la red Bitcoin no deben ser de doble gasto; de lo contrario, los activos RGB(++) también estarían en riesgo de doble gasto.
  . * Las transacciones en la red Bitcoin no deben estar censuradas; de lo contrario, las transacciones RGB(++) podrían no quedar registradas en la blockchain.
• Los usuarios deben confiar en el mecanismo de ejecución de transacciones de la red CKB por las mismas razones que con RGB.
• Los usuarios deben confiar en que la red CKB accederá a transacciones Bitcoin recientes para su verificación. De lo contrario, podrían registrarse estados ilegales en la blockchain.
• Los usuarios deben confiar en que la red CKB no censurará sus transacciones. Si la transacción de un usuario es censurada y no puede ser registrada en la blockchain, no recibirán los resultados de la ejecución de la transacción. Sin embargo, en tales casos, el protocolo puede revertir de RGB++ a RGB, volviendo a habilitar el paradigma de validación del lado del cliente para calcular los resultados de la transacción fuera de línea.
• Los usuarios deben tener un cierto nivel de confianza en la consistencia de la red CKB (la consistencia puede entenderse como si las transacciones confirmadas se revertirán).
  . * Al igual que ocurre con el compromiso en Bitcoin, los atacantes malintencionados no pueden construir otra transacción CKB con un contenido de ejecución diferente. Los usuarios no necesitan preocuparse por el doble gasto de activos RGB debido a inconsistencias en la red CKB.
  . * Sin embargo, los usuarios deben tener en cuenta que si la red CKB experimenta un retroceso, podría provocar la pérdida de los datos de la transacción. Si los usuarios no han guardado los datos de las transacciones pertinentes, esto podría provocar la pérdida permanente de los datos RGB++.

Cabe señalar que el análisis de confianza anterior no tiene en cuenta las características ampliadas previstas por el proyecto RGB++, como el “plegado de transacciones” y las “celdas de estado global”.

Resumen de RGB++: ventajas y desventajas

RGB++ es una extensión de RGB, analicemos los puntos fuertes y débiles de RGB++ en comparación con su predecesor.

Ventajas:

• Ya no es necesario que los usuarios almacenen los datos ellos mismos; CKB se encarga del alojamiento de los datos.
• La mayoría de las responsabilidades del entorno de ejecución son gestionadas por CKB, lo que permite a los usuarios acceder al estado más reciente del contrato RGB directamente desde la cadena CKB sin necesidad de iniciar cada vez todo el proceso de datos RGB.
• CKB verifica las transacciones automáticamente a través de los nodos ligeros de Bitcoin, eliminando la necesidad de que los usuarios realicen su propia verificación.

Desventajas:

• La privacidad de las transacciones se ve comprometida.
• La ejecución de transacciones complejas está restringida, ya que las transacciones deben procesarse en CKB. Además, deben pagarse tasas por transacción en función de la complejidad de las mismas.
• Se depositará una confianza adicional en la cadena CKB.

Aunque RGB++ no conserva totalmente las ventajas de RGB, sí mejora significativamente la usabilidad del protocolo al sacrificar algo de privacidad y requerir un grado de confianza adicional por parte de los usuarios.

Como solución de escalabilidad para Bitcoin, las ventajas y desventajas de RGB++ son las siguientes:

Ventajas:

• Confianza: La cadena CKB actúa como un motor informático público por debajo de la cadena Bitcoin, asumiendo la responsabilidad de verificar y ejecutar el protocolo sin necesidad de puentes entre cadenas. La confianza adicional requerida por el protocolo es mínima, permitiendo a los usuarios determinar fácilmente si la cadena CKB está actuando maliciosamente, con la opción de volver a la verificación del lado del cliente si es necesario.

Desventajas:

• La solución no aborda eficazmente la cuestión de la escalabilidad. (El plegado de transacciones propuesto en el RGB++ Light Paper puede mitigar en cierta medida este problema; para más información, se anima a los lectores a explorar el contenido posterior).

Para más detalles

En esta parte, trataremos aspectos del protocolo que son menos críticos pero que merece la pena explorar para aquellos que sientan curiosidad por los entresijos técnicos.

Enlace isomórfico

No hemos profundizado en la arquitectura específica de Nervos CKB en las secciones anteriores. Otras cadenas de bloques, como las cadenas compatibles con EVM de Turing-completo, también pueden lograr funcionalidades similares. Una discusión concisa sobre este tema se puede encontrar en el apéndice.

La capacidad del CKB para actuar como motor de computación de RGB se ve muy reforzada por la naturaleza isomórfica de sus Células a los UTXOs de Bitcoin(RGB). Esto permite al CKB adoptar muchos diseños del protocolo RGB, como el mecanismo de prueba de publicación, que ayuda a evitar la contención de estados y permite que los cálculos RGB se realicen sin conexión, reduciendo la dependencia de la cadena CKB.

Transacción Folding

Con RGB++, es posible comprometer en Bitcoin múltiples transacciones CKB en lugar de sólo una. Este enfoque puede crear un efecto similar al de ROLLUP, mejorando la escalabilidad del sistema.

Estado compartido y sus riesgos de seguridad

Para potenciar las capacidades del contrato, RGB++ introduce el concepto de “célula de estado global”. El libro blanco “Shared State and Unhosted Contracts” de RGB++ explica esta característica:

Consideremos una célula de estado global en el CKB que gestiona el estado compartido por múltiples usuarios. Típicamente, podría ser un contrato de estaca para una stablecoin algorítmica, donde los usuarios depositan activos volátiles y reciben una prueba de depósito. El estado global se gestiona mediante un contrato no hospedado, lo que significa que cualquiera puede realizar cambios en el estado sin necesidad de firmas digitales específicas de los firmantes designados. La implementación de un contrato no alojado desempeña un papel crucial en la descentralización y la resistencia a la censura del protocolo.

Una implementación mediocre en este contexto significa que existe el riesgo de que la celda de estado Global esté ocupada por otro usuario, causando que el CKB TX falle porque el estado Global utxo especificado no existe. Como el Bitcoin TX necesita ser enviado y computado en el compromiso antes del CKB TX, la validación posterior se hace imposible.

Para solucionar el problema anterior, introducimos la Intent Cell como intermediario. Los usuarios pueden escribir de forma determinista las acciones que desean ejecutar en la Célula de Intención, que puede interactuar con la Célula de estado global a través de la colaboración de un agregador de terceros, procesando por lotes la intención de múltiples partes y fusionando los resultados de la interacción en una célula sombra estándar.

Este enfoque, sin embargo, introduce posibles problemas de seguridad. El diseño de la prueba de publicación en RGB sólo garantiza un orden parcial de las transiciones de estado, no un orden total, que es suficiente para la seguridad del protocolo.

Cuando se introducen elementos como el estado global, esto cambia la dinámica, ya que el orden de revelación de las transacciones A y B en diferentes caminos puede influir en el resultado.
Consideremos el siguiente escenario:

1. Ambas transacciones A y B han tenido sus compromisos registrados en la cadena BTC.
2. La transacción CKB para A no se ha registrado debido a algún problema, como un ataque de censura en la cadena CKB.
3. La transacción B ya ha alterado el estado global tras su ejecución.
4. Si la transacción A se registra finalmente en CKB, puede dar resultados diferentes o incluso fallar, lo que podría provocar la pérdida de activos.
   
   
   
   La solución Intent Cell presentada en el libro blanco no aborda plenamente esta cuestión. Aunque garantiza que las transacciones enviadas a CKB se ejecuten, no garantiza que el resultado de la ejecución de A y B sea el esperado. En el protocal RGB original, mientras el cliente construya correctamente la transición de estado y el compromiso, el contrato funciona como se espera. Sin embargo, en RGB++, el resultado de la ejecución de la transacción del compromiso realizado primero en Bitcoin está ahora controlado por CKB, mientras que, degradando la “seguridad de Capa1” original. Incorporar la celda de estado global en RGB podría no ser una elección segura.

Recursos relacionados

• Protocolo RGB++ Light Paper
• Especificación del contrato RGB

Apéndice: Discusión sobre la construcción de un motor de ejecución RGB Pseudocódigo en EVM
Mencionamos en el texto que un EVM Turing-completo también puede servir como motor de ejecución para la arquitectura RGB. A continuación se muestra una implementación en pseudocódigo de un contrato de demostración para desplegar un motor de ejecución similar a RGB+± en una cadena EVM.

BTC_STATE es un contrato especialmente implementado que suponemos puede (a través de un nodo ligero) leer información confirmada sobre el Bitcoin. Al mismo tiempo, cualquiera puede hacer público manualmente el valor de compromiso de una transacción a través de la función openCommitment de RGB_CONTRACT, utilizando el EVM como motor de ejecución para ejecutar transacciones RGB. Aquí, asumimos que el valor de compromiso de la transacción se envía a la cadena.

// BTC_STATE can read bitcoin confirmed state
contract BTC_STATE {
  stuct TXO {
    uint256 btcTxId;
    uint256 outputIndex;
  }
  // a bitcoin tx will have at most 1 OpReturn
  function readBitcoinOpReturn(uint256 btcTxId) returns (bytes);
  // or
  function readBitcoinTransactionOutputScript(TXO txo) returns(bytes);

  function isBitcoinTransactionOutputSpent(TXO txo) returns(boolean);
  // ...
  function readBitcoinOrdinalIndex(TXO txo, uint256 satoshiIndex) returns (uint256);
  // ...
  function readBitcoin...(uint256 btcTxId) returns (bytes);
}

contract RGB_CONTRACT {
  struct RGB_DATA {
    TXO input; // could be multiple, only for reference
    TXO output; // could be multiple, only for reference
    bytes payload;
  }
  mappinp(uint256 => bytes) utxoStatus;
  mappinp(uint256 => boolean) utxoPermission;
  function openCommitment(RGB_DATA calldata data, bytes32 salt) public {
    isValidOpen(data, salt);
    utxoPermission[calcTxoHash(data.input)] = false;
    utxoPermission[calcTxoHash(data.output)] = true;
    execute(data.payload);
  }
  function calcTxoHash(TXO txo) pure returns (uint256);
  function calcCommitment(RGB_DATA calldata data, bytes32 salt) pure returns (bytes32);
  function execute(bytes payload) internal;
  function isValidOpen(RGB_DATA calldata data, bytes32 salt) {
    require(utxoPermission[calcTxoHash(data.input)], "from utxo should have permission");
    require(
      calcCommitment(data, salt) == BTC_STATE.readBitcoinOpReturn(data.input.btcTxId)
    );
    _;
  }
}

Información en inglés: Exploring Bitcoin Scaling Solutions: RGB