Se revela la hoja de ruta del lanzamiento de la versión RGB V0.11: Resumen del lanzamiento de Quest Asset

Nombres: Zoom, Echo, BiHelix

Director: Hong Shuning

Introducción

Mientras Nervos creó conjuntamente Cipher y propuso una solución llamada RGB ++, la discusión y la acalorada discusión sobre el protocolo nativo RGB en el mercado también están creciendo día a día. Como sistema de contrato inteligente escalable y confidencial de Bitcoin y Lightning Network creado por la Asociación de Estándares LNP/BP, RGB siempre ha sido favorecido por los desarrolladores ecológicos de Bitcoin y se considera un vínculo con gran potencial en el protocolo de expansión nativo de BTC. Como infraestructura para las finanzas descentralizadas de Bitcoin (BTCfi) y las aplicaciones (DApps), RGB marca un paso histórico en la expansión de la utilidad de Bitcoin desde una única función de depósito de valor a una gama más amplia de campos. La innovación tecnológica que lidera no sólo es emocionante, sino que también traerá nuevas direcciones y posibilidades de desarrollo a todo el ecosistema de las criptomonedas.

A finales de 2023, para afrontar mejor los desafíos del mercado y promover el vigoroso desarrollo del ecosistema Bitcoin, el equipo nativo de RGB, LNP/BP Standards Association, anunció que RGB se actualizará y lanzará la versión 0.11. Recientemente, Maxim Orlovsky y la Asociación de Estándares LNP/BP que fundó lanzaron la hoja de ruta de lanzamiento de la versión RGBv 0.11, que incluye todas las tareas y promociones necesarias para la versión candidata v 0.11. Las tareas se dividen en nivel de consenso y nivel de aplicación. Versión BiHelixRGBRGB v 0.11.

Este artículo presentará en detalle la base funcional y técnica de la actualización del protocolo RGB v 0.11 y proporcionará una descripción general completa de las funciones de generación de activos y funciones de transacción admitidas por RGB v 0.11, incluido el uso de consenso de prueba confiable, optimización de escalabilidad y mejoras clave de seguridad. Proporcionamos una mirada en profundidad a los fundamentos y las compensaciones de la prueba de creencia en comparación con los esquemas de consenso existentes, así como puntos de referencia cuantitativos para los ahorros de gas y los aumentos de rendimiento desbloqueados por la prueba v 0.11.

Generación de activos RGB

Actualmente hay tres tipos de activos integrados en el protocolo RGB V 0.11, incluidos RGB 20 (tokens), RGB 21 (NFT) y RGB 25. Tomando RGB 20 como ejemplo, analizamos los pasos de implementación y los derechos exigibles del protocolo actual.

1. Primero, el emisor del contrato debe establecer el estado inicial del token RGB de acuerdo con el protocolo RGB 20, como definir los detalles del contrato: el nombre del activo, emisión inicial, suministro total, emisión adicional, cambio de nombre, destrucción y otros permisos, etc.

2. En segundo lugar, el emisor del contrato especifica un UTXO para recibir la emisión inicial, de modo que se pueda crear un activo RGB simple. El cambio de estado se puede aplicar al derecho a cambiar la titularidad del bien, o a otro tipo de derechos. Por ejemplo:

• Interfaz de emisión adicional: cuando el contrato habilita un permiso de emisión adicional, se debe designar una dirección para recibir la emisión adicional de activos. Por supuesto, RGB 20 limita el límite superior de emisiones adicionales y los emisores por contrato no pueden emitir emisiones adicionales ilimitadas.

• Interfaz de destrucción: el emisor del contrato puede designar a una o más personas para que tengan la autoridad de destrucción del token. Debido a que RGB 20 utiliza transacciones P2P (que se presentarán en el capítulo sobre transacciones), es difícil para los usuarios colocar tokens en una dirección de agujero negro para su destrucción.

• Interfaz de cambio de nombre: el contrato puede actualizar el nombre del activo.

Debido a que el código del contrato RGB se almacena fuera de la cadena, si el emisor del contrato no autoriza el código abierto, será difícil para los usuarios verificar la información de los activos. Una vez que se emite el contrato RGB, tanto el usuario como el emisor deben cumplir con la definición estatal cuando se emite el contrato para evitar que el emisor cometa actos malvados.

Transferencia de activos RGB

El modelo de transacción de RGB adopta la transferencia P2P (Peer to Peer), que es muy diferente de ETH. Este modo de transferencia requiere que ambas partes estén en línea. Por ejemplo, la operación “A quiere enviar 100 tokens a B” es la siguiente:

1. B crea una factura especificando el envío de 100 tokens.

2. El destinatario A propone una transferencia.

3. B confirma la transferencia y firma.

4. Una transacción de transmisión.

5. A y B aceptan la transacción.

Entre ellos, B envía la factura a A. Después de recibir la factura, A solo puede seguir el contenido de la factura y enviar 100 tokens a B. B necesita confirmar que ha recibido 100 tokens para tener éxito.

• P: ¿Por qué ambas partes necesitan estar en línea?

• A: Debido a que la factura es urgente y dejará de ser válida si no se usa durante un período de tiempo, A necesita transferir el dinero inmediatamente después de recibir la factura de B. B también debe asegurarse de que A pueda utilizar la factura inmediatamente antes de crearla. Esto restringe a ambas partes a completar la transferencia dentro del período de validez de la factura.

Figura: Transacción del canal Lightning Network

Debido a que el canal de transacciones utilizado por RGB integra Lightning Network, el proceso de transacción puede referirse al proceso de transferencia de Lightning Network, excepto que se agrega el paso de “reconfirmación por parte del beneficiario”. Estos pasos de transacción evitan que el beneficiario reciba monedas de phishing sucias, protegiendo así la seguridad de las billeteras de los usuarios.

Comercio de activos RGB

Puntos técnicos en el proceso de transferencia de activos RGB

1. Sello desechable

Esta tecnología fue propuesta por primera vez por Peter Todd en 2016. Su significado principal es “agregar un sello a un mensaje para garantizar que el mensaje solo se pueda usar una vez, porque debe quitar el sello para conocer el mensaje”.

Un método sencillo es configurar un servidor externo notariado que publique un certificado en un registro público cada vez que se abre o bloquea un sello, de modo que cualquiera pueda verificar el estado del sello que le interesa.

Si no utiliza una entidad confiable para implementar la función de sello único, puede usar el UTXO de Bitcoin como sello. Porque cualquier UTXO en Bitcoin sólo se puede gastar una vez. Por lo tanto, al usar UTXO como sello, puede bloquear el UTXO cuando se crea y abrirlo cuando lo gasta.

RGB utiliza una tecnología de “sellado único”, que “envuelve” la información de los activos RGB, el estado del contrato, etc. en UTXO. Cuando se gasta UTXO, la propiedad del activo y el estado del contrato cambian. Esto significa que cada vez que ocurre una transacción RGB, el remitente en realidad está creando un cambio de estado en un contrato (el que define los derechos que se transfieren).

2. Verificación del cliente

La verificación RGB es diferente de la verificación tradicional de “consenso global” y utiliza tecnología de “verificación del cliente”. En el método tradicional de verificación de Bitcoin, un nodo conectado a la red descarga y verifica continuamente bloques y transacciones en el grupo de transacciones (nodo completo). Dicho nodo tiene una vista actualizada en tiempo real del conjunto UTXO en toda la cadena (el conjunto de todas las salidas no gastadas en la cadena de bloques). Cuando ve una nueva transacción, para verificar su validez, solo necesita verificar todas las entradas para la transacción es parte del último estado del conjunto UTXO.

Pero para RGB, no hay datos propagados globalmente, por lo que no existe tal visión global del conjunto UTXO. Después de que un cliente RGB acepta una transacción, no solo necesita verificar que el último estado de la transacción sea válido, sino que también debe realizar la misma verificación en todas las transformaciones de estado anteriores relacionadas con la transacción, hasta el estado inicial de el contrato de emisión. Esto parece tener una desventaja obvia: lleva tiempos de verificación muy largos. **Pero esto solo ocurre cuando “un activo tiene un largo historial de transacciones” y esta parte de los datos del historial de transacciones se puede verificar de antemano a través de una capa de intercambio de datos (de forma voluntaria). **

Esto también trae ventajas obvias: El cliente no necesita conocer ni verificar todas las transacciones que ocurren a nivel global. Debido a que solo necesita conocer las transacciones relacionadas con su propia billetera, no necesita verificar otras transacciones, por lo que la cantidad de datos que debe verificar cada cliente es menor y la escalabilidad del sistema mejora significativamente. BiHelix propone una solución recursiva de prueba de conocimiento cero para resolver completamente el problema de la verificación del lado del cliente de la cadena completa.

3. La promesa de certeza de Bitcoin

RGB evita el “doble gasto” mediante el compromiso RGB. Estos compromisos deben cumplirse:

• Se pueden comprometer múltiples transiciones de estado que involucran un contrato en una sola transacción de Bitcoin

