Transférer le titre original 'RGB++与同构绑定：CKB、Cardano与Fuel如何赋能比特币生态'

Résumé: Le protocole d'actif RGB++ proposé par l'équipe CKB La proposition L'essence de l'idée de "liaison isomorphique" est d'utiliser CKB, Cardano, Fuel et d'autres blockchains basées sur le modèle de programmation UTXO comme couche d'extension fonctionnelle qui transporte des "conteneurs" d'actifs RGB. Cette liaison isomorphique s'applique également aux protocoles d'actifs écologiques Bitcoin avec des caractéristiques UTXO telles qu'Atomical et Runes, facilitant la création d'une couche de contrat intelligent hors chaîne pour Bitcoin.

· Dans le protocole RGB ++, les utilisateurs n'ont pas à exécuter le client pour vérifier personnellement les données de transaction, et peuvent confier des tâches telles que la vérification de la validité des actifs et le stockage des données à des chaînes UTXO telles que CKB et Cardanao. Tant que vous êtes "optimiste" et que vous croyez que la sécurité des chaînes publiques ci-dessus est relativement fiable, il n'est pas nécessaire de le vérifier vous-même;

· Le protocole RGB++ prend en charge les utilisateurs pour passer en mode de vérification client. À ce moment, vous pouvez toujours utiliser CKB comme couche de stockage de données/DA sans avoir à conserver les données vous-même. Le protocole RGB++ ne nécessite pas d'actifs inter-chaînes et peut gérer les actifs sur la chaîne CKB via des comptes Bitcoin. Il peut réduire la fréquence d'émission des engagements à la chaîne Bitcoin, ce qui est également propice à la prise en charge des scénarios Defi;

· S'il s'agit du système de contrat EVM, de nombreuses fonctionnalités de RGB++ ne sont pas faciles à prendre en charge. Dans l'ensemble, une couche d'extension de chaîne publique/fonction adaptée à la réalisation de la liaison isomorphique doit présenter les caractéristiques suivantes :

1. Utilisez le modèle UTXO ou un schéma de stockage d'état similaire;

2. Dispose d'une programmabilité UTXO considérable, permettant aux développeurs d'écrire des scripts de déverrouillage;

3. Il existe un espace d'état lié à UTXO qui peut stocker l'état des actifs;

4. Il peut prendre en charge le fonctionnement des nœuds légers Bitcoin via des contrats intelligents ou d'autres moyens;

· En plus de CKB, Cardano et Fuel peuvent également prendre en charge la liaison isomorphique. Cependant, ces deux derniers peuvent présenter des inconvénients en termes de langage de contrat intelligent et de détails de conception de contrat. Pour l'instant, il semble que CKB soit plus adapté que ces deux derniers en tant que couche d'extension de fonction pour les protocoles d'actifs Bitcoin liés de manière isomorphique.

Dans le LightPaper du protocole existRGB++ en 2017, Cipher, co-fondateur de Nervos CKB, a proposé pour la première fois l'idée de produit de liaison isomorphique. Par rapport à d'autres solutions de couche 2 Bitcoin, la liaison isomorphique peut être mieux compatible avec des protocoles d'actifs tels que RGB, Runes et Atomical, et peut éviter des facteurs tels que les actifs inter-chaînes qui entraînent des charges de sécurité supplémentaires.

Pour le dire simplement, la liaison isomorphe utilise UTXO sur les chaînes CKB et Cardano comme "conteneurs" pour exprimer des actifs UTXO tels que RGB, ajoutant ainsi une programmabilité et des scénarios plus complexes. Auparavant, Geek web3 était apparu dans "Du BTC au Sui, en passant par l’ADA et le Nervos : le modèle UTXO et les extensions associéesAyant résumé une série de blockchains qui prennent en charge UTXO programmable, cet article explorera plus avant si ces blockchains peuvent s'adapter au schéma de liaison isomorphique.

Liaison RVB++ et isomorphe

Avant d'analyser la compatibilité des différentes chaînes UTXO avec la liaison isomorphique, nous devons d'abord introduire le principe de la liaison isomorphique. La liaison isomorphique est un concept proposé par l'équipe CKB dans le protocole RGB++, nous utilisons donc le flux de travail RGB++ pour introduire ce qu'est la liaison isomorphique basée sur CKB.

