¿Cuál es el potencial real del protocolo de emisión de activos BTC RGB?

Autor**|**A Jian

Enlace original:

Este artículo intenta proporcionar una descripción sucinta de RGB, un protocolo de distribución de activos en el BTC (que también puede entenderse como un sistema de contrato inteligente fuera de la cadena), y señala en qué se diferencia de otros protocolos que tienen como objetivo lograr la misma o similar funcionalidad, lo que hace que el protocolo RGB sea mucho más escalable de lo que son y deja más espacio para la programación. Además de presentar los diseños ya terminados de RGB, también exploraremos estas posibilidades de programación.

¿Qué es el protocolo RGB?

La idea de emitir activos en BTC ha existido durante mucho tiempo. Sin embargo, BTC protocolo tiene sus propias características: su estado es expresado por y solo por BTC UTXO (“salidas de transacciones no gastadas”), un UTXO lleva solo dos datos: su propia denominación (valor BTC) y una “clave pública de script” (también conocida como “script de bloqueo”) que se utiliza para programar las condiciones en las que se gastan los fondos, como proporcionar una firma para una clave pública, y los códigos de operación que permiten programar el script de bloqueo son proporcionados por las reglas de consenso del BTC, que no se pueden usar para implementar reglas de seguridad arbitrarias. Como resultado, no es posible crear otros activos dentro del UTXO, BTC scripts no pueden programar comprobaciones de seguridad para esos activos. Esto significa que toda la idea de emitir activos en BTC es esencialmente un uso creativo de BTC espacio de bloque. Esto significa que necesitamos diseñar un sistema de contrato inteligente fuera de la cadena y requerir que la información sobre los pasos que cambian el estado del contrato (por ejemplo, el contrato A cambia los parámetros, B transfiere una cierta cantidad de un activo a C) se cargue en la cadena de bloques, de modo que se pueda obtener el último estado del sistema de contrato inteligente mediante la recopilación de esta información.

Una idea de diseño rudimentaria es subir intacta la información de los pasos que cambian el estado del contrato a la cadena de bloques BTC. Por supuesto, esto puede funcionar, sin embargo, se enfrentará a varios problemas: (1) debido a la carga de información completa, puede consumir más espacio en bloque, y cuando los usuarios necesiten cambiar el estado del contrato (como las transferencias), también tendrán que pagar más tarifas on-chain. En particular, cuando queremos que un sistema de contrato fuera de la cadena tenga una mejor programabilidad que BTC, el aumento de la programabilidad puede producirse a costa de consumir más espacio en bloque: (2) la información en casi cualquier parte del bloque tiene el potencial de cambiar el contrato inteligente fuera de la cadena, por lo que el usuario debe obtener todos los datos del bloque BTC para obtener el último estado del sistema de contratos fuera de la cadena, es decir, es más costoso de verificar, (3) dependiendo del diseño del sistema de contrato inteligente fuera de la cadena, es posible que solo obtenga la misma o incluso peor privacidad que BTC, y si puede proporcionar más privacidad, es posible que necesite consumir más espacio en bloque。

En el pasado, un protocolo muy utilizado llamado “Omni” no cargaba la información completa de las transacciones contractuales fuera de la cadena, solo el hash de la transacción. Este enfoque resuelve el problema anterior 1 al desacoplar la complejidad de las transacciones contractuales fuera de la cadena de sus costos económicos, pero los usuarios aún necesitan obtener la cantidad total de datos de bloques de BTC para obtener el estado más reciente del protocolo Omni, y no mejora específicamente la privacidad.

RGB, por otro lado, utiliza un nuevo paradigma llamado “sellos de un solo uso”. La forma en que funciona es simple: RGB requiere que cada estado de cada contrato se adjunte a un UTXO BTC, y una vez que se va a cambiar ese estado, se debe gastar el UTXO para que la transacción que lo gastó sea confirmada por la cadena de bloques, y la transacción BTC que lo gasta también debe proporcionar un hash de la transición de estado para indicar el UTXO al que se adjunta el estado cambiado.

