Antecedentes

El rendimiento de Bitcoin ha sido observado de cerca desde que la criptomoneda se lanzó en 2009. Como solo puede procesar siete transacciones por segundo, la red no permite contratos inteligentes escalables. La actualización SegWit aumentó el límite de tamaño de bloque de Bitcoin a 4MB (1MB para datos de transacciones y 3MB para datos de testigos); sin embargo, la limitación aún persiste. Mientras tanto, a medida que la influencia de Bitcoin crece, el desafío de escalabilidad se ha vuelto más agudo. La escalabilidad sigue siendo un reto fundamental al que se enfrenta el ecosistema Bitcoin. Hoy en día, los profesionales están explorando soluciones con diferentes enfoques, que incluyen principalmente:

Cadenas laterales incluyendo Liquid, Stacks, Rootstock, etc.;
Canales de estado como la Red Lightning que procesan ciertas transacciones altamente frecuentes fuera de la cadena;
Soluciones de escalabilidad no actualizables como RGB y Bitcoin Script que no modifican el código de Bitcoin;
Soluciones de escalabilidad basadas en actualizaciones incluyendo Drivechain (BIP300/301) que requieren un fuerte apoyo de los mineros y logran la escalabilidad a través de bifurcaciones duras.

De los diferentes enfoques, algunas soluciones de escalabilidad tempranas están recuperando atención. Notablemente, Nostr, un protocolo que se volvió viral a finales de 2022, contribuyó a la adopción generalizada de la Red Lightning. Al mismo tiempo, Ordinals experimentó un auge a principios de 2023. Como una solución de contrato inteligente basada en Bitcoin y la Red Lightning que ofrece completitud de Turing, escalabilidad y fuerte protección de la privacidad, RGB lanzó una nueva versión (v0.10) este abril.

Evolución de RGB

El origen de RGB se remonta a 2016, cuando Peter Todd introdujo la noción de sello de uso único y validación del lado del cliente. Sobre la base de estos conceptos críticos, RGB fue propuesto en 2018.

En 2019, Orlovsky, un desarrollador central de RGB, encabezó el desarrollo de RGB y creó muchos componentes que finalmente constituyen el protocolo RGB. Además, el establecimiento de la Asociación LNP/BP en Suiza ayudó a proporcionar los estándares relevantes.

Tras extensos esfuerzos de desarrollo, RGB presentó su versión v0.10 en abril de 2023.

Acerca del diseño de RGB

Así es como RGB logra la escalabilidad y la confidencialidad:

Validación del Lado del Cliente

La mayoría de las cadenas de bloques públicas existentes operan bajo un modelo de consenso global, donde todos los nodos validan todas las transacciones, comparten información de transacciones entre sí y mantienen un estado global unificado.

Sin embargo, este modelo presenta varios desafíos, incluyendo:

Limitaciones de escalabilidad que hacen costosa la validación de todas las interacciones del contrato;
Altos costos que conducen a una operación centralizada de nodos;
Falta de privacidad debido a la información abierta de las transacciones.

La Validación del Lado del Cliente (CSV, por sus siglas en inglés) propone un enfoque alternativo: solo requiere que la capa de consenso cumpla con los compromisos criptográficos asociados con los eventos del libro mayor, mientras almacena la información real del evento (el libro mayor) fuera de la cadena de bloques. Este enfoque, que se origina en el trabajo de Peter Todd, se denomina "Validación del Lado del Cliente". CSV desplaza los datos de la transacción fuera de la cadena, donde la información detallada se almacena y verifica, y solo se envía información mínima en la cadena de bloques. Además, los datos de la transacción se transfieren fuera de la cadena solo entre el remitente y el receptor. Por ejemplo, en una transacción del mundo real, la validación solo se requiere cuando la billetera y las partes solicitan acceso a los datos del contrato.

Características clave de CSV:

La información detallada de la transacción se almacena fuera de la cadena y se valida solo en el cliente;
Solo se almacenan en la cadena los compromisos de los datos de la transacción;
La validación solo se aplica a las transacciones de las que los usuarios deben ser conscientes.

