Reenviar el Título Original 'RGB++与同构绑定：CKB、Cardano与Fuel如何赋能比特币生态'

Resumen:· El protocolo de activos RGB++ propuesto por el equipo de CKB propusoLa esencia de la idea de "unión isomórfica" es utilizar CKB, Cardano, Fuel y otras blockchains basadas en el modelo de programación UTXO como una capa de expansión funcional que lleva "contenedores" de activos RGB.Esta unión isomórfica también es aplicable a protocolos de activos ecológicos de Bitcoin con características UTXO como Atomical y Runes, lo que facilita la creación de una capa de contrato inteligente fuera de la cadena para Bitcoin.

· En el protocolo RGB++, los usuarios no tienen que ejecutar el cliente para verificar personalmente los datos de la transacción, y pueden delegar tareas como la verificación de la validez de los activos y el almacenamiento de datos a cadenas UTXO como CKB y Cardano. Siempre y cuando seas “optimista” y creas que la seguridad de las cadenas públicas mencionadas es relativamente confiable, no es necesario verificarlo tú mismo;

· El protocolo RGB++ admite a los usuarios cambiar al modo de verificación del cliente. En este momento, todavía puedes usar CKB como una capa de almacenamiento de datos/DA sin tener que conservar los datos tú mismo. El protocolo RGB++ no requiere activos entre cadenas, y puede operar activos en la cadena CKB a través de cuentas de Bitcoin, y puede reducir la frecuencia de emisión de Compromisos a la cadena de Bitcoin, lo que también es propicio para apoyar escenarios Defi;

· Si se encuentra bajo el sistema de contrato EVM, muchas características de RGB++ no son fáciles de soportar. En conjunto, una capa de expansión de cadena pública/función adecuada para realizar un enlace isomórfico debería tener las siguientes características:

1. Utilice el modelo UTXO o un esquema de almacenamiento de estado similar;

2. Tiene una considerable programabilidad de UTXO, lo que permite a los desarrolladores escribir scripts de desbloqueo;

3. Hay un espacio de estado relacionado con UTXO que puede almacenar el estado de activos;

4. Puede soportar la operación de nodos ligeros de Bitcoin a través de contratos inteligentes u otros medios;

Además de CKB, Cardano y Fuel también pueden soportar el enlace isomórfico. Sin embargo, los dos últimos pueden tener algunas limitaciones en cuanto al lenguaje de contrato inteligente y los detalles de diseño del contrato. En la actualidad, parece que CKB es más adecuado que los dos últimos como una capa de expansión de funciones para protocolos de activos de Bitcoin enlazados de forma isomórfica.

En 2017, Cipher, cofundador de Nervos CKB, propuso por primera vez la idea del producto de enlace isomórfico. En comparación con otras soluciones de capa 2 de Bitcoin, el enlace isomórfico puede ser mejor compatible con protocolos de activos como RGB, Runes y Atomical, y puede evitar factores como activos entre cadenas que generan cargas de seguridad adicionales.

Para ser simple, el enlace isomórfico utiliza UTXO en las cadenas de CKB y Cardano como "contenedores" para expresar activos UTXO como RGB, agregando así programabilidad y escenarios más complejos. Anteriormente, Geek web3 había aparecido en " De BTC a Sui, ADA y Nervos: modelo UTXO y extensiones relacionadasDespués de resumir una serie de blockchains que admiten UTXO programable, este artículo explorará si estas blockchains pueden adaptarse al esquema de enlace isomórfico.

RGB++ y enlace isomórfico

Antes de analizar la compatibilidad de diferentes cadenas de UTXO con un enlace isomórfico, primero debemos introducir el principio del enlace isomórfico. El enlace isomórfico es un concepto propuesto por el equipo de CKB en el protocolo RGB++, por lo que aquí utilizamos el flujo de trabajo RGB++ para introducir qué es el enlace isomórfico basado en CKB.