A los ojos de los desarrolladores RGB, este diseño es similar a los sellos de plástico numerados: es fácil saber si se ha quitado y, una vez que se quita, ya no se puede usar. Sin embargo, la otra forma de mirar es usar el UTXO poseído como un contenedor o una alcancía de cerámica en este estado: para sacar el dinero de la alcancía, debe romper la alcancía y poner el dinero dentro en una nueva.

Este diseño está en marcado contraste con los protocolos anteriores que tratan todo el bloque como un gran tablero: usar UTXO como contenedor significa que las transacciones que no gastan este UTXO no pueden tener ningún efecto en el estado del contrato en el contenedor, por lo que para verificar un determinado estado de un contrato, no necesitamos obtener todos los datos del bloque, todo lo que necesitamos es una serie de transacciones BTC, pruebas de que estas transacciones BTC existen en un bloque, y estos RGB BTC los compromisos del intercambio Transiciones de estado (en pares con transacciones de BTC relacionadas). Estos datos, que se pueden concatenar en una cadena, deberían permitirnos rastrear hasta el estado inicial del contrato, lo que nos permitiría identificar la esencia de este estado.

Para los lectores que están familiarizados con los sistemas de contratos inteligentes en cadena (como ETH Fang), una de las cosas que es difícil de entender sobre este proceso es que si no depende del consenso de la cadena de bloques (lo que significa que el estado inicial del contrato y cada cambio de estado serán verificados por cada nodo), ¿cómo asegurar que la seguridad de este sistema de contrato inteligente esté garantizada, cómo asegurarse de que los activos que recibe son del tipo que desea y cómo asegurarse de que los activos no se emitan ilegalmente?

La respuesta es simple, se llama “validación del lado del cliente”: usted mismo lo verifica. En el sistema de contratos on-chain, los nodos verifican cada operación de transición de estado y rechazan las operaciones no válidas de acuerdo con las reglas públicas de transición de estado, para calcular el último estado de acuerdo con el estado inicial. Sin embargo, siempre que las reglas de transición de estado y el estado inicial sean conocibles, la verificación a través del consenso en cadena no es la única forma, y los usuarios pueden verificar que cada paso de la transición de estado sigue las reglas de transición de estado definidas originalmente en función de la información proporcionada por el pagador. De esta manera, la parte verificadora (presumiblemente el destinatario del activo) también puede detectar transiciones de estado ilegales y negarse a aceptarlas.

Por último, vamos a utilizar un ejemplo para ilustrar las características del protocolo RGB:

Ahora, Alice es propietaria de UTXO A’, que posee el activo Y de X unidades emitidas bajo la licencia RGB, y quiere transferir Z unidades de Y a Bob. Se necesitaron un total de 5 propietarios anteriores (incluido el emisor) de los activos para llegar a Alice. Por lo tanto, Alice quiere proporcionar a Bob evidencia de estas 4 transiciones de estado (las primeras 3 de las cuales fueron proporcionadas a Alice por el propietario anterior), incluido el estado inicial del contrato y las reglas de transición de estado, las transacciones de BTC utilizadas para cada transferencia, cada transacción RGB confirmada BTC el intercambio y la evidencia de que estas transacciones de BTC han sido confirmadas por un bloque, y enviarlas a Bob, quien verificará estas 4 de acuerdo con las reglas de transición de estado del contrato transfiere sin romper las reglas, y luego decide si aceptarlo o no. Cuando Alice construye una transacción RGB, dado que Z es menor que X, también organiza un UTXO para recibir el resto. Por último, Alice incrusta el hash de la transacción RGB en la transacción BTC que cuesta UTXO A’ completar el pago.

Eventualmente, gracias al uso de contenedores UTXO, el último estado de un contrato RGB se puede representar como un punto en un grafo acíclico dirigido que aún no tiene descendientes (cada punto representa un estado almacenado dentro de un contenedor UTXO). Y, para el propietario P en el siguiente diagrama, solo conocerá el proceso desde el estado inicial G del contrato hasta él, que es el proceso encerrado en un círculo rojo, y no sabrá nada sobre los puntos grises:

Ventajas de RGB

Estado verificable genial

