RGB refuerza las capacidades de privacidad y escalabilidad de Bitcoin y Lightning Network

TL; DR

• RGB opera como una solución de Capa 2/3 en el paradigma de validación del lado del cliente de Bitcoin y Lightning Network, y alberga todos los datos de contratos inteligentes fuera de las transacciones de Bitcoin. Este diseño garantiza el funcionamiento del sistema sobre Lightning Network, eliminando la necesidad de modificaciones en los protocolos LN.
  
• Los contratos inteligentes RGB están diseñados para brindar escalabilidad y confidencialidad. El sistema admite la propiedad privada y mutua, abstrae y separa preocupaciones, lo que representa una forma post-blockchain, completa de Turing, de computación distribuida sin confianza sin la necesidad de introducir nuevos tokens.
  
• Los contratos RGB están organizados en segmentos separados llamados "fragmentos", cada uno con su propio historial y datos, lo que mejora la escalabilidad y evita la mezcla de historiales de diferentes contratos. Interactúan a través del protocolo Bifrost en Lightning Network, lo que permite cambios coordinados entre múltiples partes, similar a los DEX que operan en Lightning Network.
  
• RGB emplea sellos de un solo uso defined sobre Bitcoin UTXO por seguridad. Cualquier parte que posea el historial del estado del contrato inteligente puede verificar su singularidad, aprovechando el script de Bitcoin para define propiedad y derechos de acceso.
  
• En RGB, la propiedad estatal y la validación son entidades separadas. La propiedad es administrada por el script Bitcoin, un sistema que no pertenece a Turing Complete. Las reglas de validación, por otro lado, están dictadas por el esquema RGB utilizando el script Turing Complete Simplicity/Contractum/Rust.
  
• Cada contrato inteligente RGB está asociado a un estado único mediante sellos de un solo uso. Los sellos y el estado siguen reglas y validaciones específicas fijadas por el creador del contrato, regidas por un “esquema”. Este esquema actúa como un conjunto de reglas para verificar los datos del contrato en el lado del cliente, lo que permite un alto nivel de privacidad y escalabilidad del protocolo.
  
• El diseño de RGB es altamente interoperable con las tecnologías existentes de Bitcoin y Lightning Network, lo que facilita una integración perfecta con estas plataformas y cualquier actualización futura.
  
• A diferencia del estilo de programación imperativo de muchas plataformas blockchain, RGB emplea un estilo declarativo. Este enfoque se centra en delinear el resultado deseado en lugar de detallar los pasos específicos para lograrlo.
  
• RGB utiliza varias tecnologías avanzadas, incluido AluVM para tareas informáticas portátiles deterministas, PRISM para informática de máquinas de estado infinito parcialmente replicadas y Storm para almacenamiento sin confianza basado en depósito de garantía utilizando zk-proofs. Estas tecnologías contribuyen a la solidez, confidencialidad y extensibilidad de RGB.
  
• RGB (v0.10) introduce mejoras notables en la experiencia del usuario y los procesos de integración, optimizando las operaciones y minimizando las dependencias. La versión actualizada presenta una API de biblioteca más unificada y una herramienta de línea de comandos, lo que la hace más accesible y fácil de usar.

Breve descripción

RGB es un protocolo diseñado para emitir tokens en la red Bitcoin con privacidad mejorada y compatibilidad con Lightning Network. Se basa en el concepto de "monedas de colores", como las utilizadas en el protocolo OmniLayer, donde los metadatos en las transacciones de Bitcoin indican una transferencia de token. Por ejemplo, las transacciones de USDT en OmniLayer funcionan como transacciones de Bitcoin aumentadas con datos adicionales que detallan los movimientos de los tokens de USDT. Sin embargo, estos métodos enfrentan limitaciones, como restricciones de tamaño de datos en los resultados de OP_RETURN, escaneo intensivo de blockchain y privacidad restringida derivada de la visibilidad en la cadena.

RGB aborda estos problemas reubicando la mayoría de los procesos de validación fuera de la cadena de bloques de Bitcoin. Adopta validación del lado del cliente y emplea sellos de un solo uso para conectar tokens con los UTXO de Bitcoin, preservando al mismo tiempo la privacidad del usuario.

Los tokens se transfieren mediante la confirmación de un mensaje que contiene información de pago RGB dentro de una transacción de Bitcoin, lo que permite que los tokens se muevan de un UTXO a otro sin dejar rastro en el gráfico de transacciones de Bitcoin. Esto mejora significativamente la privacidad, ya que las transacciones RGB "teletransportan" tokens discretamente, con datos específicos de RGB pasados ​​a través de canales privados fuera de la cadena.