Antes de presentar el protocolo RGB++, entendamos brevemente el protocolo RGB. RGB es un protocolo de activos/red P2P que se ejecuta bajo la cadena Bitcoin, un poco como la Lightning Network. Además, RGB también es un protocolo de activos parásitos basado en Bitcoin UTXO. El llamado parasitismo significa que el cliente RGB declarará bajo la cadena de Bitcoin a qué UTXO están vinculados ciertos activos RGB en la cadena de Bitcoin. Una vez que posea este UTXO, los activos RGB vinculados a él también estarán a su disposición.

Protocolos de activos como el protocolo RGB y ERC-20 operan de formas muy diferentes. El contrato ERC-20 en Ethereum registra el estado de activos de todos los usuarios, y el cliente de nodo de Ethereum sincronizará y verificará toda la información de transferencia, y registrará las actualizaciones de estado después de la transferencia en el contrato de activos. Esto ha sido conocido por la gente desde hace mucho tiempo, y no es más que depender del proceso de consenso de Ethereum para asegurar que los cambios de estado de los activos sean suaves. Dado que el consenso de los nodos de Ethereum es muy confiable, los usuarios pueden recurrir a la plataforma de custodia de activos basada en contratos ERC-20 como "sin problemas" incluso si no ejecutan el cliente.

Pero el protocolo RGB es muy extraño. Para mejorar la privacidad, simplemente elimina el consenso entre nodos/clientes, lo cual es algo convencional en el mundo de la cadena de bloques. Los usuarios tienen que ejecutar el cliente RGB ellos mismos y solo recibir y almacenar "datos de activos relacionados con ellos mismos". No pueden ver lo que han hecho los demás. A diferencia de Ethereum y ERC-20, en la cadena hay registros de transferencias visibles para todos.

En este caso, si alguien te transfiere algunos activos RGB, no sabes de antemano cómo se creó el dinero y de quién cambió de manos. Si la persona del otro lado declara un activo de la nada y luego te transfiere parte de él, ¿cómo afrontas este mal escenario de falsificación de moneda?

El protocolo RGB adopta esta idea: antes de que cada transferencia entre en vigor, el destinatario primero le pide al remitente que presente toda la historia del activo. Por ejemplo, desde la etapa de creación hasta el presente, quién emitió estos activos, quién los ha pasado, y si cada transferencia de activos que ocurre entre estas personas no viola las normas contables (una persona suma, otra persona resta).

De esta manera, puedes saber si el dinero que te dio la otra parte es "dinero cuestionable", por lo que la esencia de RGB es permitir que las partes de la transacción ejecuten el cliente para la verificación. Basado en el modo de verificación del cliente, correspondiente a la suposición del juego de la persona racional, siempre y cuando las partes involucradas sean racionales y el software del cliente esté bien, se puede garantizar que la transferencia de activos problemáticos no tendrá efecto o no será reconocida por otros.

Vale la pena señalar que el protocolo RGB comprimirá los datos de transacción bajo la cadena de Bitcoin en un Compromiso (esencialmente una raíz de Merkle) y los subirá a la cadena de Bitcoin. Esto permitirá que los registros de transferencia bajo la cadena se conecten directamente a la red principal de Bitcoin. Haz una conexión.

(Diagrama de flujo de interacción del protocolo RGB)

Dado que no hay consenso entre los clientes de RGB, la publicación del contrato de activos RGB no puede propagarse a todos los nodos de manera 'extremadamente confiable'. Los editores y usuarios de contratos simplemente conocen los detalles del contrato de activos RGB de forma espontánea a través de correo electrónico o Twitter, y la forma es muy informal.