Como se mencionó anteriormente, RGB reduce significativamente el costo de validación (un cierto estado de un contrato) en comparación con los protocolos de emisión de activos (sistemas de contratos fuera de la cadena) que han surgido previamente en BTC. En el momento de la transacción, el receptor ya no necesita iterar a través de todos los bloques para recopilar información sobre el cambio en el estado del contrato, sino que solo necesita obtener una serie de transacciones BTC, así como las transacciones RGB prometidas por estos intercambios, y el bloque que contiene evidencia de estas transacciones BTC (según la prueba de Merkle del encabezado del bloque), para estar seguro de que el pagador realmente posee una cierta cantidad de un determinado activo.

Esta reducción en el costo de verificación también reduce en gran medida la dependencia (confianza) del usuario de los grandes proveedores de infraestructura. En los protocolos anteriores, debido al alto costo de la verificación, era difícil para los usuarios calcular el último estado del contrato por sí mismos, por lo que los usuarios tenían que confiar en algunos proveedores (como el proveedor de estado del contrato utilizado por sus billeteras) y, al mismo tiempo, porque había menos proveedores que pudieran asumir dichos costos computacionales, lo que también significaba que el proveedor estaba centralizado. Sin embargo, en RGB, los usuarios solo necesitan usar BTC cliente ligero para verificar la parte de la transacción con el BTC y usar el protocolo RGB para verificar la parte de la transacción RGB, y pueden permitírselo.

En comparación con algunos sistemas de contrato en cadena, RGB también es más ligero. Esto se refleja en el hecho de que RGB puede verificar específicamente un determinado estado de un contrato, mientras que en los sistemas que no se basan en UTXO, debido a la falta de un mecanismo para controlar el acceso, como los UTXO, cualquier transacción puede cambiar cualquier estado, por lo que es casi imposible verificar un determinado estado de manera específica, sino que solo puede determinar un cierto estado mientras se calculan todos los estados más recientes, en este sentido, la característica expresada como un “estado global” en realidad debería llamarse " estado uniforme", aunque proporciona acceso cruzado entre contratos, también determina que será más costoso de verificar y más difícil de obtener sin confianza.

Una optimización significativa en estos protocolos de contratos en cadena es el requisito de que los encabezados de bloque se comprometan con el estado más reciente (“raíz de estado”), lo que permite a los clientes ligeros validar un determinado estado de un contrato desde nodos completos contra estos compromisos. Es una forma de reutilizar cálculos que ya han ocurrido (cálculos que ya han sido ejecutados por un nodo completo), y también es muy eficiente, por lo que puede considerarse más eficiente que RGB si no se tiene en cuenta la falta de confianza. Sin embargo, significa que los nodos ligeros dependen de nodos completos para la verificación de la base de transacciones y el cálculo del estado del contrato. En una billetera RGB que utiliza un cliente ligero BTC, se basa en la suposición de confianza de que la transacción es relevante BTC transacción es válida, y la parte relacionada con el estado del contrato es verificada por el propio cliente, por lo que la falta de confianza es mejor. La desventaja es que el retraso en la verificación es más largo y es necesario conservar más datos.

Escalabilidad

La escalabilidad de RGB es doble:

1. Solo un hash está incrustado en BTC transacción, lo que significa que no hay límite para el tamaño de la transacción RGB (aparte de las reglas personalizadas por el contrato): incluso si divide un activo RGB en 100 (la transacción RGB en sí será muy grande), solo hay un hash que debe incrustarse en BTC transacción. Como se señaló en la Nota 6, hay dos formas de incrustar un hash de este tipo: utilizando la salida OP_RETURN, lo que significa que consume un hash de espacio en la cadena, u ocultándolo en el árbol de scripts prometido por la clave pública del script de la salida de Taproot, que no consume ningún espacio en la cadena. Esto también significa que los usuarios no tienen que sacrificar la economía por la programabilidad, solo las tarifas en la cadena.