Además, para garantizar la propiedad y evitar la inflación, los receptores deben validar todo el historial de transacciones de los tokens recibidos. RGB permite futuras actualizaciones sin la necesidad de bifurcaciones duras, lo que garantiza que los mineros no puedan rastrear el flujo de activos, lo que proporciona una mayor resistencia a la censura. A diferencia de las estructuras tradicionales de blockchain, RGB opera sin necesidad de bloques o cadenas, lo que lo posiciona como un protocolo descentralizado sin bloques, que promete alta confidencialidad, seguridad y escalabilidad.

Introducción y visión

Un trazador de líneas: Un sistema de contrato inteligente y de estado validado por el cliente que opera en la capa 2/3 en Bitcoin y Lightning Network.

Más detalles:

RGB es un sistema de contratos inteligentes escalable y confidencial para Bitcoin y Lightning Network. Los contratos inteligentes RGB funcionan con validación del lado del cliente paradigma, vivienda todos los datos del contrato inteligente fuera Transacciones de Bitcoin, es decir, blockchain de Bitcoin o estado del canal Lightning. Esto permite que el sistema funcione sobre Lightning Network sin ningún cambio en los protocolos de LN y también proporciona una base para un alto nivel de escalabilidad y privacidad del protocolo.

Los contratos inteligentes incorporan principios de propiedad privada y mutua, abstracción y separación de preocupaciones. Representan una forma "post-blockchain", completa de Turing, de computación distribuida sin confianza que no requiere la introducción de tokens.

Los contratos RGB operan en segmentos separados llamados "fragmentos". Cada fragmento tiene su propia historia y datos, lo que significa que los diferentes contratos no mezclan sus historias. Este método mejora la escalabilidad. El término "fragmento" se utiliza para mostrar que RGB logra objetivos similares a los que se pretendía con el concepto de fragmentos de Ethereum.

Aunque funcionan de forma independiente, los contratos RGB pueden interactuar a través del protocolo Bifrost en Lightning Network. Esto permite cambios coordinados entre múltiples partes. Por ejemplo, permite que los DEX funcionen a través de Lightning Network.

Tecnología y Arquitectura

Descripción general de alto nivel del funcionamiento RGB y sellos de un solo uso

Figura 1. Descripción general de alto nivel del funcionamiento de RGB.
Fuente: Github de la Asociación LNP/BP.

Como mecanismo de seguridad, RGB utiliza sellos de un solo uso defined sobre bitcoin UTXO, que brindan a cualquier parte que tenga un historial de estado de contrato inteligente la capacidad de verificar su singularidad. En esencia, RGB aprovecha el script de Bitcoin para su modelo de seguridad y definep propiedad y derechos de acceso.

Figura 2. Principio de funcionamiento RGB de alto nivel.
Fuente: "Impulsando la adopción masiva de criptomonedas: cómo el protocolo RGB está iluminando el futuro de Bitcoin" por Waterdrip Capital.

Cada contrato inteligente RGB es defined por un estado de génesis, elaborado por el emisor de contratos inteligentes (o, dicho simplemente, emisor) y un gráfico acíclico dirigido (DAG) de transiciones de estado mantenidos como datos validados por el cliente.

Figura 3. Transacciones, sello cerrado y testigo.
Fuente: Github de la Asociación LNP/BP.

Podemos resumirlo de la siguiente manera: cada transacción tiene un UTXO, y la propiedad de este UTXO le otorga al propietario el derecho a poseer el estado. La propiedad determina quién puede modificar el estado de la cadena de bloques y "gastar" el UTXO. Al individuo que posee el Estado se le llama partido. estado propietario.

La parte tiene la autoridad para modificar la sección relevante del estado del contrato inteligente generando una nueva transición de estado y confirmándola en una transacción, utilizando la salida que contiene el estado anterior.

El proceso significa cierre de un sello sobre la transición estatal, y un par que comprende la transacción de gasto y los datos de transacciones adicionales correspondientes en la transición de estado se denomina Testigo (representado en una imagen de arriba).

Propiedad y acceso: propiedades principales

Figura 4. Propiedad y Acceso.
Fuente: Github de la Asociación LNP/BP.

La propiedad estatal y la validación son conceptos distintos. Las reglas de validación especifican cómo puede cambiar el estado, pero no identifican quién puede efectuar el cambio. 

Por otro lado, la propiedad está controlada por el script de Bitcoin en el nivel de la cadena de bloques de Bitcoin, que no es Turing Complete. Por el contrario, las reglas de validación se rigen por el esquema RGB que utiliza Simplicity/Contractum Script, es decir, Turing Complete. 

Esquema RGB

En los contratos inteligentes RGB, a cada contrato se le asigna un estado único mediante sellos de un solo uso. Estos sellos, junto con el estado, tienen reglas y validaciones específicas, fijadas por el creador del contrato al inicio. Esta configuración se rige por un "esquema", que funciona como un conjunto de reglas para validar los datos del contrato en el lado del cliente. El esquema puede incluir guiones complejos que son parte integral de la lógica del contrato.