La figura a continuación muestra un escenario de transferencia de activos RGB malintencionados. Como usuario de RGB, necesitamos almacenar el contrato inteligente correspondiente al activo RGB localmente en nuestro cliente. Cuando otros nos transfieren dinero, podemos saber si la transferencia actual viola las reglas definidas en el contrato basándonos en el contenido del contrato de activos almacenado localmente. Según la información de origen de los activos (registro histórico) proporcionada en el lado opuesto, puedes confirmar si hay algún problema con la fuente de los activos de la otra parte (si fue declarado de la nada).

Revisando el proceso anterior, no es difícil ver que los datos recibidos y almacenados por diferentes clientes RGB son frecuentemente independientes, y a menudo no sabes qué activos tienen otros y cuánto tienen. A su vez, otros básicamente no conocen el estado de tus activos.

Esta es una isla de datos típica, es decir, los datos almacenados por todos son inconsistentes. Aunque teóricamente puede mejorar la privacidad, también trae muchos problemas. Debes mantener los datos de activos RGB localmente en tu cliente. Una vez que estos datos se pierden, causará graves consecuencias (el activo no estará disponible). Pero de hecho, siempre y cuando mantengas bien los datos locales, el protocolo RGB puede brindarte seguridad que es básicamente equivalente a la red principal de Bitcoin.

Además, el protocolo Bifrost utilizado para la comunicación entre clientes RGB ayudará a los usuarios en la comunicación p2p con otros clientes. Pueden cifrar sus datos de activos y difundirlos a otros nodos, y pedirles que ayuden a almacenarlos. (Tenga en cuenta que estos son datos cifrados, la otra parte no conoce el texto plano). Siempre y cuando no pierda la clave, cuando se pierdan los datos locales, puede restaurar los datos de activos que originalmente poseía a través de otros nodos en la red.

Pero las deficiencias del protocolo RGB original siguen siendo evidentes. En primer lugar, cada transacción requiere múltiples comunicaciones entre las dos partes. La parte receptora debe verificar primero la fuente de los activos del remitente, y luego enviar un recibo para aprobar la solicitud de transferencia del remitente. Durante este proceso, al menos tres mensajes deben ser intercambiados entre las dos partes. Este tipo de 'transferencia interactiva' es claramente inconsistente con la 'transferencia no interactiva' a la que la mayoría de la gente está acostumbrada. ¿Puedes imaginar que cuando alguien quiera transferirte dinero, tenga que enviarte los datos de la transacción para verificar? ¿Pueden completar el proceso de transferencia solo después de recibir tu mensaje de recibo? (El diagrama de flujo se puede ver en el artículo anterior)

En segundo lugar, la gran mayoría de los escenarios de Defi requieren contratos inteligentes con datos transparentes y un estado verificable, pero el protocolo RGB no admite inherentemente tales escenarios, por lo que es muy hostil para Defi; además, en el protocolo RGB, los usuarios deben ejecutar el cliente para realizar sus propias tareas de verificación. Si accidentalmente recibes un activo que ha cambiado de manos entre decenas de miles de personas, incluso tendrás que verificar las decenas de miles de veces que el activo ha cambiado de manos. Obviamente, permitir que los usuarios resuelvan todo por sí mismos no es propicio para la promoción y la adopción del producto en sí mismo.

En cuanto a los problemas anteriores, la solución de RGB++ es permitir a los usuarios cambiar libremente entre el modo de autoverificación del cliente y el modo de alojamiento de terceros. Los usuarios pueden dejar la carga de verificación y almacenamiento de datos, alojamiento de contratos inteligentes, etc. a CKB. Por supuesto, los usuarios deben ser optimistas y confiar en que CKB, la cadena pública de POW, es fiable; si algunas personas tienen un mayor deseo de seguridad y privacidad, por ejemplo, grandes inversores con grandes cantidades de activos también pueden retroceder al modo RGB original. Lo que se debe enfatizar aquí es que RGB++ y el protocolo RGB original son teóricamente compatibles entre sí.

(Diagrama de flujo de interacción del protocolo RGB++ [versión corta])