En RGB, el mecanismo de validación para las transferencias de activos difiere significativamente del de Bitcoin. En la red Bitcoin, los nodos siempre están descargando y validando bloques y transacciones del mempool, lo que les permite adquirir el estado más reciente del conjunto UTXO. Al encontrar una nueva transacción, los validadores de Bitcoin verifican la validez de su historial comprobando si todas las entradas existen en el conjunto UTXO más actualizado.

RGB, por otro lado, no depende de una red global que transmita todas las transacciones para crear un equivalente al conjunto UTXO de Bitcoin. Esto significa que al recibir un pago entrante, un cliente RGB no solo debe verificar que la última transición de estado sea válida, sino que también necesita realizar la misma validación para todas las transiciones de estado anteriores hasta el estado génesis en el contrato de emisión. Esta validación ascendente del historial de transacciones en RGB también protege contra ataques de doble gasto.

RGB mejora la escalabilidad al validar solo las transacciones que son relevantes. Sin embargo, este enfoque podría resultar en problemas asociados con una pobre disponibilidad de datos, lo que podría requerir el intercambio de datos para optimizar la validación de pagos.

Sellos de un solo uso basados en Bitcoin

Los sellos físicos de un solo uso son precintos plásticos numerados de manera única que se utilizan comúnmente para detectar manipulaciones durante el almacenamiento y el envío. Por ejemplo, nos permite saber si la puerta de un contenedor de envío se abrió durante el transporte. Los sellos digitales de un solo uso cierran un sello digital sobre un mensaje para asegurar que solo se pueda usar una vez, lo que hace imposible que los vendedores vendan la misma propiedad dos veces.

En lugar de utilizar una entidad de confianza para certificar la apertura y cierre de sellos digitales, es posible utilizar las Salidas de Transacción No Gastadas (UTXOs) de Bitcoin como sellos. Un UTXO puede verse como un sello que se cierra cuando se crea y se abre cuando se gasta. A la luz de las reglas de consenso de Bitcoin, una salida solo puede gastarse una vez; por lo tanto, el sello solo puede abrirse una vez. De esta manera, los sellos de un solo uso se utilizan para asociar los UTXOs de Bitcoin con estados de contrato fuera de la cadena, permitiendo la ejecución de la siguiente transición de estado a través de transacciones RGB fuera de la cadena (cerrando el sello). Similar a los sellos físicos de un solo uso utilizados para asegurar contenedores de envío, un sello digital de un solo uso es un objeto único que sella con precisión una pieza de información para prevenir el doble gasto.

Aquí hay una analogía simple: Podemos pensar en los UTXO como una serie de cheques, cada uno con un monto diferente. Al realizar un pago, básicamente estás pagando a alguien con un cheque sin cobrar. Además, cualquier saldo restante del cheque volverá a ti en forma de un nuevo cheque. En este escenario, los sellos de un solo uso agregan ciertos registros de transferencia al cuadro de información adicional del cheque. Como un cheque solo se puede cobrar una vez, este enfoque previene el doble gasto.

Veamos cómo funciona este proceso entre Alice, Bob y Dave:

Para empezar, Alice ha emitido un activo RGB (por ejemplo, USDT Tether o USDT) con un suministro total de 100 millones, y ha añadido la información de compromiso a un cheque válido (Cheque A) en el cuadro de información adicional. El impresor del cheque no tiene que considerar esta información adicional, y el Cheque A puede tener cualquier valor nominal, siempre que pertenezca a Alice y permanezca sin cobrar.
Cuando Alice quiere transferir 10 millones de USDT a Bob, necesita cobrar el Cheque A e indicar en el cuadro de información adicional que 10 millones de USDT irán a un nuevo cheque (Cheque B) propiedad de Bob y 90 millones de USDT irán a otro nuevo cheque (Cheque C) propiedad de Alice, que contiene los 90 millones de USDT restantes.
Si Bob desea transferir 10 millones de USDT a Dave, necesita cobrar el Cheque B y anotar en el cuadro de información adicional que 10 millones de USDT irán a un nuevo cheque (Cheque D) propiedad de Dave.
El mismo proceso se repite para cada transferencia subsiguiente. Más específicamente, el titular anterior endosa una porción del monto al nuevo receptor, y el receptor luego verifica toda la historia de transferencias de activos. De manera similar a los cheques circulantes, cada transferencia crea un nuevo cheque, y cada cheque solo puede cobrarse una vez (UTXO). Mientras tanto, los cheques antiguos (UTXOs) se vuelven inválidos, asegurando que el estado solo pueda avanzar y no retroceder, lo que también previene el doble gasto. De esta manera, los registros en cadena reflejan de manera confiable los cambios de estado de un criptoactivo.

RGB utiliza el modelo de sello de uso único basado en Bitcoin descrito anteriormente, lo que significa que cuando ocurre una transacción RGB, el remitente crea una transición de estado del contrato que define los derechos que se están transfiriendo. Tomemos el caso de los tokens. Primero, el emisor de un contrato establece el estado génesis que define los detalles del contrato, como el nombre del activo, el suministro total y el UTXO con el derecho de mover el suministro. Luego, a medida que se transfieren los activos por primera vez, el propietario del primer UTXO puede crear una transición de estado que define qué nuevo UTXO será ahora propietario del activo. RGB logra transiciones de estado aprovechando el mecanismo de que los UTXO solo se pueden gastar una vez, lo que le permite definir y rastrear de manera confiable la transferencia de criptoactivos y los cambios en los derechos de propiedad.

RGB mantiene toda la información de la transacción fuera de la red Bitcoin, transfiriéndola exclusivamente entre remitentes y receptores. Mientras tanto, los datos de compromiso están anclados a los UTXO de Bitcoin. Una vez que se gasta un UTXO, no se puede gastar de la misma manera nuevamente, lo que significa un cambio en el contrato.

RGB aprovecha la cadena de bloques de Bitcoin para protegerse contra el doble gasto, y esto se logra comprometiendo cada transición de estado de RGB dentro de la transacción de Bitcoin que gasta el UTXO que posee los derechos que se están moviendo. Se pueden incluir múltiples transiciones de estado en una sola transacción de Bitcoin, pero cada transición de estado solo se puede enviar una vez (de lo contrario, sería posible el doble gasto). Para permitir tener varias transiciones de estado en un solo compromiso, las transiciones de estado se agregan varias veces y luego se envían a la transacción de Bitcoin a través de Taproot o OP_RETURN. Si existen múltiples compromisos en una transacción de Bitcoin, solo el primero será relevante para las reglas de validación de RGB, y los demás serán ignorados, haciendo que cualquier intento de doble gasto sea inútil. Características clave de RGB

Escalabilidad

En comparación con protocolos alternativos que mantienen toda la lógica en la cadena, CSV mantiene los datos fuera de la cadena, reduciendo costos y carga computacional;
RGB está fácilmente disponible en Bitcoin, sin necesidad de modificar el código o realizar transacciones complejas en la cadena;
RGB es compatible con la Red Lightning.

Privacidad

Terceros no pueden observar las transacciones RGB ni sus sellos de uso único;
RGB presenta UTXOs cegados. Un UTXO cegado consiste en el hash de la concatenación entre el UTXO y un secreto de cegamiento aleatorio. De esta manera, el remitente no sabe a dónde fueron los activos, y el nuevo receptor solo puede validar el UTXO cegado cuando gasta el activo;
RGB también utiliza un mecanismo de conocimiento cero llamado Bulletproof. Bajo este mecanismo, los propietarios de activos podrán ver todos los UTXOs que anteriormente poseían un activo, pero no podrán ver la cantidad de activos transferidos en cada transición de estado.

Funciones Versátiles y Casos de Uso de RGB

Esquemas