Figura 5. Esquema RGB.
Fuente: Github de la Asociación LNP/BP.

Principios de diseño y validación del lado del cliente

Figura 6. Validación del lado del cliente RGB.
Fuente: Github de la Asociación LNP/BP.

1. Propiedad fuerte: En RGB, los contratos inteligentes tienen una clara defipropietario o propietarios ned. Sólo los propietarios designados tienen la autoridad para modificar el estado del contrato. Estos contratos describen distintos derechos u operaciones categorizados como públicos (accesibles a todos) o de propiedad (restringidos al propietario).
2. Confidencialidad: La información contenida en el contrato se mantiene confidencial y sólo la conocen los participantes, especialmente los propietarios del estado. Los participantes tienen la opción de hacer públicos ciertos datos, pero de forma predeterminada, toda la información es privada. Esta confidencialidad evita que herramientas de análisis externas accedan a los datos, lo que garantiza que no se almacene información confidencial en libros públicos.
3. Separación de intereses: RGB presenta un diseño modular con distintas capas, a cada una de las cuales se le asigna una tarea específica. Estas capas funcionan de forma independiente, eliminando la necesidad de que las capas inferiores sean conscientes de la estructura de las capas superiores. Este diseño mejora la organización y eficiencia del sistema.
4. Extensibilidad: El sistema es fácilmente ampliable, lo que permite la creación e integración de contratos inteligentes avanzados sin la necesidad de modificar el protocolo central o recompilar toda la biblioteca RGB.
5. Determinismo: La lógica de validación de RGB es determinista y produce constantemente resultados idénticos con las mismas entradas y el estado predominante de la cadena de bloques subyacente o del canal Lightning Network. Esta consistencia se logra a través de dos componentes principales: a. La lógica de validación central, escrita en Rust, es la misma en todos los sistemas que ejecutan RGB. b. La lógica de validación específica del contrato se ejecuta en AluVM, una máquina virtual que proporciona un conjunto consistente de instrucciones independientemente de la plataforma.
6. Interoperabilidad LNP/BP: RGB está diseñado para funcionar a la perfección con las tecnologías existentes de Bitcoin y Lightning Network. También está diseñado para ser compatible con futuras actualizaciones de estas tecnologías.
   

Enfoque de RGB y Pure Blockchain/L1

El enfoque puro de blockchain/L1 es incorrecto, afirma el equipo de RGB.

Figura 7. Comentarios RGB sobre el enfoque Blockchain/L1.
Fuente: Github de la Asociación LNP/BP.

Enfoque de RGB: programación declarativa versus imperativa:

• La mayoría de las plataformas blockchain, incluido Ethereum, utilizan contratos inteligentes escritos en un estilo imperativo. En este enfoque, el contrato funciona como un programa que dirige explícitamente la ejecución paso a paso de las tareas, asemejándose a una receta precisa y detallada.
• Estos programas imperativos suelen ser bastante restrictivos y limitados por las capacidades de la plataforma blockchain subyacente. Aunque a veces se los denomina Turing-completos, tienen limitaciones importantes.

Naturaleza declarativa de los contratos inteligentes RGB:

• RGB, por otro lado, no utiliza programación imperativa. En cambio, emplea una forma especial de programación funcional donde los contratos inteligentes son defined declarativamente.
• En la programación declarativa, en lugar de detallar cómo hacer algo, se describe cuál debería ser el resultado. Es como delinear cómo debería ser una comida en lugar de proporcionar instrucciones de cocción paso a paso.
• El “Esquema” en RGB es declarativo definición de un contrato inteligente. Especifica las reglas y condiciones del contrato, pero no la secuencia exacta de operaciones para lograrlas.

Cambio de paradigma en programación:

• Pasar del estilo imperativo de Ethereum al estilo declarativo de RGB en la programación de contratos inteligentes es similar al cambio de la programación imperativa tradicional a la programación funcional o declarativa en el desarrollo de software en general.
• Este cambio requiere una mentalidad diferente: centrarse en el “qué” (los resultados deseados) en lugar del “cómo” (los pasos específicos para lograr esos resultados).

Sencillez

El plan original implicaba incorporar Simplicity en RGB, y se dedicaron esfuerzos a garantizar la compatibilidad desde el día 1. Sin embargo, dado el lento progreso del desarrollo de Simplicity y la incertidumbre en torno a su cronograma de lanzamiento, se hizo evidente que confiar en él no era práctico. El lanzamiento de RGB en curso, actualmente en preparación, generó dudas sobre la inclusión de Simplicity.