en artículos anteriores“De RGB a RGB++: Cómo CKB potencia el protocolo de activos ecológicos de Bitcoin”, hemos popularizado brevemente el 'enlace isomórfico' de RGB++. Aquí haremos una revisión rápida:

CKB tiene su propio UTXO extendido llamado Cell, que es más programable que el UTXO en la cadena BTC. El "enlace isomórfico" es usar el Cell en la cadena CKB como un "contenedor" para los datos de activos RGB, y escribir los parámetros clave del activo RGB en el Cell.

Dado que hay una relación de vinculación entre los activos RGB y Bitcoin UTXO, la forma lógica del activo tiene las características de UTXO. y Cell, que también tiene características de UTXO, es naturalmente adecuado como un “contenedor” para los activos RGB. Cada vez que ocurre una transacción de activos RGB, el contenedor de Celda correspondiente también puede mostrar características similares, al igual que la relación entre entidades y sombras. Esta es la esencia de la “vinculación isomórfica”.

Por ejemplo, si Alice posee 100 tokens RGB y UTXO A en la cadena de Bitcoin, y tiene una Celda en la cadena de CKB, esta Celda está marcada con “Saldo de Tokens RGB: 100”, y las condiciones de desbloqueo están relacionadas con UTXO A.

Si Alicia quiere enviar 30 tokens a Bob, primero puede generar un Compromiso. La declaración correspondiente es: transferir 30 de los tokens RGB asociados con UTXO A a Bob, y transferir 70 a otros UTXOs que ella controla.

Posteriormente, Alice gasta UTXO A en la cadena de Bitcoin, publica la declaración anterior y luego inicia una transacción en la cadena CKB para consumir el contenedor de celdas que lleva 100 tokens RGB y generar dos nuevos contenedores, uno que contiene 30 tokens (para Bob), y otro que contiene 70 tokens (controlado por Alice). En este proceso, la tarea de verificar la validez de los activos de Alice y la validez de la declaración de transacción es completada por los nodos de la red CKB a través de consenso, sin intervención de Bob. CKB ahora actúa como una capa de verificación y una capa DA bajo la cadena de Bitcoin.

Esto es similar al hecho de que cada vez que cambia el estado del contrato Ethereum ERC-20, el usuario no necesita ejecutar la verificación del cliente. El principio es similar. El protocolo de consenso y la red de nodos reemplazan la verificación del cliente. Además, los datos de activos RGB de todos están almacenados en la cadena CKB, que es globalmente verificable, lo cual es propicio para la implementación de escenarios de Defi, como piscinas de liquidez y protocolos de garantía de activos.

Esto realmente introduce una suposición de confianza importante:Los usuarios tienden a ser optimistas de que la cadena CKB, o la plataforma de red compuesta por un gran número de nodos que dependen de protocolos de consenso, es confiable y libre de errores. Si no confías en CKB, también puedes seguir el proceso de comunicación e interacción y verificación en el protocolo RGB original y ejecutar el cliente tú mismo.

Por supuesto, si alguien quiere ejecutar el cliente RGB++ por sí mismo y verificar la fuente histórica de los activos de otras personas, puede verificar directamente la historia relacionada con el contenedor de activos RGB Cell en la cadena CKB. Si ejecutas un nodo ligero de CKB y recibes Merkle Proof y encabezados de bloque CKB, puedes estar seguro de que los datos históricos que recibes no han sido manipulados por atacantes maliciosos en la red. Se puede decir que CKB actúa como una capa de almacenamiento de datos históricos aquí.

simplemente, el enlace isomórfico no solo es aplicable a RGB, sino también a varios protocolos de activos con características UTXO como Runes y Atomic., transfiere todo el estado de activos, datos históricos y contratos inteligentes correspondientes almacenados localmente en el cliente del usuario a cadenas públicas UTXO como CKB o Cardano para almacenamiento y alojamiento. El protocolo de activos UTXO mencionado anteriormente puede utilizar el modelo UTXO de CKB o Cardano como un "contenedor" para mostrar la forma y el estado del activo. Es conveniente cooperar con escenarios como contratos inteligentes.