2. El último estado del contrato RGB es un punto independiente en un grafo acíclico dirigido sin descendientes, lo que significa que estos estados se pueden cambiar de forma independiente sin afectarse entre sí, es decir, se permite la concurrencia. En realidad, esta es una característica heredada de UTXO también. Esto también significa que los cambios no válidos (transacciones no válidas) que se produzcan en una sucursal no afectarán a las otras sucursales, y mucho menos harán que se congele todo el contrato, por lo que también puede considerarse un beneficio de seguridad.

RGB ha sido criticado por su escalabilidad: con cada transferencia, el destinatario debe verificar todas las transacciones involucradas desde el estado inicial hasta el estado del pagador: a medida que aumenta el número de transferencias de activos, aumenta la carga de verificación de los destinatarios posteriores. Esta crítica es cierta. Optimizarlo significa encontrar una manera de reutilizar los cálculos que ya se han producido. Se espera que las tecnologías de sistemas de prueba, como los SNARK, proporcionen una solución de este tipo.

Diferenciación de la definición de activos y mecanismo de declaración aduanera

El último beneficio sigue estando relacionado con los UTXO, dependiendo de cómo entendamos el mecanismo de scripting de bloqueo de UTXO.

Un script de bloqueo se puede utilizar para programar las condiciones en las que se desbloqueará un fondo, de modo que pueda implementar reglas de custodia. Por ejemplo, si un script de bloqueo contiene solo una clave pública, significa que solo el propietario de la clave privada correspondiente puede controlarlo. Sin embargo, estas normas de custodia también son la base de BTC programación del protocolo contractual. Por ejemplo, un UTXO que utiliza un script de bloqueo multifirma 2 de 2 podría ser un canal relámpago, y durante el funcionamiento del canal, dos partes pueden pagarse entre sí casi un número infinito de veces sin ningún cambio en la forma on-chain de los fondos. En otras palabras, en este punto, el script de bloqueo de firma múltiple 2 de 2 constituye un mecanismo de transferencia de valor que permite a ambas partes transferir valor sin cambiar la forma de los fondos en cadena.

Este mecanismo puede utilizarse para el valor de los BTC transportados por la UTXO y, naturalmente, para los activos RGB que transporta. Podemos emitir un activo RGB y adjuntarlo a un UTXO multifirma 2 de 2, utilizando el mecanismo del canal lightning para pagarnos un número ilimitado de veces. Del mismo modo, los activos RGB también se pueden utilizar en otros contratos BTC basados en scripts.

Aquí, los scripts y protocolos RGB de UTXO forman una diferenciación funcional: el primero se centra en la implementación de las reglas de custodia y transferencia de valor, mientras que el segundo se centra en la definición de activos. De este modo, se puede separar la custodia de los activos y la definición de los mismos. Esta es una mejora de seguridad importante, y una que la gente está buscando en algunos otros sistemas de contratos en cadena.

RGB ha sido diseñado

Las características anteriores son válidas para prácticamente todos los protocolos basados en el sellado único de UTXO y la verificación del lado del cliente. Pero además de eso, el protocolo RGB ha sido diseñado aún más.

En el desarrollo actual del protocolo RGB, los desarrolladores están particularmente preocupados por la privacidad del protocolo, por lo que RGB fortalece la privacidad de dos maneras:

• UTXO cegados. En una transacción RGB, el receptor solo necesita usar el identificador UTXO ofuscado para recibir el activo, sin exponer las características del UTXO que realmente recibe el activo. Esto no compromete de ninguna manera la capacidad del destinatario para proporcionar pruebas al siguiente propietario, mientras que al mismo tiempo permite que los destinatarios posteriores del activo se defiendan de las miradas indiscretas del propietario del activo anterior. *Antibalas. Se puede utilizar para ocultar el monto exacto en cada transacción. Sin embargo, los propietarios de activos posteriores aún pueden verificar que no ha habido ninguna emisión adicional antes.

Espacio explorable

En esta parte, voy a hablar sobre las áreas en las que el protocolo RGB puede seguir explorando, principalmente relacionadas con la programabilidad.

En la actualidad, las plantillas de contratos RGB propuestas (esquemas) se centran en la emisión de activos. Sin embargo, dado que RGB utiliza el paradigma de “validación del lado del cliente”, de hecho, podemos agregarle cualquier cosa que pueda garantizarse mediante la verificación del lado del cliente, limitada solo por la estructura UTXO.