Al reconocer la ausencia de un calendario fiable para Simplicity, iniciamos un examen de alternativas (WASM, EVM (como una broma), IELE, etc.). Con el tiempo, se hizo evidente que desarrollar una máquina virtual patentada para RGB era la única opción viable, reemplazando la dependencia inicial de Simplicity.

Por eso decidimos crear AluVM – Máquina virtual puramente funcional y altamente portátil basada en Rust para contratos inteligentes validados por el lado del cliente (RGB), Lightning Network, computación determinista distribuida y de borde.

Prisma

PRISM significa computación de “máquinas de estados infinitos parcialmente replicadas”.

tecnología RGB defiHay reglas para la evolución de contratos inteligentes en un nivel básico, llamado esquema, pero no limita todas las acciones futuras del contrato con un algoritmo único y general. En cambio, cada nodo de la red realiza operaciones individuales, y tanto el estado del contrato como el contrato en sí siguen siendo válidos siempre que estas operaciones cumplan con las reglas del esquema. 

Además, este enfoque no limita la evolución histórica del contrato con un algoritmo predeterminado. Por lo tanto, un contrato puede exhibir comportamientos variados siempre que cada cambio cumpla con reglas de validación específicas. Este método se centra en reglas locales en lugar de un algoritmo global.

Por el contrario, Ethereum utiliza un algoritmo global donde cada operación afecta todo el estado del contrato inteligente. Con RGB, se trabaja sólo con una parte del estado del contrato, aplicando reglas localmente. Esto proporciona una gama más amplia de posibilidades para la evolución del contrato.

A continuación puede ver una vista de alto nivel sobre las diferencias entre los canales estatales y la validación del lado del cliente: 

Figura 8. Separación de sistemas distribuidos.
Fuente: Github de la Asociación LNP/BP.

Las diferencias más específicas son las siguientes: 

Figura 9. Comparación de canales estatales y validación del lado del cliente.
Fuente: Github de la Asociación LNP/BP.

AluVM

AluVM – (unidad lógica algorítmica VM) es una máquina virtual RISC puramente funcional diseñada para tareas informáticas portátiles deterministas

AluVM se distingue por emplear un sistema basado en registros que prohíbe el acceso aleatorio a la memoria. Este diseño mejora la idoneidad de AluVM para aplicaciones como contratos inteligentes, ejecución remota de código y computación distribuida y de vanguardia. Las principales fortalezas de AluVM residen en su determinismo, solidez y capacidad para el análisis de código formal.

Caracteristicas claves: Excepcional, Portabilidad, Sandboxing, Seguridad, Extensibilidad.

La arquitectura del conjunto de instrucciones (ISA) de AluVM está diseñada para ser adaptable, lo que le permite crear diferentes entornos de ejecución para diversas aplicaciones. AluVM en sí es una máquina virtual e ISA basada en registros, altamente predecible y funcional. 

Si bien restringe el acceso aleatorio a la memoria, AluVM ISA sobresale en la realización de tareas aritméticas, incluidas aquellas relacionadas con curvas elípticas. Excepcionalmente, el entorno de la VM puede expandir AluVM ISA, permitiendo agregar funcionalidades como cargar datos en los registros de la VM y admitir instrucciones especializadas (por ejemplo, SIMD) diseñadas para aplicaciones específicas.

AluVM está destinado principalmente a su uso en sistemas distribuidos donde la coherencia y la confiabilidad entre diferentes plataformas son más cruciales que la velocidad de procesamiento. Los usos principales de AluVM, con las extensiones ISA adecuadas, incluyen tecnología blockchain, cálculos críticos para el consenso en redes, computación de borde, computación multipartita (que cubre el aprendizaje automático determinista), validación del lado del cliente, computación restringida de Internet2 y algoritmos genéticos. Estas aplicaciones se benefician de la capacidad de AluVM para funcionar de manera consistente y segura en diversos entornos.

Figura 10. Comparación de AluVM.
Fuente: Github de la Asociación LNP/BP.

contrato

Contractum se distingue de otros lenguajes de programación de contratos inteligentes al combinar las capacidades funcionales de Haskell con la proximidad al metal desnudo que se ve en Rust. Ocupa un nicho que antes era inaccesible para los contratos inteligentes:

Figura 11. Comparación de Contractum, Simplicity y otros lenguajes.
Fuente: contractum.org

Contractum es un lenguaje de programación utilizado para crear contratos RGB. Los contratos celebrados con Contractum se verifican mediante un método llamado validación del lado del cliente. Este enfoque no agrega ningún dato a la cadena de bloques de Bitcoin, lo que puede compararse con una forma de tecnología de fragmentación, mejorada aún más con el uso de pruebas de conocimiento cero. 