Bajo el protocolo de enlace isomórfico, los usuarios pueden usar directamente sus cuentas de Bitcoin para operar sus contenedores de activos RGB en cadenas UTXO como CKB sin cruzar la cadena. Solo necesitas usar la característica UTXO de Cell para establecer las condiciones de desbloqueo del contenedor de Cell para que esté asociado con cierta dirección de Bitcoin/UTXO de Bitcoin. Dado que ya hemos explicado las características de Cell en el artículo de divulgación científica RGB++ anterior de Geekweb3, no entraremos en detalles aquí.

Si ambas partes involucradas en transacciones de activos RGB pueden confiar en la seguridad de CKB, ni siquiera necesitarán emitir Compromisos con frecuencia en la cadena de Bitcoin. Después de que se realicen muchas transferencias de RGB, se puede enviar un Compromiso a la cadena de Bitcoin. Esto se llama la función de 'transacción plegable'. Puede reducir los costos de uso.

Sin embargo, cabe destacar que el “contenedor” utilizado en la vinculación isomórfica a menudo requiere una cadena pública que admita el modelo UTXO, o una infraestructura con características similares en el almacenamiento de estado, y la cadena EVM claramente no es adecuada, y habrá problemas de implementación técnica. Se encuentran muchos obstáculos. En primer lugar, como se mencionó anteriormente, RGB++ “puede operar contenedores de activos en la cadena CKB sin necesidad de intercambios cruzados”, lo cual es básicamente imposible de implementar en la cadena EVM; incluso si se implementa de forma forzada, el costo puede ser muy alto;

Además, en el protocolo RGB++, muchas personas no necesitan ejecutar el cliente ni almacenar datos de activos localmente. Si se utiliza el método ERC-20 para registrar el saldo de activos de todos en este contrato, si alguien quiere volver al modo de autoverificación del cliente y propone verificar la fuente de los activos de alguien, en este momento puede tener que escanear todos los registros de transacciones que interactúan con contratos de activos, lo que generará una gran presión.

Hablando claramente, los contratos de activos como ERC-20 acoplan y almacenan el estado de los activos de todos. Si deseas verificar individualmente el historial de cambio de activos de uno de ellos, se volverá difícil. Al igual que en una sala de chat pública, si deseas saber quién ha enviado mensajes a Wang Gang, debes revisar los registros de mensajes en toda la sala de chat. UTXO es como un canal de chat privado uno a uno, y es fácil verificar el historial.

En resumen, una cadena pública/capa de expansión de funciones adecuada para realizar un enlace isomórfico debería tener las siguientes características:

1. Utilice el modelo UTXO o un esquema de almacenamiento de estado similar;
2. Tiene una considerable programabilidad de UTXO, lo que permite a los desarrolladores escribir scripts de desbloqueo;
3. Hay un espacio de estado relacionado con UTXO que puede almacenar el estado de los activos;
4. Hay puentes o nodos ligeros relacionados con Bitcoin;

Por supuesto, también esperamos que la cadena pública utilizada para el enlace isomórfico tenga una seguridad sólida. Por otro lado, también esperamos que las condiciones de desbloqueo de UTXO en la cadena pública sean programables, para que los usuarios puedan usar directamente el esquema de firma de BTC para desbloquear su UTXO de forma isomórfica en otras cadenas públicas sin cambiar el algoritmo de firma.

Actualmente, el script de bloqueo UTXO en CKB es programable, y el oficial también es compatible con los esquemas de firma de diferentes cadenas públicas. Para el enlace isomórfico, la red de CKB básicamente cumple con las características mencionadas anteriormente. ¿Qué pasa con otras cadenas públicas basadas en UTXO? Hemos realizado una inspección preliminar de Fuel y Cardano y creemos que teóricamente pueden soportar el enlace isomórfico.