Los emisores pueden utilizar esquemas RGB, que actúan como plantillas de contratos que se pueden usar para objetivos específicos.

Aquí hay algunos ejemplos:

RGB20 emisión de activos fungibles
RGB21 emisión de activos no fungibles
RGB22 identidades digitales descentralizadas
RGB23 registro de historial único verificable para datos auditables
RGB24 sistema de nombres de dominio global descentralizado
RGB25 emisión de activos coleccionables

Cualquiera es libre de desarrollar su propio esquema para diferentes aplicaciones sin tener que pedir permiso a los desarrolladores de RGB. Sin embargo, se espera que la mayoría de los casos de uso puedan ser cubiertos por unos pocos esquemas principales.

AluVM

RGB emplea AluVM, una máquina virtual RISC basada en registros especialmente diseñada. AluVM es Turing-completa y puede operar el estado global con las mismas garantías de disponibilidad que los sistemas existentes basados en blockchain. Similar a EVM, AluVM presenta una arquitectura que anida un nodo RGB en la parte superior de la Red Lightning, alojando un cliente RGB en los nodos RGB.

Totalmente Compatible con la Red Lightning

Al vincular canales de pago de tokens específicos a la Red Lightning, los activos RGB pueden ofrecer la misma experiencia de usuario y las mismas suposiciones de seguridad que los pagos regulares de la Red Lightning. Esto asegura pagos de bajo costo, rápidos y estables, y puede beneficiar a todo el ecosistema, incluyendo usuarios, desarrolladores y operadores de nodos Lightning.

Comparación con Otras Soluciones

RGB VS TARO

TARO (ahora Activos Taproot), un protocolo Taro respaldado por Taproot, fue introducido por Lightning Labs en abril de 2022 después de recaudar $70 millones en financiación Serie B.

Tanto RGB como TARO se basan en CSV. Como los dos comparten diseños similares, algunos incluso argumentan que TARO se inspiró en RGB. Sin embargo, ahora parece que se enfocan en aspectos diferentes: TARO se concentra en tokens, mientras que RGB apunta a implementar funciones de contratos inteligentes.

Comparación con Otras Soluciones de Bitcoin

A diferencia de Drivechain, que se basa en BIP300 y BIP301 y requiere bifurcaciones duras, RGB es compatible con la tecnología Bitcoin existente y posibles bifurcaciones suaves futuras, sin necesidad de modificaciones en la capa base de Bitcoin.

Ordinals compromete todos los datos en la blockchain, mientras que RGB solo mantiene los compromisos de datos en la cadena. Dada la seguridad proporcionada por los UTXOs, RGB consume un espacio mínimo en la cadena, permitiendo una integración perfecta con la Red Lightning.

RGB VS Rollup

Rollup es una solución de escalado de Ethereum que permite a los usuarios depositar fondos en los contratos inteligentes de Ethereum y luego realizar transacciones con otros usuarios en el mismo Rollup. Estas transacciones se agregan periódicamente y se envían a la blockchain.

Además, RGB no es una cadena de bloques independiente. Desafíos: El ecosistema RGB se encuentra aún en su infancia. Aunque la infraestructura ya está implementada, el ecosistema solo ofrece un puñado de aplicaciones básicas, y puede llevar tiempo hasta que RGB expanda sus herramientas para desarrolladores y su base de usuarios.
Los clientes RGB almacenan datos masivos, y el gasto sería imposible si se perdieran los datos fuera de la cadena necesarios para la validación. Por lo tanto, no es solo la clave lo que debe almacenarse. Además, a diferencia de Bitcoin y otros sistemas de consenso global, los clientes RGB no necesitan ver ni validar todas las transacciones a nivel global. En su lugar, solo tienen que validar las transacciones relacionadas con sus carteras. Esto reduce significativamente la cantidad de datos que cada cliente debe validar, haciendo que todo el sistema sea más escalable. Aunque validar datos masivos al recibir pagos pueda parecer problemático porque una validación lenta significa transacciones len

ما هو بينانس USD (BUSD)؟