La validación del lado del cliente también separa el desarrollo del contrato de las transacciones de blockchain, lo que hace imposible rastrear o analizar estas transacciones a través de los métodos tradicionales de análisis de blockchain.

Figura 12. Características del contrato.
Fuente: contractum.org

Para participar en el diseño de Contractum, es importante familiarizarse con las tecnologías empleadas por los contratos inteligentes RGB:

Figura 13. Tecnologías utilizadas por los contratos inteligentes RGB.
Fuente: contractum.org

Actualizaciones recientes en la nueva versión RGB v0.10

En la última versión de RGB (versión 0.10), se implementaron varias mejoras técnicas avanzadas, mejorando las capacidades del marco para el desarrollo de aplicaciones complejas. Estas actualizaciones se centran principalmente en la introducción de un Estado Global para cada contrato RGB, la integración de interfaces de contrato y la adopción de un sistema de tipos estricto.

Estado global en contratos RGB

La función Estado global es una innovación fundamental en RGB v0.10, que permite que cada contrato mantenga un estado universalmente accesible. Este estado es accesible no solo para la máquina virtual RGB sino también para clientes externos como billeteras y otras aplicaciones.

La utilidad de este Estado Global es fundamental para construir aplicaciones sofisticadas en la plataforma RGB, especialmente aquellas que requieren una gestión estatal compleja, como activos sintéticos y monedas estables algorítmicas. Permite una interacción más dinámica con el estado del contrato, extendiéndose más allá de las limitaciones de las arquitecturas tradicionales de contratos inteligentes.

Interfaces de contrato

RGB v0.10 introduce "interfaces de contrato" como un protocolo de comunicación estandarizado para diversos contratos inteligentes. Estas interfaces funcionan de manera similar a las ABI (interfaces binarias de aplicaciones) y ERC (solicitud de comentarios de Ethereum) del contrato de Ethereum.

Una distinción clave del enfoque de RGB es la estandarización no obligatoria de estas interfaces y su empaquetado inherente con contratos, eliminando la necesidad de una distribución por separado. Esto facilita las interacciones semánticas entre usuarios y contratos a través de interfaces de usuario en billeteras y otro software.

Estas interfaces no son estáticas; Los desarrolladores pueden aumentar los contratos existentes con interfaces adicionales con el tiempo, mejorando la funcionalidad sin modificar el núcleo del contrato inmutable.

Sistema de tipo estricto

El nuevo formato de codificación en RGB v0.10 utiliza un sistema de "tipos estrictos". Este sistema es un novedoso enfoque de tipo de datos funcional diseñado para una representación e introspección eficiente de los estados del contrato dentro del marco RGB.

El estricto sistema de tipos garantiza la seguridad del tamaño de los datos en tiempo de compilación, lo que es particularmente beneficioso para la operación en dispositivos con recursos limitados, como carteras de hardware de gama baja con capacidades de memoria limitadas.

Además, toda la capa de consenso RGB en la versión 0.10 se compila en tipos estrictos, lo que proporciona una base para pruebas formales de compatibilidad binaria entre diferentes versiones de software. Esta característica no solo simplifica y asegura el uso de RGB, sino que también permite a los emisores de activos y desarrolladores de contratos agregar metadatos adicionales a sus activos o contratos. Dichos metadatos pueden desempeñar un papel crucial en la verificación de la identidad y autenticidad de los activos o contratos en el ecosistema RGB.

Contratos inteligentes basados ​​en Rust

Los contratos inteligentes RGB ahora se pueden crear en Rust, aprovechando las capacidades del lenguaje para la seguridad y el rendimiento de los tipos.

La estricta integración de tipos de sistemas facilita la compilación directa de tipos de datos de Rust en estructuras de contratos RGB, lo que mejora la eficiencia y confiabilidad del código de contrato.

Capacidades mejoradas de introspección de estado

Los contratos inteligentes en RGB v0.10 pueden introspeccionar su propio estado dentro del código de validación ejecutado por la máquina virtual RGB.

Esta característica es particularmente útil para crear contratos complejos que interactúan con transacciones de Bitcoin, contratos de registro discreto y otras estructuras de datos complejas, mejorando el alcance y la funcionalidad de los contratos inteligentes RGB.

Formato de factura basado en URL

La actualización introduce un nuevo formato de factura que reemplaza el sistema codificado Bech32m anterior.

Estas nuevas facturas basadas en URL son significativamente más cortas y fáciles de usar, lo que facilita una verificación más sencilla y una apertura automática con software preconfigurado.

Soporte WASM (WebAssembly)

La biblioteca estándar RGB ahora es compatible con entornos que carecen de E/S y acceso al sistema de archivos, como páginas web o complementos de navegador.

Esto amplía los posibles casos de uso de RGB, permitiéndole funcionar sin problemas en una amplia gama de aplicaciones y extensiones basadas en web.