Combustible: Ethereum OP Rollup basado en UTXO

Fuel es un Ethereum OP Rollup basado en UTXO, y es un pionero en introducir el concepto de prueba de fraude en el ecosistema de capa 2 de Ethereum. Para el soporte de función UTXO normal, Fuel es básicamente consistente con BTC.

Fuel divide su UTXO interno en las siguientes tres categorías:

Moneda de entrada: UTXO estándar, utilizado para representar los activos de los usuarios, tiene un bloqueo de tiempo nativo y permite a los usuarios escribir predicados de script de desbloqueo;

Contrato de entrada: Los UTXO utilizados para las llamadas de contrato contienen datos como la raíz del estado del contrato y los activos del contrato;

Mensaje de entrada: UTXO utilizado para transmitir información principalmente contiene campos como el destinatario de la información;

Cuando un usuario gasta un UTXO, se produce la siguiente salida:

Salida de moneda: Para transferencias de activos estándar;

Contrato de salida: La salida generada por la interacción del contrato internamente contiene la raíz del estado después de la interacción del contrato;

Contrato de salida creado: Un UTXO especial es la salida generada al crear un contrato, que contiene el ID y la raíz del estado del contrato;

A diferencia de la Celda de CKB, que contiene todos los estados del contrato internamente, el UTXO de Fuel en realidad no lleva todos los estados del contrato relacionados con la transacción. Fuel solo lleva la raíz del estado del contrato Stateroot en UTXO, que es la raíz del árbol de estados. El estado completo del contrato se almacena dentro de la biblioteca de estados de Fuel y es propiedad del contrato inteligente.

Vale la pena mencionar que, en lo que respecta al procesamiento del estado de contratos inteligentes, el contrato Fuel y el contrato de solidez son ideológicamente consistentes e incluso relativamente cercanos en forma de programación. La figura a continuación muestra un contrato de contador escrito en el lenguaje Sway de Fuel. El contrato contiene un contador. Cuando el usuario llama a la función increment_counter, el contador almacenado en el contrato se incrementa en 1.

Podemos ver que la lógica de escritura del contrato Sway es similar a la de un contrato general de Solidity. Primero damos el ABI del contrato, luego las variables de estado del contrato, y luego la implementación específica del contrato. Todos los procesos de escritura de código no involucran el sistema UTXO de Fuel.

Por lo tanto, la experiencia de programación de contratos de Fuel es diferente de los lenguajes de programación UTXO como CKB y Cardano. Fuel proporciona una experiencia más cercana a la programación y desarrollo de contratos inteligentes EVM. Los desarrolladores también pueden usar el lenguaje Sway para construir scripts de desbloqueo para implementar lógica de verificación de algoritmo de firma especial o lógica de desbloqueo de firma múltiple compleja.

Básicamente es factible implementar el enlace isomórfico dentro de Fuel, pero aún existen los siguientes problemas:

El lenguaje de oscilación utilizado por Fuel es más cercano a la cadena EVM en cuanto al diseño de contratos inteligentes que a BTC o CKB y Cardano. Los emisores de activos UTXO como RGB y Atomics necesitan construir específicamente un contrato inteligente en Fuel. CKB y otras cadenas utilizan otro, que es bastante complicado.

Cardano: cadena pública eUTXO basada en POS

Cardano es otra cadena de bloques que utiliza el modelo UTXO, pero a diferencia de Fuel, es una cadena pública de Capa 1. Cardano utiliza eUTXO (UTXO extendido) para referirse al modelo de programación UTXO en su sistema. En comparación con CKB, eUTXO en Cardano contiene las siguientes estructuras:

Script: Los contratos inteligentes se utilizan para verificar si se puede desbloquear UTXO y realizar transiciones de estado;