Avant d'introduire le protocole RGB++, comprenons brièvement le protocole RGB. RGB est un protocole d'actif/réseau P2P fonctionnant sous la chaîne Bitcoin, un peu comme le Lightning Network. De plus, RGB est également un protocole d'actif parasitaire basé sur les UTXO de Bitcoin. Le soi-disant parasitisme signifie que le client RGB déclare sous la chaîne Bitcoin à quel UTXO certains actifs RGB sont liés sur la chaîne Bitcoin. Une fois que vous possédez cet UTXO, les actifs RGB qui y sont liés sont également à votre disposition.

Les protocoles d'actifs tels que le protocole RGB et ERC-20 fonctionnent de manières très différentes. Le contrat ERC-20 sur Ethereum enregistre l'état des actifs de tous les utilisateurs, et le client de nœud Ethereum synchronisera et vérifiera toutes les informations de transfert, et enregistrera les mises à jour d'état après le transfert dans le contrat d'actif. Cela est en fait connu des gens depuis longtemps, et cela ne fait que s'appuyer sur le processus de consensus d'Ethereum pour garantir que les changements d'état des actifs se déroulent en douceur. Étant donné que le consensus des nœuds Ethereum est très fiable, les utilisateurs peuvent considérer par défaut la plateforme de garde d'actifs basée sur les contrats ERC-20 comme étant sans problème même s'ils n'exécutent pas le client.

Le protocole RGB est très étrange. Afin d'améliorer la confidentialité, il supprime simplement le consensus du nœud/client, ce qui est une chose conventionnelle dans le monde de la blockchain. Les utilisateurs doivent exécuter eux-mêmes le client RGB et ne recevoir et stocker que les 'données d'actifs les concernant'. Ils ne peuvent pas voir ce que les autres ont fait. Contrairement à Ethereum et ERC-20, il n'y a pas de registres de transfert visibles sur la chaîne.

Dans ce cas, si quelqu'un vous transfère des actifs RGB, vous ne savez pas à l'avance comment l'argent a été créé et de qui il a changé de mains. Si la personne de l'autre côté déclare un actif à partir de rien, puis en transfère une partie à vous, comment gérez-vous ce scénario malveillant de contrefaçon monétaire ?

Le protocole RGB adopte cette idée : avant que chaque transfert ne prenne effet, le destinataire demande d'abord à l'expéditeur de présenter l'intégralité de l'historique de l'actif. Par exemple, de la phase de création à aujourd'hui, qui a émis ces actifs, qui les a traversés, et si chaque transfert d'actifs qui a lieu entre ces personnes ne viole pas les normes comptables (une personne ajoute, une personne soustrait).

De cette façon, vous pouvez savoir si l'argent qui vous est donné par l'autre partie est de l'argent “questionnable”, donc l'essence de RGB est de permettre aux parties à la transaction d'exécuter le client pour vérification. En fonction du mode de vérification du client, en correspondance avec l'hypothèse du jeu de la personne rationnelle, tant que les parties impliquées sont rationnelles et que le logiciel client est OK, il peut être garanti que le transfert d'actifs problématiques ne prendra pas effet ou ne sera pas reconnu par d'autres.

Il convient de noter que le protocole RGB compressera les données de transaction sous la chaîne Bitcoin en un engagement (essentiellement une racine de Merkle) et les téléchargera sur la chaîne Bitcoin. Cela permettra de relier directement les enregistrements de transfert sous la chaîne au réseau principal de Bitcoin. Faire une connexion.

(Organigramme d’interaction du protocole RVB)

Comme il n'y a pas de consensus parmi les clients RGB, la publication du contrat d'actif RGB ne peut pas être propagée à tous les nœuds de manière “extrêmement fiable”. Les éditeurs de contrats et les utilisateurs apprennent simplement les détails du contrat d'actif RGB de manière spontanée via e-mail ou Twitter, et la forme est très informelle.

La figure ci-dessous montre un scénario malveillant de transfert de ressources RVB. En tant qu’utilisateur RVB, nous devons stocker le contrat intelligent correspondant à l’actif RVB localement sur notre client. Lorsque d’autres personnes nous transfèrent de l’argent, nous pouvons savoir si le transfert en cours enfreint les règles définies dans le contrat en fonction du contenu du contrat d’actif stocké localement. Selon les informations sur la source des actifs (enregistrement historique) fournies sur le côté opposé, vous pouvez confirmer s’il y a un problème avec la source des actifs de l’autre partie (s’il a été déclaré à partir de rien).

