Este artículo intenta proporcionar una descripción concisa de RGB, un protocolo de emisión de activos en Bitcoin (también puede entenderse como un sistema de contrato inteligente fuera de la cadena), y señala que es muy diferente de otros proyectos que apuntan Para lograr protocolos funcionales iguales o similares, estas diferencias hacen que el protocolo RGB sea mucho más escalable que ellos y deja un espacio de programación más amplio. Además de presentar los diseños completos de RGB, también exploraremos estas posibilidades de programación.
¿Qué es el protocolo RGB?
La idea de emitir activos en Bitcoin existe desde hace mucho tiempo. Pero el protocolo Bitcoin tiene sus propias características: su estado se expresa únicamente por Bitcoin UTXO ("salida de transacción no gastada"); un UTXO sólo lleva dos datos: su propia denominación (valor de Bitcoin) y una "clave pública de script" (también conocido como "script de bloqueo"), utilizado para programar las condiciones de gasto de este fondo, por ejemplo: proporcionar una firma de una determinada clave pública; permitir que el código de operación utilizado para programar el script de bloqueo sea determinado por las reglas de consenso de Bitcoin siempre que no puedan utilizarse para implementar reglas de seguridad arbitrarias. Por lo tanto, es imposible crear otros activos dentro de UTXO: el script de Bitcoin no puede programar controles de seguridad para estos activos. Esto significa que todas las ideas para emitir activos en Bitcoin son esencialmente usos creativos del espacio de bloques de Bitcoin. Esto significa que necesitamos diseñar un sistema de contrato inteligente fuera de la cadena y requerir los pasos para cambiar el estado del contrato; por ejemplo, el contrato A cambia los parámetros y B transfiere una cierta cantidad de un determinado activo a C —— La información se carga en la cadena de bloques, de modo que se puede obtener el estado más reciente del sistema de contrato inteligente al recopilar esta información.
Una idea aproximada de diseño es cargar la información de los pasos que cambian el estado del contrato en la cadena de bloques de Bitcoin intacta. Esto ciertamente funciona, pero enfrenta varios problemas:
(1) Dado que se carga la información completa, puede consumir más espacio en el bloque. Cuando los usuarios necesiten cambiar el estado del contrato (como una transferencia), también deberán pagar más tarifas de manejo en la cadena. En particular, cuando esperamos que dicho sistema de contratos fuera de la cadena tenga una mejor programabilidad que Bitcoin, el aumento de la programabilidad puede producirse a expensas de consumir más espacio de bloque;
(2) Casi cualquier información en el bloque puede cambiar el contrato inteligente fuera de la cadena, por lo que los usuarios deben obtener todos los datos del bloque de Bitcoin para obtener el estado más reciente del sistema de contrato 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 pueda obtener una privacidad comparable a la de Bitcoin, o incluso peor; y si puede proporcionar más privacidad, es posible que necesite consumir más área. bloquear el espacio.
En el pasado, un protocolo ampliamente utilizado llamado "Omni" no cargaba información completa sobre las transacciones de contratos fuera de la cadena, sino solo el valor hash de la transacción. Este enfoque resuelve los problemas anteriores y desacopla la complejidad de las transacciones de contratos fuera de la cadena de sus costos económicos; sin embargo, los usuarios aún necesitan obtener la cantidad total de datos del bloque Bitcoin para obtener el estado más reciente del protocolo Omni; además, no No diseñado específicamente para mejorar la privacidad.
RGB utiliza un nuevo paradigma llamado "sellos de un solo uso". Su uso es muy simple: RGB requiere que cada estado de cada contrato esté asociado a un determinado UTXO de Bitcoin; y una vez que quieras cambiar este estado, debes gastar este UTXO y dejar que la transacción que lo gasta obtenga la Confirmación en la cadena de bloques; Además, la transacción de Bitcoin que lo gasta también debe proporcionar un hash del contenido de la transición de estado para indicar el UTXO adjunto al estado alterado.
Para los desarrolladores de RGB, el diseño es similar a un sello de plástico numerado: es fácil saber si se ha quitado y, una vez retirado, no se puede reutilizar. Sin embargo, otra perspectiva es considerar el UTXO poseído como el contenedor o alcancía de cerámica en este estado: si quieres sacar el dinero de la alcancía, debes romper la alcancía y luego poner el dinero dentro. en el nuevo frasco.
Este diseño contrasta marcadamente con protocolos anteriores que trataban todo el bloque como un gran tablero de escritura: usar UTXO como contenedor significa que las transacciones que no gastan este UTXO no pueden tener ningún impacto en el estado del contrato en el contenedor. Para un determinado estado de un determinado contrato, no necesitamos obtener los datos de todos los bloques, todo lo que necesitamos es una serie de transacciones de Bitcoin, evidencia de que estas transacciones de Bitcoin existen en un determinado bloque y estos bits La conversión de estado RGB prometida por el cambio de moneda (un par con la transacción Bitcoin correspondiente) es suficiente. Estos datos, que pueden conectarse en cadena, deberían permitirnos rastrear el estado inicial de este contrato, permitiéndonos identificar la esencia de este estado.
Para los lectores que están familiarizados con los sistemas de contratos inteligentes en cadena (como Ethereum), una cosa que es difícil de entender acerca de este proceso es que si no depende del consenso de la cadena de bloques (lo que significa que el estado inicial de la contrato y cada cambio de estado será verificado por cada nodo), ¿cómo se garantiza la seguridad de este sistema de contrato inteligente? ¿Cómo garantizar que los activos que recibe sean los que desea y cómo garantizar que no hayan sido emitidos ilegalmente?
La respuesta también es muy simple: se llama "validación del lado del cliente": usted mismo la verifica. En el sistema de contrato en cadena, los nodos verifican cada operación de transición de estado de acuerdo con las reglas públicas de transición de estado, rechazan operaciones no válidas y luego calculan el último estado en función del estado inicial. Sin embargo, siempre que se conozcan las reglas de transición de estado y el estado inicial, la verificación a través del consenso en la cadena no es la única manera. Los usuarios pueden verificar si cada paso de la transición de estado sigue la transición de estado definida originalmente en función de la información proporcionada por el pagador regla. De esta manera, la parte verificadora (supuestamente el destinatario del activo) también puede detectar transiciones de estado ilegales y negarse a aceptarlas.
Finalmente, usamos un ejemplo para demostrar las características del protocolo RGB:
Ahora, Alice posee UTXO A, que contiene X unidades del activo Y emitidas según el protocolo RGB. Quiere transferir Z unidades de Y a Bob. Este lote de activos pasó por un total de 5 propietarios anteriores (incluido el emisor del activo) antes de llegar a manos de Alice. Por lo tanto, Alice necesita proporcionarle a Bob evidencia de estas cuatro transiciones de estado (las primeras tres le fueron proporcionadas a Alice por el propietario anterior), incluido el estado inicial del contrato y las reglas de transición de estado, y los bits utilizados para cada transferencia. Las transacciones de Bitcoin, las transacciones RGB realizadas por cada intercambio de Bitcoin y la evidencia de que estas transacciones de Bitcoin han sido confirmadas por un determinado bloque se envían a Bob. Bob verificará que estas cuatro transferencias no violen las reglas de acuerdo con las reglas de transición estatales. del contrato., y luego decidir si lo acepta. Cuando Alice construye la transacción RGB, dado que Z es más pequeño que X, también tiene que organizar un UTXO para recibir la parte restante. Finalmente, Alice incorpora el valor hash de esta transacción RGB en la transacción de Bitcoin que le cuesta a UTXO A' completar el pago.
Finalmente, debido al uso de contenedores UTXO, el último estado de un contrato RGB se puede representar como un punto en un gráfico acíclico dirigido que no tiene descendientes (cada punto representa un estado almacenado en un contenedor UTXO). Además, para el propietario P en la figura siguiente, solo conocerá el proceso desde el estado inicial G del contrato para llegar a él, es decir, el proceso marcado por el círculo rojo, y no sabrá nada sobre los puntos grises:
VENTAJAS #RGB
Estado ligero verificable
Como se mencionó anteriormente, en comparación con los protocolos de emisión de activos anteriores (sistemas de contratos fuera de la cadena) que aparecieron en Bitcoin, RGB reduce significativamente el costo de verificación (un cierto estado de un contrato). Durante la transacción, el receptor ya no necesita atravesar todos los bloques para recopilar información sobre los cambios en el estado del contrato, sino que solo necesita obtener una serie de transacciones de Bitcoin, así como las transacciones RGB prometidas por estos intercambios y los bloques de estos Bitcoin. las transacciones contienen evidencia (basada en la evidencia de Merkle en el encabezado del bloque), puede estar seguro de que el pagador realmente posee una cierta cantidad de un determinado activo.
Esta reducción de los costos de verificación también reduce en gran medida la dependencia (confianza) de los usuarios de los grandes proveedores de infraestructura. En protocolos anteriores, debido al alto costo de verificación, era difícil para los usuarios calcular el estado más reciente del contrato por sí mismos, por lo que los usuarios tenían que confiar en algunos proveedores (como el proveedor del estado del contrato utilizado por su propia billetera); Al mismo tiempo, porque podían permitírselo. Hay menos proveedores para calcular los costos, lo que también significa centralización de proveedores. Pero en RGB, los usuarios solo necesitan usar el cliente ligero de Bitcoin para verificar la parte de la transacción con Bitcoin y 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 liviano. Esto se refleja en el hecho de que RGB puede verificar específicamente un determinado estado de un contrato; en aquellos sistemas que no están basados en UTXO, debido a la falta de un mecanismo para controlar el acceso como UTXO, cualquier transacción puede cambiar cualquier estado, por lo que Es casi imposible verificar específicamente un determinado estado, pero sólo se puede determinar un determinado estado mientras se calculan todos los estados más recientes; en este sentido, las características expresadas como "estado global" en realidad deberían denominarse "estado uniforme". proporciona la característica de acceso cruzado entre contratos, también determina que su costo de verificación será mayor y será más difícil obtener falta de confianza.
En estos protocolos de contrato en cadena, una medida de optimización importante es exigir que el encabezado del bloque se comprometa con el último estado ("estado raíz"), lo que permite a los clientes ligeros verificar un cierto estado de un contrato obtenido del nodo completo en función de estos compromisos... Este es un método para reutilizar cálculos que ya se han producido (cálculos que han sido ejecutados por el nodo completo) y también es muy eficiente, por lo que si no se considera la falta de confianza, puede considerarse más eficiente que RGB. Sin embargo, después de todo, significa que los nodos ligeros dependen de nodos completos para la verificación básica de transacciones y el cálculo del estado del contrato. En la billetera RGB que utiliza el cliente ligero de Bitcoin, la suposición de confianza en la que se basa es que la transacción de Bitcoin relevante es una transacción válida y la parte relacionada con el estado del contrato ha sido verificada personalmente por el cliente, por lo que es más confiable. gratis. . La desventaja es que el retraso en la verificación es mayor y es necesario conservar más datos.
Escalabilidad
La escalabilidad de RGB se refleja en dos aspectos:
Incrustado en la transacción de Bitcoin hay solo un valor hash, lo que significa que no hay límite en el volumen de la transacción RGB (excepto por las reglas personalizadas del contrato), incluso si divide un activo RGB en 100 partes (la transacción RGB en sí será muy grande), y solo hay un valor hash que debe incorporarse en una transacción de Bitcoin. Como se menciona en la Nota 6, hay dos formas de incrustar dicho valor hash: una es usar la salida OP_RETURN, lo que significa que consumirá el espacio en cadena de un valor hash; la otra es ocultar la salida pública del script. en la clave Taproot: esto 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, considerando únicamente las tarifas en cadena.
El último estado del contrato RGB es un punto independiente en un gráfico acíclico dirigido sin descendientes; esto significa que estos estados se pueden cambiar de forma independiente sin afectarse entre sí, lo que significa que se permite la concurrencia. En realidad, esta es una característica heredada de UTXO. Esto también significa que los cambios no válidos (transacciones no válidas) que ocurren en una sucursal no afectarán a otras sucursales, y mucho menos provocarán que todo el contrato se bloquee, por lo que también puede considerarse como un beneficio de seguridad.
Un punto que ha sido criticado por la escalabilidad de RGB es que cada transferencia requiere que el destinatario verifique todas las transacciones involucradas desde el estado inicial hasta el estado del pagador: a medida que aumenta el número de veces que el activo cambia de manos, aumenta la carga de verificación para los destinatarios posteriores. se volverá más y más pesado. Esta crítica es cierta. Optimizarlo significa que también necesitamos encontrar una manera de reutilizar operaciones que ya han ocurrido. Las tecnologías de sistemas de prueba, como SNARK, prometen proporcionar dicha solución.
Diferenciación de la definición de activos y el mecanismo de custodia
El último beneficio todavía está relacionado con UTXO y depende de cómo entendamos el mecanismo del script de bloqueo de UTXO.
Se puede utilizar un script de bloqueo para programar las condiciones de desbloqueo de un fondo y, por lo tanto, puede implementar reglas de custodia. Por ejemplo, si un script de bloqueo contiene una y sólo una clave pública, eso significa que sólo el propietario de la clave privada correspondiente puede controlarlo. Sin embargo, dichas reglas de custodia también son la base para la programación del protocolo de contrato de Bitcoin. Por ejemplo, un UTXO que utiliza un script de bloqueo de firmas múltiples 2 de 2 puede ser un canal relámpago; durante la operación del canal, las dos partes pueden pagarse entre sí casi innumerables veces sin ningún cambio en la forma de la cadena. los fondos. En otras palabras, en este momento, el script de bloqueo de firmas múltiples 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 la cadena.
Este mecanismo se puede utilizar para el valor de Bitcoin que porta UTXO y, naturalmente, también se puede utilizar para los activos RGB que porta. Podemos emitir un activo RGB y adjuntarlo a un UTXO de firma múltiple 2 de 2, utilizando así el mecanismo del canal Lightning para pagar este activo entre sí un número ilimitado de veces. Del mismo modo, los activos RGB también se pueden celebrar en otros contratos basados en scripts de Bitcoin.
Aquí, el script UTXO y el protocolo RGB forman una diferenciación funcional: el primero se compromete a implementar las reglas de custodia y transferencia de valor; mientras que el segundo se centra en la definición de activos. Por tanto, la custodia de los activos y la definición de activos pueden separarse. Esta es una mejora de seguridad importante y algo por lo que la gente se está esforzando en otros sistemas de contratos en cadena.
Diseño RGB ya realizado
Las características anteriores son en realidad válidas para todos los protocolos basados en el sellado único UTXO y la verificación del cliente. Pero sobre esta base, se ha diseñado aún más el protocolo RGB.
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 en dos aspectos:
UTXO ciego. En una transacción RGB, el destinatario solo necesita usar el identificador UTXO ofuscado para recibir el activo sin exponer las características del UTXO que realmente recibió el activo. Esto no perjudica la capacidad del destinatario de proporcionar pruebas al siguiente propietario, al tiempo que permite a los siguientes destinatarios de activos defenderse de las miradas indiscretas del anterior propietario de activos.
A prueba de balas. Se puede utilizar para ocultar el monto específico en cada transacción. Sin embargo, los propietarios de activos posteriores aún pueden verificar que no se haya producido ninguna emisión adicional antes.
Espacio por explorar
En esta sección, discutiré el espacio que el protocolo RGB puede continuar explorando, principalmente relacionado con la programabilidad.
Actualmente, las plantillas de contrato RGB (esquema) que se han propuesto se centran en la emisión de activos. Sin embargo, dado que RGB utiliza el paradigma de "verificación del lado del cliente", en realidad podemos agregarle cualquier característica que pueda garantizarse mediante la verificación del lado del cliente, solo limitado por la estructura de UTXO.
Restricciones
Sobre la base de UTXO, un concepto que puede ampliar la programabilidad se denomina "pactos". La intención original de una cláusula de restricción es limitar el destino al que se puede transferir una suma de dinero. Con esta capacidad podremos programar muchas aplicaciones interesantes, como por ejemplo:
Fondo común para retiros no interactivos. Podemos agrupar los fondos de muchas personas en una misma UTXO y utilizar cláusulas de restricción para asegurar que cualquiera de ellas pueda retirar sus propios fondos sin la ayuda de otros. Esto puede tener el efecto de ayudar a las personas a salir de lugares de alto riesgo a bajo costo cuando la demanda de espacio en bloques es alta.
Contrato de bóveda. Primero se debe gastar un fondo en algún lugar y pasar por un bloqueo de tiempo antes de poder gastarlo libremente; durante el período de bloqueo de tiempo, el propietario de la caja fuerte puede interrumpir este proceso con una llave de emergencia e inmediatamente transferir los fondos a otro lugar. Este dispositivo puede ser de gran ayuda para la custodia autónoma.
El Bitcoin Script actual no tiene esta capacidad, por lo que habilitar restricciones en Bitcoin Script requiere una bifurcación suave.
Sin embargo, siempre que estemos dispuestos a sacrificar algunos de los beneficios que aporta la "diferenciación de la definición de activos y los mecanismos de custodia", podemos experimentar con tales características en activos RGB. Podemos implementar dichas funciones a nivel de contrato RGB, aunque puede Solo no funciona para activos RGB que lo usan (y no para Bitcoin), pero definitivamente abrirá un espacio interesante.
Las investigaciones existentes sobre cláusulas de restricción muestran que pueden ampliar el espacio de programación de transacciones basadas en UTXO y proporcionar muchas funciones. Pero estos estudios se basan básicamente en Bitcoin, y en protocolos como Bitcoin, seremos más conservadores. En RGB, podemos generalizar audazmente la capacidad central de las cláusulas de restricción (la capacidad de leer transacciones que se gastan a nivel de script) para proporcionar una programabilidad más flexible: la capacidad de acceder a contratos de forma cruzada.
Acceso cruzado
Los términos mínimamente restrictivos significan que cuando se gasta un UTXO, su script puede leer el resultado de la transacción de gasto. Pero una restricción completamente generalizada significa que puede leer todas las partes de la transacción en la que se gastó. Esto significa que también puede leer otras entradas de la transacción. Si no limitamos que otras entradas provengan del mismo contrato, significa que puede leer el estado de otros contratos.
En RGB, por defecto cada contrato es un universo independiente con su propio gráfico acíclico dirigido. Sin embargo, todavía es posible que un usuario tenga el estado de dos contratos diferentes al mismo tiempo. Si las transacciones RGB permitieran el gasto simultáneo de activos de ambos contratos, tales capacidades de acceso cruzado podrían tener aplicaciones (aunque posiblemente podrían complicar más 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 de contratos. Este es un campo muy nuevo, que se abre a áreas rara vez abordadas por investigaciones anteriores de Bitcoin, y puede haber algunas sorpresas enterradas allí.
en conclusión
En este artículo, los lectores encontrarán que hay un concepto que se menciona con frecuencia y recorre todos los procesos de razonamiento y fantasía: "UTXO". Esta es exactamente mi intención. Si no comprende UTXO, no puede comprender el punto de partida del diseño de un protocolo como RGB, ni puede comprender las ventajas del diseño del protocolo RGB, ni puede imaginar cómo la gente lo usa. Las características del protocolo RGB están determinadas en gran medida por su forma UTXO sellada una sola vez. En consecuencia, la investigación sobre UTXO acumulada en el campo de investigación de Bitcoin también se puede aplicar a la investigación sobre RGB.
Esto también explica por qué a las personas que no entienden Bitcoin les resultará difícil entender RGB. Las personas a las que les gusta Bitcoin reconocerán el diseño que ha realizado RGB.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Comprenda el verdadero potencial del protocolo de emisión de activos RGB en un artículo
Autor: A Jian
Este artículo intenta proporcionar una descripción concisa de RGB, un protocolo de emisión de activos en Bitcoin (también puede entenderse como un sistema de contrato inteligente fuera de la cadena), y señala que es muy diferente de otros proyectos que apuntan Para lograr protocolos funcionales iguales o similares, estas diferencias hacen que el protocolo RGB sea mucho más escalable que ellos y deja un espacio de programación más amplio. Además de presentar los diseños completos de RGB, también exploraremos estas posibilidades de programación.
¿Qué es el protocolo RGB?
La idea de emitir activos en Bitcoin existe desde hace mucho tiempo. Pero el protocolo Bitcoin tiene sus propias características: su estado se expresa únicamente por Bitcoin UTXO ("salida de transacción no gastada"); un UTXO sólo lleva dos datos: su propia denominación (valor de Bitcoin) y una "clave pública de script" (también conocido como "script de bloqueo"), utilizado para programar las condiciones de gasto de este fondo, por ejemplo: proporcionar una firma de una determinada clave pública; permitir que el código de operación utilizado para programar el script de bloqueo sea determinado por las reglas de consenso de Bitcoin siempre que no puedan utilizarse para implementar reglas de seguridad arbitrarias. Por lo tanto, es imposible crear otros activos dentro de UTXO: el script de Bitcoin no puede programar controles de seguridad para estos activos. Esto significa que todas las ideas para emitir activos en Bitcoin son esencialmente usos creativos del espacio de bloques de Bitcoin. Esto significa que necesitamos diseñar un sistema de contrato inteligente fuera de la cadena y requerir los pasos para cambiar el estado del contrato; por ejemplo, el contrato A cambia los parámetros y B transfiere una cierta cantidad de un determinado activo a C —— La información se carga en la cadena de bloques, de modo que se puede obtener el estado más reciente del sistema de contrato inteligente al recopilar esta información.
Una idea aproximada de diseño es cargar la información de los pasos que cambian el estado del contrato en la cadena de bloques de Bitcoin intacta. Esto ciertamente funciona, pero enfrenta varios problemas:
(1) Dado que se carga la información completa, puede consumir más espacio en el bloque. Cuando los usuarios necesiten cambiar el estado del contrato (como una transferencia), también deberán pagar más tarifas de manejo en la cadena. En particular, cuando esperamos que dicho sistema de contratos fuera de la cadena tenga una mejor programabilidad que Bitcoin, el aumento de la programabilidad puede producirse a expensas de consumir más espacio de bloque;
(2) Casi cualquier información en el bloque puede cambiar el contrato inteligente fuera de la cadena, por lo que los usuarios deben obtener todos los datos del bloque de Bitcoin para obtener el estado más reciente del sistema de contrato 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 pueda obtener una privacidad comparable a la de Bitcoin, o incluso peor; y si puede proporcionar más privacidad, es posible que necesite consumir más área. bloquear el espacio.
En el pasado, un protocolo ampliamente utilizado llamado "Omni" no cargaba información completa sobre las transacciones de contratos fuera de la cadena, sino solo el valor hash de la transacción. Este enfoque resuelve los problemas anteriores y desacopla la complejidad de las transacciones de contratos fuera de la cadena de sus costos económicos; sin embargo, los usuarios aún necesitan obtener la cantidad total de datos del bloque Bitcoin para obtener el estado más reciente del protocolo Omni; además, no No diseñado específicamente para mejorar la privacidad.
RGB utiliza un nuevo paradigma llamado "sellos de un solo uso". Su uso es muy simple: RGB requiere que cada estado de cada contrato esté asociado a un determinado UTXO de Bitcoin; y una vez que quieras cambiar este estado, debes gastar este UTXO y dejar que la transacción que lo gasta obtenga la Confirmación en la cadena de bloques; Además, la transacción de Bitcoin que lo gasta también debe proporcionar un hash del contenido de la transición de estado para indicar el UTXO adjunto al estado alterado.
Para los desarrolladores de RGB, el diseño es similar a un sello de plástico numerado: es fácil saber si se ha quitado y, una vez retirado, no se puede reutilizar. Sin embargo, otra perspectiva es considerar el UTXO poseído como el contenedor o alcancía de cerámica en este estado: si quieres sacar el dinero de la alcancía, debes romper la alcancía y luego poner el dinero dentro. en el nuevo frasco.
Este diseño contrasta marcadamente con protocolos anteriores que trataban todo el bloque como un gran tablero de escritura: usar UTXO como contenedor significa que las transacciones que no gastan este UTXO no pueden tener ningún impacto en el estado del contrato en el contenedor. Para un determinado estado de un determinado contrato, no necesitamos obtener los datos de todos los bloques, todo lo que necesitamos es una serie de transacciones de Bitcoin, evidencia de que estas transacciones de Bitcoin existen en un determinado bloque y estos bits La conversión de estado RGB prometida por el cambio de moneda (un par con la transacción Bitcoin correspondiente) es suficiente. Estos datos, que pueden conectarse en cadena, deberían permitirnos rastrear el estado inicial de este contrato, permitiéndonos identificar la esencia de este estado.
Para los lectores que están familiarizados con los sistemas de contratos inteligentes en cadena (como Ethereum), una cosa que es difícil de entender acerca de este proceso es que si no depende del consenso de la cadena de bloques (lo que significa que el estado inicial de la contrato y cada cambio de estado será verificado por cada nodo), ¿cómo se garantiza la seguridad de este sistema de contrato inteligente? ¿Cómo garantizar que los activos que recibe sean los que desea y cómo garantizar que no hayan sido emitidos ilegalmente?
La respuesta también es muy simple: se llama "validación del lado del cliente": usted mismo la verifica. En el sistema de contrato en cadena, los nodos verifican cada operación de transición de estado de acuerdo con las reglas públicas de transición de estado, rechazan operaciones no válidas y luego calculan el último estado en función del estado inicial. Sin embargo, siempre que se conozcan las reglas de transición de estado y el estado inicial, la verificación a través del consenso en la cadena no es la única manera. Los usuarios pueden verificar si cada paso de la transición de estado sigue la transición de estado definida originalmente en función de la información proporcionada por el pagador regla. De esta manera, la parte verificadora (supuestamente el destinatario del activo) también puede detectar transiciones de estado ilegales y negarse a aceptarlas.
Finalmente, usamos un ejemplo para demostrar las características del protocolo RGB:
Ahora, Alice posee UTXO A, que contiene X unidades del activo Y emitidas según el protocolo RGB. Quiere transferir Z unidades de Y a Bob. Este lote de activos pasó por un total de 5 propietarios anteriores (incluido el emisor del activo) antes de llegar a manos de Alice. Por lo tanto, Alice necesita proporcionarle a Bob evidencia de estas cuatro transiciones de estado (las primeras tres le fueron proporcionadas a Alice por el propietario anterior), incluido el estado inicial del contrato y las reglas de transición de estado, y los bits utilizados para cada transferencia. Las transacciones de Bitcoin, las transacciones RGB realizadas por cada intercambio de Bitcoin y la evidencia de que estas transacciones de Bitcoin han sido confirmadas por un determinado bloque se envían a Bob. Bob verificará que estas cuatro transferencias no violen las reglas de acuerdo con las reglas de transición estatales. del contrato., y luego decidir si lo acepta. Cuando Alice construye la transacción RGB, dado que Z es más pequeño que X, también tiene que organizar un UTXO para recibir la parte restante. Finalmente, Alice incorpora el valor hash de esta transacción RGB en la transacción de Bitcoin que le cuesta a UTXO A' completar el pago.
Finalmente, debido al uso de contenedores UTXO, el último estado de un contrato RGB se puede representar como un punto en un gráfico acíclico dirigido que no tiene descendientes (cada punto representa un estado almacenado en un contenedor UTXO). Además, para el propietario P en la figura siguiente, solo conocerá el proceso desde el estado inicial G del contrato para llegar a él, es decir, el proceso marcado por el círculo rojo, y no sabrá nada sobre los puntos grises:
VENTAJAS #RGB
Estado ligero verificable
Como se mencionó anteriormente, en comparación con los protocolos de emisión de activos anteriores (sistemas de contratos fuera de la cadena) que aparecieron en Bitcoin, RGB reduce significativamente el costo de verificación (un cierto estado de un contrato). Durante la transacción, el receptor ya no necesita atravesar todos los bloques para recopilar información sobre los cambios en el estado del contrato, sino que solo necesita obtener una serie de transacciones de Bitcoin, así como las transacciones RGB prometidas por estos intercambios y los bloques de estos Bitcoin. las transacciones contienen evidencia (basada en la evidencia de Merkle en el encabezado del bloque), puede estar seguro de que el pagador realmente posee una cierta cantidad de un determinado activo.
Esta reducción de los costos de verificación también reduce en gran medida la dependencia (confianza) de los usuarios de los grandes proveedores de infraestructura. En protocolos anteriores, debido al alto costo de verificación, era difícil para los usuarios calcular el estado más reciente del contrato por sí mismos, por lo que los usuarios tenían que confiar en algunos proveedores (como el proveedor del estado del contrato utilizado por su propia billetera); Al mismo tiempo, porque podían permitírselo. Hay menos proveedores para calcular los costos, lo que también significa centralización de proveedores. Pero en RGB, los usuarios solo necesitan usar el cliente ligero de Bitcoin para verificar la parte de la transacción con Bitcoin y 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 liviano. Esto se refleja en el hecho de que RGB puede verificar específicamente un determinado estado de un contrato; en aquellos sistemas que no están basados en UTXO, debido a la falta de un mecanismo para controlar el acceso como UTXO, cualquier transacción puede cambiar cualquier estado, por lo que Es casi imposible verificar específicamente un determinado estado, pero sólo se puede determinar un determinado estado mientras se calculan todos los estados más recientes; en este sentido, las características expresadas como "estado global" en realidad deberían denominarse "estado uniforme". proporciona la característica de acceso cruzado entre contratos, también determina que su costo de verificación será mayor y será más difícil obtener falta de confianza.
En estos protocolos de contrato en cadena, una medida de optimización importante es exigir que el encabezado del bloque se comprometa con el último estado ("estado raíz"), lo que permite a los clientes ligeros verificar un cierto estado de un contrato obtenido del nodo completo en función de estos compromisos... Este es un método para reutilizar cálculos que ya se han producido (cálculos que han sido ejecutados por el nodo completo) y también es muy eficiente, por lo que si no se considera la falta de confianza, puede considerarse más eficiente que RGB. Sin embargo, después de todo, significa que los nodos ligeros dependen de nodos completos para la verificación básica de transacciones y el cálculo del estado del contrato. En la billetera RGB que utiliza el cliente ligero de Bitcoin, la suposición de confianza en la que se basa es que la transacción de Bitcoin relevante es una transacción válida y la parte relacionada con el estado del contrato ha sido verificada personalmente por el cliente, por lo que es más confiable. gratis. . La desventaja es que el retraso en la verificación es mayor y es necesario conservar más datos.
Escalabilidad
La escalabilidad de RGB se refleja en dos aspectos:
Incrustado en la transacción de Bitcoin hay solo un valor hash, lo que significa que no hay límite en el volumen de la transacción RGB (excepto por las reglas personalizadas del contrato), incluso si divide un activo RGB en 100 partes (la transacción RGB en sí será muy grande), y solo hay un valor hash que debe incorporarse en una transacción de Bitcoin. Como se menciona en la Nota 6, hay dos formas de incrustar dicho valor hash: una es usar la salida OP_RETURN, lo que significa que consumirá el espacio en cadena de un valor hash; la otra es ocultar la salida pública del script. en la clave Taproot: esto 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, considerando únicamente las tarifas en cadena.
El último estado del contrato RGB es un punto independiente en un gráfico acíclico dirigido sin descendientes; esto significa que estos estados se pueden cambiar de forma independiente sin afectarse entre sí, lo que significa que se permite la concurrencia. En realidad, esta es una característica heredada de UTXO. Esto también significa que los cambios no válidos (transacciones no válidas) que ocurren en una sucursal no afectarán a otras sucursales, y mucho menos provocarán que todo el contrato se bloquee, por lo que también puede considerarse como un beneficio de seguridad.
Un punto que ha sido criticado por la escalabilidad de RGB es que cada transferencia requiere que el destinatario verifique todas las transacciones involucradas desde el estado inicial hasta el estado del pagador: a medida que aumenta el número de veces que el activo cambia de manos, aumenta la carga de verificación para los destinatarios posteriores. se volverá más y más pesado. Esta crítica es cierta. Optimizarlo significa que también necesitamos encontrar una manera de reutilizar operaciones que ya han ocurrido. Las tecnologías de sistemas de prueba, como SNARK, prometen proporcionar dicha solución.
Diferenciación de la definición de activos y el mecanismo de custodia
El último beneficio todavía está relacionado con UTXO y depende de cómo entendamos el mecanismo del script de bloqueo de UTXO.
Se puede utilizar un script de bloqueo para programar las condiciones de desbloqueo de un fondo y, por lo tanto, puede implementar reglas de custodia. Por ejemplo, si un script de bloqueo contiene una y sólo una clave pública, eso significa que sólo el propietario de la clave privada correspondiente puede controlarlo. Sin embargo, dichas reglas de custodia también son la base para la programación del protocolo de contrato de Bitcoin. Por ejemplo, un UTXO que utiliza un script de bloqueo de firmas múltiples 2 de 2 puede ser un canal relámpago; durante la operación del canal, las dos partes pueden pagarse entre sí casi innumerables veces sin ningún cambio en la forma de la cadena. los fondos. En otras palabras, en este momento, el script de bloqueo de firmas múltiples 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 la cadena.
Este mecanismo se puede utilizar para el valor de Bitcoin que porta UTXO y, naturalmente, también se puede utilizar para los activos RGB que porta. Podemos emitir un activo RGB y adjuntarlo a un UTXO de firma múltiple 2 de 2, utilizando así el mecanismo del canal Lightning para pagar este activo entre sí un número ilimitado de veces. Del mismo modo, los activos RGB también se pueden celebrar en otros contratos basados en scripts de Bitcoin.
Aquí, el script UTXO y el protocolo RGB forman una diferenciación funcional: el primero se compromete a implementar las reglas de custodia y transferencia de valor; mientras que el segundo se centra en la definición de activos. Por tanto, la custodia de los activos y la definición de activos pueden separarse. Esta es una mejora de seguridad importante y algo por lo que la gente se está esforzando en otros sistemas de contratos en cadena.
Diseño RGB ya realizado
Las características anteriores son en realidad válidas para todos los protocolos basados en el sellado único UTXO y la verificación del cliente. Pero sobre esta base, se ha diseñado aún más el protocolo RGB.
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 en dos aspectos:
UTXO ciego. En una transacción RGB, el destinatario solo necesita usar el identificador UTXO ofuscado para recibir el activo sin exponer las características del UTXO que realmente recibió el activo. Esto no perjudica la capacidad del destinatario de proporcionar pruebas al siguiente propietario, al tiempo que permite a los siguientes destinatarios de activos defenderse de las miradas indiscretas del anterior propietario de activos.
A prueba de balas. Se puede utilizar para ocultar el monto específico en cada transacción. Sin embargo, los propietarios de activos posteriores aún pueden verificar que no se haya producido ninguna emisión adicional antes.
Espacio por explorar
En esta sección, discutiré el espacio que el protocolo RGB puede continuar explorando, principalmente relacionado con la programabilidad.
Actualmente, las plantillas de contrato RGB (esquema) que se han propuesto se centran en la emisión de activos. Sin embargo, dado que RGB utiliza el paradigma de "verificación del lado del cliente", en realidad podemos agregarle cualquier característica que pueda garantizarse mediante la verificación del lado del cliente, solo limitado por la estructura de UTXO.
Restricciones
Sobre la base de UTXO, un concepto que puede ampliar la programabilidad se denomina "pactos". La intención original de una cláusula de restricción es limitar el destino al que se puede transferir una suma de dinero. Con esta capacidad podremos programar muchas aplicaciones interesantes, como por ejemplo:
Fondo común para retiros no interactivos. Podemos agrupar los fondos de muchas personas en una misma UTXO y utilizar cláusulas de restricción para asegurar que cualquiera de ellas pueda retirar sus propios fondos sin la ayuda de otros. Esto puede tener el efecto de ayudar a las personas a salir de lugares de alto riesgo a bajo costo cuando la demanda de espacio en bloques es alta.
Contrato de bóveda. Primero se debe gastar un fondo en algún lugar y pasar por un bloqueo de tiempo antes de poder gastarlo libremente; durante el período de bloqueo de tiempo, el propietario de la caja fuerte puede interrumpir este proceso con una llave de emergencia e inmediatamente transferir los fondos a otro lugar. Este dispositivo puede ser de gran ayuda para la custodia autónoma.
El Bitcoin Script actual no tiene esta capacidad, por lo que habilitar restricciones en Bitcoin Script requiere una bifurcación suave.
Sin embargo, siempre que estemos dispuestos a sacrificar algunos de los beneficios que aporta la "diferenciación de la definición de activos y los mecanismos de custodia", podemos experimentar con tales características en activos RGB. Podemos implementar dichas funciones a nivel de contrato RGB, aunque puede Solo no funciona para activos RGB que lo usan (y no para Bitcoin), pero definitivamente abrirá un espacio interesante.
Las investigaciones existentes sobre cláusulas de restricción muestran que pueden ampliar el espacio de programación de transacciones basadas en UTXO y proporcionar muchas funciones. Pero estos estudios se basan básicamente en Bitcoin, y en protocolos como Bitcoin, seremos más conservadores. En RGB, podemos generalizar audazmente la capacidad central de las cláusulas de restricción (la capacidad de leer transacciones que se gastan a nivel de script) para proporcionar una programabilidad más flexible: la capacidad de acceder a contratos de forma cruzada.
Acceso cruzado
Los términos mínimamente restrictivos significan que cuando se gasta un UTXO, su script puede leer el resultado de la transacción de gasto. Pero una restricción completamente generalizada significa que puede leer todas las partes de la transacción en la que se gastó. Esto significa que también puede leer otras entradas de la transacción. Si no limitamos que otras entradas provengan del mismo contrato, significa que puede leer el estado de otros contratos.
En RGB, por defecto cada contrato es un universo independiente con su propio gráfico acíclico dirigido. Sin embargo, todavía es posible que un usuario tenga el estado de dos contratos diferentes al mismo tiempo. Si las transacciones RGB permitieran el gasto simultáneo de activos de ambos contratos, tales capacidades de acceso cruzado podrían tener aplicaciones (aunque posiblemente podrían complicar más 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 de contratos. Este es un campo muy nuevo, que se abre a áreas rara vez abordadas por investigaciones anteriores de Bitcoin, y puede haber algunas sorpresas enterradas allí.
en conclusión
En este artículo, los lectores encontrarán que hay un concepto que se menciona con frecuencia y recorre todos los procesos de razonamiento y fantasía: "UTXO". Esta es exactamente mi intención. Si no comprende UTXO, no puede comprender el punto de partida del diseño de un protocolo como RGB, ni puede comprender las ventajas del diseño del protocolo RGB, ni puede imaginar cómo la gente lo usa. Las características del protocolo RGB están determinadas en gran medida por su forma UTXO sellada una sola vez. En consecuencia, la investigación sobre UTXO acumulada en el campo de investigación de Bitcoin también se puede aplicar a la investigación sobre RGB.
Esto también explica por qué a las personas que no entienden Bitcoin les resultará difícil entender RGB. Las personas a las que les gusta Bitcoin reconocerán el diseño que ha realizado RGB.