Descriptores de raíz principal y derivación personalizada

RGB v0.10 utiliza compromisos OP_RETURN basados ​​en raíz primaria (denominados tapret), lo que requiere soporte a nivel de descriptor para que las billeteras reconozcan transacciones con resultados modificados.

La introducción de índices de derivación personalizados en esta versión evita que las billeteras que no son RGB gasten inadvertidamente salidas que contienen activos RGB, salvaguardando así la integridad de estos activos.

Dependencias simplificadas

La capa de consenso RGB en la versión 0.10 ha reducido sus dependencias, alejándose notablemente de una implementación personalizada a prueba de balas originalmente derivada de proyectos Grin.

Esta reducción de dependencias mejora la estabilidad de la API y la solidez general del sistema.

Proceso de integración simplificado

La actualización simplifica los flujos de trabajo operativos al reducir la necesidad de múltiples llamadas API y codificación compleja de estructuras de datos en varios idiomas.

Los estados de los contratos RGB ahora se representan como objetos JSON, lo que permite una serialización sencilla en diferentes lenguajes de programación.

Mejoras en la experiencia del usuario

La nueva versión de RGB simplifica la experiencia del usuario al consolidar componentes previamente dispares en una API de biblioteca unificada y una herramienta de línea de comandos.

Si bien el Nodo RGB aún se puede operar en servidores domésticos, su uso ya no es obligatorio para interactuar con el sistema RGB, lo que reduce la barrera de entrada para los usuarios y las aplicaciones de billetera.

Esta sección incluye un reconocimiento especial a Waterdrip Capital por destacar las últimas características en su artículo titulado "Impulsando la adopción masiva de criptomonedas: cómo el protocolo RGB ilumina el futuro de Bitcoin".

Competidores RGB

Figura 14. FRGB vs Ethereum en palabras simples.
Fuente: Github de la Asociación LNP/BP

Raíz principal

Taproot Assets, anteriormente conocido como Taro, es un protocolo diseñado para lanzar tokens en la red Bitcoin. Este protocolo aprovecha el modelo UTXO de Taproot junto con soluciones asociadas como Tapscript y taptweak. Estas herramientas se utilizan para almacenar información sobre el suministro y el equilibrio de un activo dentro de los datos de las transacciones de Bitcoin.

Figura 15. Esquema para almacenar información sobre los tokens Taproot Assets.
Fuente: "Taproot Assets: emisión de activos en Bitcoin" por Voltaje

Taproot Assets emplea un método análogo al concepto de Ordinals, en el que los tokens BRC-20 almacenan información de suministro en los metadatos de satoshis enumerados. Por el contrario, Taproot Assets incorpora esta información en la salida Taproot de una transacción de Bitcoin, utilizando lo que se conoce como un "árbol Merkle disperso". Básicamente, Taproot Assets incorpora un árbol Merkle en la transacción de Bitcoin, que sirve como prueba del saldo de un usuario específico y del suministro general de tokens. Este árbol, a su vez, refleja datos del "Universo", un repositorio que mantiene el historial completo de activos y es administrado por el emisor del token.

Figura 16. Árbol de estado digital.
Fuente: "Taproot Assets: emisión de activos en Bitcoin" por Voltaje

Árbol digital estatal: la arquitectura de Taproot Assets ofrece dos opciones para la prueba del equilibrio: datos fuera de la cadena del Universo o el escaso árbol Merkle integrado en el UTXO.

Mecanismo operativo

1. El creador del token ejecuta una transacción P2TR (Pago a Taproot) utilizando el protocolo Taproot Assets. 
2. La información sobre el activo, en forma de árbol Merkle, se almacena en el UTXO de esta transacción (efectivamente, el bloque génesis). 
3. Para transferir el token, el propietario de la clave Taproot modifica la información del saldo en el árbol Merkle, asegurando que el suministro general de activos permanezca constante. 
4. Estas modificaciones se introducen mediante una nueva transacción Taproot. Sin embargo, para cada transferencia de token, no se requiere una transacción en cadena separada. Similar a los rollups o Lightning Network, el protocolo permite al propietario procesar un "lote" de transferencias y publicar posteriormente el estado actualizado de los saldos.

Ventajas de los activos Taproot

• Una ventaja clave de Taproot Assets es su total compatibilidad con Lightning Network, lo que mejora las posibilidades de escalabilidad y reduce los costos de transacción.
• Taproot Assets crea una capa distinta para registrar operaciones con tokens personalizados. Si bien se basa principalmente en datos fuera de la cadena, publica el estado de los saldos en la red principal. 
• Este enfoque es más flexible, escalable y completo en comparación con BRC-20, pero también plantea más complejidad para usuarios inexpertos.