En examinant le processus ci-dessus, il n'est pas difficile de voir que les données reçues et stockées par différents clients RGB sont souvent indépendantes, et vous ne savez souvent pas quels actifs les autres possèdent et combien ils en ont. À leur tour, les autres ne connaissent essentiellement pas l'état de vos actifs.

Il s'agit d'une île de données typique, c'est-à-dire que les données stockées par chacun sont incohérentes. Bien qu'elle puisse théoriquement améliorer la confidentialité, elle apporte également beaucoup de problèmes. Vous devez conserver les données d'actifs RGB localement sur votre client. Une fois que ces données sont perdues, cela entraînera de graves conséquences (l'actif ne sera pas disponible). Mais en réalité, tant que vous maintenez bien les données locales, le protocole RGB peut vous apporter une sécurité essentiellement équivalente à celle du réseau principal Bitcoin.

De plus, le protocole Bifrost utilisé pour la communication entre les clients RGB aidera les utilisateurs dans la communication de pair à pair avec d'autres clients. Ils peuvent crypter leurs données d'actifs et les diffuser à d'autres nœuds, et leur demander de les aider à les stocker. (Notez qu'il s'agit de données cryptées, l'autre partie ne connaît pas le texte en clair). Tant que vous ne perdez pas la clé, lorsque les données locales sont perdues, vous pouvez restaurer les données d'actifs que vous possédiez initialement grâce à d'autres nœuds dans le réseau.