Restricciones

Además de los UTXO, un concepto que amplía la programabilidad se denomina “covenants”. La intención original de la cláusula de restricción es limitar el destino al que se puede transferir una suma de dinero. Con esta capacidad, podemos programar muchas aplicaciones interesantes, tales como:

• Fondos comunes para retiros no interactivos. Podemos agrupar los fondos de muchas personas en el mismo UTXO y utilizar restricciones para garantizar que ninguno de ellos pueda retirar sus propios fondos sin la ayuda de otros. Esto puede servir para ayudar a las personas a salir de lugares de alto riesgo a un bajo costo cuando la demanda de espacio en bloque es alta.
• Contrato de bóveda. Haga que un fondo tenga que ir a algún lugar, pase por un bloqueo de tiempo antes de que pueda gastarlo libremente, y durante el bloqueo de tiempo, el propietario de la bóveda puede interrumpir el proceso con una clave de emergencia e inmediatamente mover los fondos a otro lugar. Un dispositivo de este tipo puede ser de gran ayuda para el autoalmacenamiento.

Los scripts de BTC actuales no tienen esta capacidad, por lo que habilitar restricciones en BTC scripts requiere una bifurcación suave.

Sin embargo, siempre y cuando estemos dispuestos a sacrificar algunos de los beneficios de la “definición de activos y diferenciación de custodia”, podemos experimentar con dicha característica en activos RGB, y podemos implementar esta funcionalidad a nivel de contratos RGB, aunque solo puede funcionar para los activos RGB que la usan (y no BTC), pero sin duda abrirá un espacio interesante.

Los estudios de las restricciones existentes han demostrado que amplía el espacio de programación para las transacciones basadas en UTXO, ofreciendo una serie de características. Pero estos estudios se basan básicamente en BTC, y seríamos un poco más conservadores en BTC protocolos como este. En RGB, podemos generalizar audazmente la capacidad central de la cláusula de restricción, la capacidad de leer transacciones que se cuestan a sí mismas a nivel de script, para proporcionar una programabilidad más flexible: la capacidad de acceder a contratos cruzados.

Acceso cruzado

La cláusula de restricción mínima significa que cuando se gasta un UTXO, su script puede leer el resultado de la transacción de gasto. Pero una restricción totalmente generalizada significa que puede leer todas las partes de la transacción que le costaron. Esto significa que también puede leer las otras entradas de la transacción, y si no limitamos las otras entradas al mismo contrato, significa que puede leer el estado de los otros contratos.

En RGB, por defecto cada contrato es un universo independiente con su propio grafo acíclico dirigido. Sin embargo, todavía es posible que un usuario tenga dos contratos diferentes al mismo tiempo. Si las transacciones RGB permiten que los activos de ambos contratos se gasten al mismo tiempo, estas capacidades de acceso cruzado pueden tener un caso de uso (aunque es concebible que complique la verificación de las transacciones).

De hecho, ya existen sistemas de contratos en cadena basados en estructuras similares a UTXO (por ejemplo, Nervos Network) que utilizan esto para lograr capacidades de acceso cruzado para contratos11. Este es un campo muy nuevo, que se abre a áreas que rara vez han sido tocadas por estudios BTC anteriores, y puede haber algunas sorpresas enterradas en él.

Conclusión

En este artículo, el lector notará que hay un concepto que se menciona con frecuencia a lo largo del proceso de razonamiento y fantasía: “UTXO”. Eso es exactamente lo que pretendía. Si no entiendes UTXO, no puedes entender el punto de partida del diseño de un protocolo como RGB, las ventajas del diseño del protocolo RGB y la forma en que las personas pueden usarlo. La naturaleza del protocolo RGB está determinada en gran medida por su UTXO, una forma de sello de un solo uso. En consecuencia, la investigación sobre UTXO acumulada en BTC campo de investigación también se puede aplicar a la investigación de RGB.

Esto también explica por qué las personas que no entienden BTC, tendrán dificultades para entender RGB. Y aquellos a los que les guste BTC reconocerán los diseños que RGB ya ha realizado.