BitVM

BitVM es un proyecto de vanguardia destinado a transformar Bitcoin en una plataforma informática totalmente descentralizada. Presentado el 9 de octubre de 2023, el documento técnico de BitVM presenta una tecnología que se encuentra actualmente en fase de prueba y requiere un mayor desarrollo para alcanzar su máximo potencial.

Funcionalidad principal y concepto de BitVM

En esencia, BitVM emplea el concepto de Optimistic Rollups para externalizar los cálculos de los contratos inteligentes de la red, y posteriormente realizar una verificación en cadena basada en "pruebas de fraude". En teoría, una vez que la información del contrato inteligente se registra en una transacción Taproot (como código binario), el intercambio de datos y los cálculos deben ocurrir directamente entre las partes. Este enfoque está diseñado para reducir la congestión de blockchain. Sin embargo, si el probador (la parte que prueba, es decir, el propietario del contrato) transmite datos erróneos, un verificador puede iniciar una verificación en cadena. Este proceso forma la base del concepto de prueba de fraude.

Manejo de la verificación en cadena en una red computacionalmente limitada

El desafío surge en cómo realizar una verificación de operación en una red que intrínsecamente no admite tales cálculos. Para solucionar este problema, BitVM utiliza un árbol Merkle para crear un esquema de puerta NAND lógico, que luego se registra en una transacción Taproot. Esencialmente, el árbol Merkle en los datos de la transacción actúa como un esquema NAND, donde cada "rama" lleva uno de dos valores posibles: 1 o 0. El cálculo en cadena avanza poco a poco, y la salida de una "rama" se convierte en la entrada para el siguiente. Se producen constantes intercambios de transacciones para la verificación del valor entre las partes del contrato inteligente. Si la versión de cálculo del probador es incorrecta, el verificador recibe sus activos bloqueados en la transacción Taproot.

Figura 17. Representación esquemática de NAND.
Fuente: "El gran problema con BitVM: la computación arbitraria ahora es posible en Bitcoin sin bifurcación" por Bitcoin Magazine

Construyendo NAND usando Taproot y Merkle Tree

En la documentación técnica se puede encontrar información detallada sobre cómo BitVM facilita la construcción de NAND utilizando árboles Taproot y Merkle, así como su impacto en los cálculos.

Este enfoque permite una verificación precisa, paso a paso, de los cálculos de los contratos inteligentes, alineándose con los principios de integridad y seguridad de blockchain.

Desafíos del bilateralismo de contratos inteligentes

Persiste un problema importante en BitVM debido a la estructura bilateral de los contratos inteligentes, que facilitan el intercambio directo de datos únicamente entre el verificador y el probador, excluyendo la participación de terceros. Esta restricción impide el desarrollo de dApps y exige soluciones complementarias para la construcción de contratos entre múltiples partes. 

Además, las características intrincadas y de bajo nivel de BitVM implican que la construcción de productos funcionales que aprovechen esta base puede extenderse durante varios años. Es imprescindible un desarrollo e innovación sustanciales para traducir esta tecnología fundamental en aplicaciones prácticas.

Para una inmersión profunda y detallada, no dude en leer un BitVM Whitepaper – https://bitvm.org/bitvm.pdf 

Conclusión

El protocolo RGB es un desarrollo técnico en el ecosistema de Bitcoin, que introduce funcionalidades para la implementación de contratos inteligentes y la emisión de tokens directamente vinculados a la red de Bitcoin. Esto se logra mediante una combinación de validación del lado del cliente y utilización de sellos de un solo uso, que vinculan los tokens a los UTXO de Bitcoin manteniendo la privacidad de las transacciones.

Una de las principales ventajas técnicas de RGB es su enfoque de escalabilidad y privacidad. Al trasladar la mayor parte del trabajo de validación fuera de la cadena de bloques de Bitcoin y emplear métodos criptográficos para la verificación de transacciones, RGB reduce efectivamente la carga de datos en la cadena de bloques. Este enfoque favorece el mantenimiento de la eficiencia de la red, especialmente a medida que aumentan los volúmenes de transacciones.

La compatibilidad de RGB con Lightning Network es otro aspecto importante, que permite un procesamiento de transacciones más escalable y eficiente. Esta característica es particularmente relevante dada la creciente demanda de métodos de transacción más rápidos y rentables en el espacio de las criptomonedas.

Sin embargo, la naturaleza compleja de la tecnología RGB presenta desafíos en términos de accesibilidad y comprensión del usuario. La arquitectura del protocolo y los métodos criptográficos avanzados empleados pueden ser difíciles de entender e implementar, especialmente para quienes son nuevos en la tecnología blockchain. Esta complejidad podría obstaculizar una adopción más amplia y la participación de los usuarios.