Mais les lacunes du protocole RGB original restent évidentes. Tout d'abord, chaque transaction nécessite de multiples communications entre les deux parties. La partie réceptrice doit d'abord vérifier la source des actifs de l'expéditeur, puis envoyer un reçu pour approuver la demande de transfert de l'expéditeur. Pendant ce processus, au moins trois messages doivent être échangés entre les deux parties. Ce genre de "transfert interactif" est en contradiction sérieuse avec le "transfert non interactif" auquel la plupart des gens sont habitués. Pouvez-vous imaginer que lorsque quelqu'un veut vous transférer de l'argent, il doit vous envoyer les données de transaction pour vérification. Peuvent-ils compléter le processus de transfert uniquement après avoir reçu votre message de réception? (Le diagramme de flux peut être vu dans l'article précédent)

Deuxièmement, la grande majorité des scénarios Defi nécessitent des contrats intelligents avec des données transparentes et un statut vérifiable, mais le protocole RGB ne prend pas en charge de manière inhérente de tels scénarios, il est donc très peu convivial pour Defi ; de plus, dans le protocole RGB, les utilisateurs doivent exécuter le client pour effectuer leurs propres tâches de vérification. Si vous recevez accidentellement un actif qui a changé de mains entre des dizaines de milliers de personnes, vous devrez même vérifier les dizaines de milliers de fois où l'actif a changé de mains. De toute évidence, laisser les utilisateurs tout résoudre par eux-mêmes n'est pas propice à la promotion et à l'adoption du produit lui-même.

En ce qui concerne les problèmes ci-dessus, la solution de RGB++ consiste à permettre aux utilisateurs de passer librement du mode de vérification client auto-attesté au mode d'hébergement tiers. Les utilisateurs peuvent laisser le fardeau de la vérification et du stockage des données, de l'hébergement de contrats intelligents, etc. à CKB. Bien sûr, les utilisateurs doivent être optimistes et faire confiance à CKB, la chaîne publique POW, pour être fiables ; si certaines personnes ont des exigences plus élevées en matière de sécurité et de confidentialité, par exemple, de gros investisseurs avec des montants importants d'actifs peuvent également revenir au mode RGB original. Ce qui doit être souligné ici, c'est que RGB++ et le protocole RGB original sont théoriquement compatibles entre eux.

(Diagramme de flux d'interaction du protocole RGB++ [version courte])

dans les articles précédents"De RGB à RGB++ : Comment CKB renforce le protocole d'actifs écologiques Bitcoin", nous avons brièvement popularisé la « liaison isomorphe » de RGB++. Ici, nous allons rapidement passer en revue :

CKB a son propre UTXO étendu appelé Cell, qui est plus programmable que l'UTXO sur la chaîne BTC. Le “liaison isomorphe” consiste à utiliser le Cell sur la chaîne CKB comme un “conteneur” pour les données d'actifs RGB, et écrire les paramètres clés de l'actif RGB dans le Cell.

Étant donné qu'il existe une relation contraignante entre les actifs RGB et Bitcoin UTXO, la forme logique de l'actif présente les caractéristiques de UTXO. etCell, qui a également des caractéristiques de UTXO, est naturellement adapté en tant que “conteneur” pour les actifs RGB. Chaque fois qu'une transaction d'actifs RGB a lieu, le conteneur Cell correspondant peut également présenter des caractéristiques similaires, tout comme la relation entre les entités et les ombres. C'est l'essence de la “liaison isomorphe”.

Par exemple, si Alice possède 100 jetons RVB et UTXO A sur la chaîne Bitcoin, et qu’elle possède une cellule sur la chaîne CKB, cette cellule est marquée avec « Solde de jetons RVB : 100 », et les conditions de déblocage sont liées à UTXO A.

Si Alice veut envoyer 30 jetons à Bob, elle peut d'abord générer un Engagement. L'énoncé correspondant est le suivant : transférer 30 des jetons RGB associés à l'UTXO A à Bob, et transférer 70 à d'autres UTXO qu'elle contrôle.

Par la suite, Alice dépense UTXO A sur la chaîne Bitcoin, publie la déclaration ci-dessus, puis lance une transaction sur la chaîne CKB pour consommer le conteneur Cell transportant 100 jetons RGB et générer deux nouveaux conteneurs, l'un contenant 30 jetons (à Bob), l'autre contenant 70 jetons (contrôlés par Alice). Dans ce processus, la tâche de vérification de la validité des actifs d'Alice et de la déclaration de transaction est réalisée par les nœuds du réseau CKB par consensus, sans l'intervention de Bob. CKB agit désormais comme une couche de vérification et une couche DA sous la chaîne Bitcoin.

Cela ressemble au fait qu'à chaque fois que l'état du contrat Ethereum ERC-20 change, l'utilisateur n'a pas besoin d'exécuter la vérification du client. Le principe est similaire. Le protocole de consensus et le réseau de nœuds remplacent la vérification du client. De plus, les données d'actifs RGB de chacun sont stockées sur la chaîne CKB, ce qui est vérifiable mondialement, ce qui est propice à la mise en œuvre de scénarios Defi, tels que les pools de liquidités et les protocoles de mise en gage d'actifs.

Cela introduit en fait une hypothèse de confiance importante : les utilisateurs ont tendance à être optimistes quant à la fiabilité et à l'absence d'erreurs de la chaîne CKB, ou de la plateforme réseau composée d'un grand nombre de nœuds reposant sur des protocoles de consensus. Si vous ne faites pas confiance à CKB, vous pouvez également suivre le processus de communication et de vérification interactif dans le protocole RGB d'origine et exécuter le client vous-même.

Bien sûr, si quelqu'un souhaite exécuter lui-même le client RGB++ et vérifier la source historique des actifs d'autres personnes, il peut vérifier directement l'histoire liée au conteneur d'actifs RGB Cell sur la chaîne CKB. Tant que vous exécutez un nœud léger CKB et recevez une preuve de Merkle et des en-têtes de blocs CKB, vous pouvez être sûr que les données historiques que vous recevez n'ont pas été altérées par des attaquants malveillants dans le réseau. On peut dire que CKB agit comme une couche de stockage de données historiques ici.

En termes simples, la liaison isomorphe n'est pas seulement applicable au RGB, mais aussi à divers protocoles d'actifs avec des caractéristiques UTXO telles que Runes et Atomic., il transfère tous les états d'actifs, les données historiques et les contrats intelligents correspondants stockés localement sur le client utilisateur vers des chaînes publiques UTXO telles que CKB ou Cardano pour le stockage et l'hébergement. Le protocole d'actifs UTXO susmentionné peut utiliser le modèle UTXO de CKB ou Cardano comme un "conteneur" pour afficher la forme et l'état de l'actif. Il est pratique de coopérer avec des scénarios tels que des contrats intelligents.

Sous le protocole de liaison isomorphe, les utilisateurs peuvent directement utiliser leurs comptes Bitcoin pour faire fonctionner leurs conteneurs d'actifs RGB sur des chaînes UTXO telles que CKB sans traverser la chaîne. Vous devez simplement utiliser la fonction UTXO de Cell pour définir les conditions de déverrouillage du conteneur de Cellule à associer à une certaine adresse Bitcoin/UTXO Bitcoin. Comme nous avons déjà expliqué les caractéristiques de Cell dans un précédent article de vulgarisation RGB++ de Geekweb3, nous n'entrerons pas dans les détails ici.

Si les deux parties impliquées dans les transactions d'actifs RGB peuvent faire confiance à la sécurité de CKB, elles n'auront même pas besoin d'émettre fréquemment des Engagements sur la chaîne Bitcoin.Après de nombreuses transferts RGB sont effectués, un Engagement peut être envoyé à la chaîne Bitcoin. Cela s'appelle la fonction de "pliage de transaction".Peut réduire les coûts d'utilisation.

Cependant, il convient de noter que le "conteneur" utilisé dans la liaison isomorphe nécessite souvent une chaîne publique prenant en charge le modèle UTXO, ou une infrastructure aux caractéristiques similaires en matière de stockage d'état, et la chaîne EVM n'est évidemment pas adaptée, et il y aura des problèmes d'implémentation technique. Rencontré de nombreux pièges.Tout d'abord, comme mentionné précédemment, RGB++ "peut exploiter des conteneurs d'actifs sur la chaîne CKB sans chaîne transversale", ce qui est pratiquement impossible à mettre en œuvre sur la chaîne EVM ; même s'il est mis en œuvre de force, le coût peut être très élevé ;

De plus, dans le protocole RGB++, de nombreuses personnes n'ont pas besoin d'exécuter le client ou de stocker localement les données d'actifs. Si la méthode ERC-20 est utilisée pour enregistrer le solde des actifs de chacun dans ce contrat, si quelqu'un veut revenir au mode de vérification par soi-même du client et propose de vérifier la source des actifs de quelqu'un, à ce moment-là, il devra peut-être scanner tous les enregistrements de transactions qui interagissent avec les contrats d'actifs, ce qui entraînera une énorme pression.

Pour être franc, les contrats d'actifs tels que ERC-20 couplent et stockent le statut des actifs de tout le monde. Si vous souhaitez vérifier individuellement l'historique des modifications d'actifs de l'un d'eux, cela deviendra difficile. Tout comme dans une salle de discussion publique, si vous voulez savoir qui a envoyé des messages à Wang Gang, vous devez parcourir les enregistrements de messages dans toute la salle de discussion. UTXO est comme un canal de discussion privé en tête-à-tête, et il est facile de vérifier l'historique.

En résumé, une chaîne publique/couche d'expansion de fonction adaptée à la réalisation de liaisons isomorphes devrait avoir les caractéristiques suivantes :

1. Utilisez le modèle UTXO ou un schéma de stockage d'état similaire;
2. Possède une programmabilité UTXO considérable, permettant aux développeurs d'écrire des scripts de déverrouillage;
3. Il existe un espace d'état lié à UTXO qui peut stocker l'état des actifs;
4. Il existe des ponts ou des nœuds légers liés à Bitcoin;

Bien sûr, nous espérons également que la chaîne publique utilisée pour la liaison isomorphique soit dotée d'une sécurité renforcée. D'autre part, nous espérons également que les conditions de déverrouillage UTXO sur la chaîne publique soient programmables, de sorte que les utilisateurs puissent utiliser directement le schéma de signature BTC pour déverrouiller leur UTXO lié isomorphiquement sur d'autres chaînes publiques sans modifier l'algorithme de signature.

Actuellement, le script de verrouillage UTXO sur CKB est programmable, et l'officiel est également compatible avec les schémas de signature de différentes chaînes publiques. Pour une liaison isomorphe, le réseau CKB répond pratiquement aux caractéristiques ci-dessus. Et les autres chaînes publiques basées sur UTXO ? Nous avons effectué une inspection préliminaire de Fuel et de Cardano et estimons qu'elles peuvent théoriquement prendre en charge une liaison isomorphe.

Carburant : Ethereum OP Rollup basé sur UTXO

Fuel est un Ethereum OP Rollup basé sur UTXO, et est un pionnier dans l'introduction du concept de preuve de fraude dans l'écosystème Ethereum Layer 2. Pour le support de la fonction UTXO normal, Fuel est fondamentalement conforme à BTC.

Fuel divise ses UTXO internes en trois catégories suivantes :

Pièce d'entrée : UTXO standard, utilisée pour représenter les actifs des utilisateurs, dispose d'un verrouillage temporel natif et permet aux utilisateurs d'écrire des prédicats de script de déverrouillage ;

Contrat d'entrée：Les UTXO utilisés pour les appels de contrat contiennent des données telles que la racine d'état du contrat et les actifs du contrat;

Message d'entrée: UTXO utilisé pour transmettre des informations contient principalement des champs tels que le destinataire des informations;

Lorsqu'un utilisateur dépense un UTXO, la sortie suivante est produite:

Jeton de sortie：Pour les transferts d'actifs standard;

Contrat de sortie : La sortie générée par l'interaction du contrat contient internalement la racine d'état après l'interaction du contrat;

Contrat de sortie créé : Un UTXO spécial est la sortie générée lors de la création d’un contrat, qui contient l’ID et la racine d’état du contrat ;

Contrairement à la cellule CKB de CKB, qui contient tous les états de contrat en interne, l'UTXO de Fuel ne transporte pas réellement tous les états de contrat liés à la transaction. Fuel ne transporte que la racine d'état du contrat Stateroot dans l'UTXO, qui est la racine de l'arbre d'états. L'état complet du contrat est stocké à l'intérieur de la bibliothèque d'états de Fuel et est détenu par le contrat intelligent.

Il convient de mentionner qu'en ce qui concerne le traitement de l'état des contrats intelligents, le contrat Fuel et le contrat de solidité sont idéologiquement cohérents et même relativement proches dans leur forme de programmation. La figure ci-dessous montre un contrat de compteur écrit dans le langage Sway de Fuel. Le contrat contient un compteur. Lorsque l'utilisateur appelle la fonction increment_counter, le compteur stocké dans le contrat est incrémenté de 1.

Nous pouvons voir que la logique d'écriture du contrat Sway est similaire à celle d'un contrat Solidity général. Nous donnons d'abord l'ABI du contrat, puis les variables d'état du contrat, et enfin la mise en œuvre spécifique du contrat. Tous les processus d'écriture de code n'impliquent pas le système UTXO de Fuel.

Par conséquent, l'expérience de programmation de contrats de Fuel est différente de celle des langages de programmation UTXO tels que CKB et Cardano. Fuel offre une expérience plus proche de la programmation et du développement de contrats intelligents EVM. Les développeurs peuvent également utiliser le langage Sway pour construire des scripts de déverrouillage afin de mettre en œuvre une logique de vérification d'algorithme de signature spéciale ou une logique de déverrouillage multi-signature complexe.

Il est essentiellement réalisable de mettre en œuvre une liaison isomorphe au sein de Fuel, mais il reste les problèmes suivants :

Le langage d'influence utilisé par Fuel est plus proche de la chaîne EVM en termes de conception de contrats intelligents que de BTC ou CKB et Cardano. Les émetteurs d'actifs UTXO tels que RGB et Atomics doivent spécifiquement construire un contrat intelligent sur Fuel. CKB et d'autres chaînes utilisent un autre, qui est assez compliqué.

Cardano : chaîne publique eUTXO basée sur POS

Cardano est une autre blockchain qui utilise le modèle UTXO, mais contrairement à Fuel, c'est une chaîne publique de couche 1. Cardano utilise eUTXO (Extended UTXO) pour faire référence au modèle de programmation UTXO dans son système. Comparé à CKB, l'eUTXO dans Cardano contient les structures suivantes :

Script: Les contrats intelligents sont utilisés pour vérifier si UTXO peut être déverrouillé et effectuer des transitions d'état;

Rédempteurs: Les données fournies par les utilisateurs pour déverrouiller UTXO sont généralement des données de signature, similaires au témoin de Bitcoin;

Donnée: L'espace d'état des contrats intelligents peut stocker des données telles que le statut des actifs;

Contexte de transaction: Données contextuelles pour les transactions UTXO, telles que les paramètres d'entrée et les résultats de la transaction (Le processus de calcul de la transaction de la chaîne UTXO est effectué directement hors chaîne, et les résultats du calcul sont soumis à vérification à la chaîne. S'ils passent la vérification, les résultats de la transaction sont téléchargés sur la chaîne)

Les développeurs peuvent utiliser le langage PlutusCore pour programmer UTXO sur la chaîne Cardano. Tout comme CKB, les développeurs peuvent écrire des scripts de déverrouillage et certaines fonctions pour les mises à jour de statut.

Nous introduisons le modèle de programmation UTXO de Cardano avec un processus d'enchères basé sur l'UTXO. Supposons que nous devons mettre en œuvre une DAPP d'enchères d'actifs qui nécessite que les utilisateurs fassent des offres avant la fin de l'enchère. Plus précisément, l'utilisateur consomme son propre UTXO, contracte l'UTXO avec cette enchère, puis génère un nouveau UTXO. Lorsque quelqu'un fait une offre plus élevée, en plus de générer un nouvel UTXO de contrat d'enchère, un UTXO de remboursement pour la personne précédente sera également généré. Le processus spécifique est le suivant:

Pour mettre en oeuvre le processus d'enchères ci-dessus, certains états doivent être stockés dans l'UTXO du contrat intelligent d'enchères, tels que le prix le plus élevé de l'enchère en cours et la personne ayant fait l'offre. La figure ci-dessous montre l'énoncé d'état à l'intérieur de PlutusCore. Nous pouvons voir que bBidder et bAmount affichent l'offre aux enchères et l'adresse du portefeuille ayant fait l'offre. Les paramètres de l'enchère contiennent les informations de base de l'enchère.

Lorsqu'un utilisateur dépense cette UTXO, nous pouvons mettre à jour l'état dans le contrat. La figure ci-dessous montre des mises à jour d'état spécifiques et la logique métier dans le contrat d'enchères. Par exemple, la logique de vérification des offres des utilisateurs et la vérification si l'enchère en cours est toujours en cours. bien sûr, Comme PlutusCore est un langage de programmation Haskell, qui est un langage de programmation purement fonctionnel, la plupart des développeurs ne pourront peut-être pas comprendre directement sa signification.

Il est réalisable de construire des liaisons isomorphes sur Cardano, nous pouvons utiliser Datum pour stocker l'état des actifs et écrire des scripts spécifiques pour être compatibles avec les algorithmes de signature liés à Bitcoin. Mais le problème sérieux est que la plupart des programmeurs pourraient ne pas être en mesure de s'adapter à l'utilisation de PlutusCore pour la programmation de contrats. De plus, son environnement de programmation est difficile à configurer et n'est pas convivial pour les développeurs.

Résumé

La liaison isomorphique nécessite que la chaîne ait les propriétés suivantes :

1. Utiliser le modèle UTXO
2. Possède une programmabilité UTXO considérable, permettant aux développeurs d'écrire des scripts de déverrouillage
3. Il existe un espace d’état lié à UTXO qui peut stocker l’état des ressources
4. Il peut prendre en charge l'exécution de nœuds légers Bitcoin via des contrats intelligents ou d'autres moyens.

En raison de la particularité de ses idées de programmation de contrats intelligents, Fuel est compatible avec la liaison isomorphique, mais cela apporte tout de même quelques inconvénients ; tandis que Cardaon utilise le langage de programmation Haskell pour la programmation de contrats, ce qui rend difficile le démarrage rapide pour la plupart des développeurs. Pour les raisons mentionnées ci-dessus, CKB, qui adopte l'ensemble d'instructions RISC-V et est plus équilibré dans les caractéristiques de la programmation UTXO, peut être une couche d'extension de fonction plus adaptée à la liaison isomorphique.

Disclaimer：

1. Cet article est repris de [ 极客 Web3]. Transférer le titre original 'RGB++与同构绑定：CKB、Cardano与Fuel如何赋能比特币生态'. Tous les droits d'auteur appartiennent à l'auteur original [Shew]. S'il y a des objections à cette réimpression, veuillez contacter le Porte Apprendreéquipe et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf indication contraire, il est interdit de copier, distribuer ou plagier les articles traduits.