• Cada transición de estado de contrato solo puede comprometerse una vez con una transacción de Bitcoin.

La forma específica de lograr esto es:

1. En primer lugar, todas las transiciones de estado relacionadas con un determinado contrato (o ID de activo) deben agregarse de manera determinista en un compromiso.

2. Luego, los compromisos de todos los activos transferidos se agregan en un árbol Merkle.

3. El valor hash raíz final es el compromiso RGB final.

4. Para garantizar la compatibilidad con otros protocolos que no tienen nada que ver con RGB pero que también necesitan utilizar compromisos deterministas de Bitcoin, los compromisos RGB y los compromisos de otros protocolos deben agregarse nuevamente (como se describe en el estándar LNPBP-4). , entonces obtenemos el valor ha. Hash es el mensaje que realmente está integrado en las transacciones de Bitcoin.

4. El procesamiento por lotes reduce los costos

Como se puede ver en la sección anterior, podemos “envolver” cualquier número de cambios de estado en un solo compromiso de Bitcoin, lo que teóricamente permite el procesamiento por lotes a gran escala, proporcionando así más escenarios de aplicación para los proveedores de servicios UTXO.

• Escenario: A quiere pagar a varias personas al mismo tiempo, transferir un activo RGB 20 a B, transferir un activo RGB 21 a C y transferir la propiedad de un contrato a D.

• Resultado: A solo necesita crear una transición de estado para cada uno de B, C y D, y confirmar todas las transiciones de estado en la misma transacción de Bitcoin, sin ocupar más bytes. Esto significa que los cambios de estado en diferentes estados se agrupan porque están envueltos en una promesa. **El costo marginal de las tarifas de manejo en cadena para cada pago RGB puede ser muy pequeño, porque la misma tarifa de manejo se amortiza equitativamente por cualquier número de transferencias. **

También hay limitaciones aquí, es decir: esta información de transición de estado debe “envolverse” en el mismo UTXO. Si hay varios UTXO, será necesario aumentar la entrada de la transacción y los costos correspondientes también aumentarán. Pero en comparación con la situación tradicional en la que cada cambio de estado requiere una transacción, se pueden lograr grandes mejoras.

5. Comunicación entre clientes

La comunicación con el cliente es común en el proceso de implementación de una transferencia RGB. El remitente debe compartir un “envío” con el receptor. Esta estructura de datos contiene toda la información necesaria para verificar la transferencia, incluidas todas las transiciones de estado que se pueden rastrear hasta el estado fundador del contrato y que deben transferirse desde del emisor al receptor a través de la comunicación. Sin embargo, el protocolo RGB no está restringido por canales de comunicación y tiene una variedad de métodos para compartir datos. Dos formas comunes de compartir datos:

• Storm: un sistema de almacenamiento y mensajería instantánea de igual a igual basado en Lightning Network.

• Servidor Proxy RGB: un servidor HTTP JSON-RPC estandarizado cuyos clientes pueden cargar y descargar datos. Los usuarios pueden ejecutar sus propios servidores proxy o utilizar servidores de terceros. Depender de servidores de terceros afecta la privacidad y la resistencia a la censura, pero no la seguridad

Comunicación con el cliente BiHelix también propone un protocolo de comunicación adaptativo para la optimización.

en conclusión

Aunque la versión actual RGB v 0.11 todavía se encuentra en la etapa Beta, no es difícil ver que muchos equipos de proyectos ecológicos RGB están contribuyendo activamente y trabajando juntos para promover la optimización fina de la versión v 0.11. **Como defensor del proyecto ecológico RGB y del protocolo RGB, el equipo de BiHelix ha estado trabajando arduamente para lograr la ingeniería y comercialización del protocolo RGB. **Su objetivo principal será acelerar la compatibilidad de Lightning Network y el protocolo RGB, mientras atrae activamente a más desarrolladores de ecosistemas de aplicaciones de alta calidad y les permite aprender y aplicar en profundidad el protocolo RGB.

Se cree que el conjunto de funciones de emisión de activos cada vez más maduro del protocolo RGB traerá más innovaciones al ecosistema de Bitcoin y una vez más llevará a todo el ecosistema de Bitcoin a nuevas alturas. Con la aplicación generalizada del protocolo RGB en la red de Bitcoin, este artículo También se convertirá en una referencia indispensable e importante para comprender el mecanismo y el diseño detrás de RGB. En este ecosistema vibrante, el futuro de RGB parece brillante, inyectando nueva vitalidad y posibilidades a la evolución de Bitcoin.