Además, si bien RGB mejora la privacidad al mantener los datos de los contratos fuera de la cadena de bloques, este aspecto también plantea dudas sobre la verificabilidad de los datos y la capacidad de auditar las transacciones, que son cruciales para determinadas aplicaciones y el cumplimiento normativo.

La última actualización de RGB, la versión 0.10, lo posiciona como un competidor notable en el panorama cambiante de las tecnologías blockchain, particularmente frente a protocolos emergentes como Taproot Assets y BitVM. A diferencia de Taproot Assets, que se centra en aprovechar el modelo UTXO de Taproot para la emisión de tokens en la red Bitcoin, RGB se distingue por sus características avanzadas de privacidad y manejo de datos fuera de la cadena, ofreciendo un enfoque distinto para la funcionalidad de contratos inteligentes y la gestión de tokens.

Del mismo modo, mientras BitVM introduce un concepto novedoso para la computación descentralizada en Bitcoin, los avances de la versión 0.10 de RGB en la validación del lado del cliente, las interfaces de contrato y un sistema de tipos estricto muestran su enfoque único para mejorar la escalabilidad y la interacción del usuario dentro del ecosistema de Bitcoin. Estas mejoras resaltan la destreza de RGB para abordar los desafíos de escalabilidad y eficiencia, áreas donde los protocolos tradicionales y emergentes a menudo enfrentan limitaciones.

La simplificación de las dependencias y los procesos de integración en la última versión de RGB indica aún más un enfoque en la experiencia del usuario y la estabilidad del sistema, lo que lo distingue de la competencia. Esto posiciona a RGB no solo como una plataforma sólida para contratos inteligentes y emisión de tokens escalables y centrados en la privacidad, sino también como una solución con visión de futuro en el espacio más amplio de blockchain.

En conclusión, el protocolo RGB es un desarrollo tecnológico significativo dentro de la red Bitcoin, que ofrece capacidades avanzadas para contratos inteligentes y emisión de tokens. Aborda cuestiones clave de escalabilidad y privacidad, pero enfrenta desafíos en términos de complejidad y potencial auditabilidad. El desarrollo actual y las futuras iteraciones del protocolo probablemente se centrarán en equilibrar estas capacidades avanzadas con la accesibilidad del usuario y las consideraciones regulatorias.

Referencias de términos: 

1. Turing completo: En términos prácticos, el sistema puede ejecutar cualquier problema computacional con suficiente tiempo y memoria. La mayoría de los lenguajes de programación modernos son Turing completos, lo que significa su capacidad teórica para abordar cualquier problema computacional.
   
2. Esquema: Un esquema de contrato sirve como código real para un contrato inteligente, que los emisores pueden utilizar como "plantilla de contrato" sin la necesidad de codificar o auditar código personalizado proporcionado por fuentes externas. El esquema RGB no es un script sino una estructura de datos.
   
3. Contratos de registro discretos (DLC) en el contexto de los canales estatales son contratos inteligentes especializados que se utilizan principalmente en la red Bitcoin. Permiten la ejecución privada y eficiente de acuerdos financieros complejos basados ​​en eventos externos, como los precios de los activos. Los DLC operan fuera de la cadena y mantienen la confidencialidad de los detalles del contrato y las identidades de los participantes. Utilizan fuentes de datos externas u oráculos para la resolución de contratos. Cuando se integran con los canales estatales, los DLC mejoran la escalabilidad al permitir múltiples acuerdos de transacciones sin congestionar la cadena de bloques, lo que los hace ideales para transacciones financieras privadas y eficientes que dependen de resultados del mundo real.
   
4. Storm – almacenamiento sin confianza basado en custodia utilizando zk-proofs. Storm combina almacenamiento sin confianza basado en custodia con pruebas de conocimiento cero para facilitar transacciones seguras y privadas. En este sistema, los datos o activos se mantienen en custodia y solo se liberan cuando se cumplen condiciones específicas, lo que garantiza un entorno sin confianza donde no se necesita una autoridad central. La integración de zk-proofs permite la verificación de estas transacciones manteniendo la máxima confidencialidad, ya que permiten la validación de datos sin revelar ningún detalle subyacente.
   
5. Prometeo – Computación distribuida sin confianza basada en arbitraje. Prometheus representa un enfoque para la computación descentralizada, que combina mecanismos de arbitraje para la resolución de disputas, interacciones sin confianza para operaciones seguras y descentralizadas y la eficiencia de los canales estatales para la gestión de la computación fuera de la cadena.
   
6. A Grupo reducido de instrucciones para computadoras es un tipo de arquitectura de microprocesador que utiliza un conjunto de instrucciones pequeño y altamente optimizado en lugar del conjunto de instrucciones altamente especializado que normalmente se encuentra en otras arquitecturas.