Redeemers: Los datos proporcionados por los usuarios para desbloquear UTXO son generalmente datos de firma, similares a los Testigos de Bitcoin;

Datos: El espacio de estado de los contratos inteligentes puede almacenar datos como el estado de los activos;

Contexto de la transacción: Datos contextuales para las transacciones UTXO, como parámetros de entrada y resultados de la transacción (El proceso de cálculo de la transacción de la cadena UTXO se realiza directamente fuera de la cadena, y los resultados del cálculo se envían a la cadena para su verificación. Si pasan la verificación, los resultados de la transacción se cargan en la cadena)

Los desarrolladores pueden usar el lenguaje PlutusCore para programar UTXO en la cadena Cardano. Similar a CKB, los desarrolladores pueden escribir scripts de desbloqueo y algunas funciones para actualizaciones de estado.

Presentamos el modelo de programación UTXO de Cardano con un proceso de subasta basado en UTXO. Supongamos que necesitamos implementar una DAPP de subasta de activos que requiere que los usuarios den ofertas antes de que termine la subasta. Específicamente, el usuario consume su propio UTXO, contratos UTXO con esta subasta y luego genera un nuevo UTXO. Cuando alguien hace una oferta más alta, además de generar un nuevo UTXO de contrato de subasta, también se generará un UTXO de reembolso para la persona anterior. El proceso específico es el siguiente:

Para implementar el proceso de subasta anterior, algunos estados deben almacenarse en el UTXO del contrato inteligente de subasta, como el precio más alto de la subasta actual y la persona que realizó la oferta. La figura a continuación muestra la declaración de estado dentro de PlutusCore. Podemos ver que bBidder y bAmount muestran la oferta de subasta y la dirección de billetera que realizó la oferta. Los parámetros de la subasta contienen la información básica de la subasta.

Cuando un usuario gasta este UTXO, podemos actualizar el estado dentro del contrato. La figura a continuación muestra algunas actualizaciones de estado específicas y lógica empresarial dentro del contrato de subasta. Por ejemplo, la lógica de verificar las ofertas de los usuarios y verificar si la subasta actual todavía está en progreso. Dado que PlutusCore es un lenguaje de programación Haskell, que es un lenguaje de programación puramente funcional, es probable que la mayoría de los desarrolladores no puedan entender directamente su significado.

Es factible construir enlaces isomorfos en Cardano, podemos usar Datum para almacenar el estado de los activos y escribir scripts específicos para ser compatibles con algoritmos de firma relacionados con Bitcoin. Pero el problema grave es que la mayoría de los programadores pueden no ser capaces de adaptarse al uso de PlutusCore para la programación de contratos. Además, su entorno de programación es difícil de configurar y no es amigable para los desarrolladores.

Resumir

La vinculación isomórfica requiere que la cadena tenga las siguientes propiedades:

1. Utilice el modelo UTXO
2. Tiene una considerable programabilidad UTXO, lo que permite a los desarrolladores escribir scripts de desbloqueo
3. Hay un espacio de estado relacionado con UTXO que puede almacenar el estado de los activos
4. Puede admitir la ejecución de nodos ligeros de Bitcoin a través de contratos inteligentes u otros medios.

Debido a la particularidad de sus ideas de programación de contratos inteligentes, Fuel es compatible con la vinculación isomórfica, pero todavía conlleva algunas cargas; mientras que Cardano utiliza el lenguaje de programación Haskell para la programación de contratos, lo que dificulta que la mayoría de los desarrolladores comiencen rápidamente. Con base en las razones anteriores, CKB, que adopta el conjunto de instrucciones RISC-V y es más equilibrado en las características de la programación UTXO, puede ser una capa de expansión de funciones más adecuada para la vinculación isomórfica.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [极客 Web3].Reenviar el título original 'RGB++与同构绑定：CKB、Cardano与Fuel如何赋能比特币生态’. Todos los derechos de autor pertenecen al autor original [Shew]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y ellos lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.