En juillet 2024, CKB a officiellement annoncé le lancement de la couche RGB++, marquant la transformation du protocole théorique précédent en un produit entièrement conçu, prêt à introduire des scénarios d'application plus concrets et pratiques. Avec la vision de construire un écosystème BTCFi à travers BTC et d'autres chaînes publiques basées sur UTXO telles que CKB et Cardano, la couche RGB++ a rapidement suscité une attention significative. En résumé, la couche RGB++ est basée sur le protocole RGB++, utilisant la liaison homomorphe et la technologie Leap pour offrir une expérience d'interaction transparente entre chaînes pour les actifs ou inscriptions/runes RGB++ natifs sur UTXO basées sur des blockchains telles que BTC, CKB et Cardano sans avoir besoin de ponts entre chaînes. En tirant parti de l'environnement de contrat intelligent complet de Turing de CKB, il établit les conditions nécessaires pour que Bitcoin atteigne des fonctions DeFi complexes. De plus, soutenu par l'écosystème complet d'abstraction de compte de CKB, il est compatible avec les comptes et portefeuilles Bitcoin, offrant une excellente expérience utilisateur aux utilisateurs de Bitcoin et ouvrant la voie à l'adoption généralisée de BTCFi. Dans le texte suivant, plongeons dans les principes de fonctionnement et les caractéristiques de la couche RGB++ et explorons les changements qu'elle apportera à l'écosystème BTCFi. Étant donné que sa base théorique est construite sur le protocole RGB++, nous commencerons par discuter du protocole lui-même.

Protocole RGB++ : Fondement théorique de la couche RGB++

Le protocole RGB++, lancé en janvier de cette année, transforme fondamentalement la méthode de validation du protocole RGB, passant de la «validation côté client» à la vérification on-chain sur la chaîne CKB. Essentiellement, cette approche exploite CKB en tant qu'indexeur décentralisé, confiant des tâches telles que le stockage des données et la vérification de la source des actifs à CKB. Cela positionne CKB en tant que couche de validation et couche DA pour le protocole RGB, résolvant les problèmes d'expérience utilisateur et les limitations de support DeFi inhérentes au protocole RGB d'origine.

En s'alignant avec le concept de 'capsulation unique', RGB++ introduit la notion de liaison homomorphique, en utilisant les UTXO étendues de la chaîne CKB - les Cells - en tant que support de données pour les actifs d'inscription ou de rune. Ces Cells sont ensuite liées aux UTXO sur les chaînes Bitcoin, Cardano ou Liquid, permettant aux actifs RGB++ d'hériter de la sécurité de ces blockchains basées sur les UTXO et d'empêcher les doubles dépenses. Cette approche de 'liaison pour hériter de la sécurité' est analogue aux scénarios du monde réel où un compte bancaire doit être lié à un numéro de téléphone et à une carte d'identité pour une sécurité renforcée.

Par exemple, supposons qu'Alice souhaite transférer certains jetons TEST à Bob. Elle peut générer une déclaration liant la cellule qui stocke les informations sur l'actif TEST à l'UTXO Bitcoin de Bob. Si Bob a l'intention de transférer les jetons TEST à quelqu'un d'autre, l'UTXO Bitcoin lié doit également être transféré. Cela crée une relation de liaison un à un entre la cellule transportant les données d'actif RGB++ et l'UTXO Bitcoin. Tant que l'UTXO Bitcoin n'est pas dépensé en double, l'actif RGB++ lié ne le sera pas non plus.

Lorsqu'on discute de la couche RGB++, il s'agit essentiellement d'une implémentation ingénieuse du protocole RGB++, présentant deux caractéristiques principales : liaison isomorphe et pont sans saut entre chaînes. Plongeons dans les principes techniques de la liaison isomorphe et du pont sans saut.

Liaison isomorphe et Leap: émission d'actifs de BTCFi et couche inter-chaîne sans pont

Pour bien comprendre les concepts de liaison isomorphe et Leap, nous devons d'abord expliquer brièvement le modèle Cell de CKB. Essentiellement, une Cellule est un UTXO étendu (Unspent Transaction Output) avec plusieurs champs, y compris LockScript, TypeScript et Data. Le LockScript fonctionne de manière similaire au script de verrouillage de Bitcoin et est utilisé pour la vérification des autorisations. TypeScript est semblable au code de contrat intelligent, tandis que Data est utilisé pour stocker les données d'actif.

Pour émettre des actifs RGB++ sur la blockchain CKB, vous devez d'abord créer une cellule et remplir les champs pertinents avec le symbole du jeton et le code du contrat. Par exemple, vous pourriez définir le symbole du jeton sur "TEST." Ces cellules peuvent ensuite être désassemblées et distribuées à de nombreux utilisateurs, de manière similaire à la façon dont les UTXOs (Unspent Transaction Outputs) de Bitcoin sont divisés et transférés.

Parce que la structure des cellules est similaire à l'UTXO de Bitcoin et que CKB peut prendre en charge les algorithmes de signature de Bitcoin, les utilisateurs peuvent manipuler les actifs sur la chaîne CKB à l'aide des portefeuilles Bitcoin. Si vous possédez une cellule, vous pouvez configurer le script de verrouillage pour correspondre aux conditions de déverrouillage des UTXO Bitcoin. Cela vous permet d'utiliser des clés privées Bitcoin pour contrôler les cellules sur la chaîne CKB. Cette capacité s'étend à CKB, BTC et d'autres chaînes publiques basées sur UTXO. Par exemple, vous pourriez utiliser un compte Cardano pour modifier les données d'actifs sur la chaîne CKB, transférer le contrôle des actifs RGB++ d'un compte BTC à un compte Cardano sans avoir besoin d'un pont inter-chaînes.

Ce processus nécessite de lier des actifs RGB++ à des UTXOs sur des chaînes publiques telles que Bitcoin, Cardano et Liquid, tout comme lier un compte bancaire à un numéro de téléphone et une pièce d'identité dans le monde réel. Les actifs RGB++ sont essentiellement des données qui nécessitent un support de stockage tel qu'une base de données; dans ce cas, les Cellules CKB agissent comme la base de données. Vous pouvez configurer une vérification d'autorisation pour permettre à différents comptes de chaîne publique (BTC, Cardano, etc.) de modifier les données des actifs RGB++ sur la chaîne CKB. C'est le principe fondamental de la liaison isomorphique.

Traversée sans saut et sans pont entre les chaînes

Les fonctions de « saut » et de chaîne croisée sans pont de la couche RVB++ sont basées sur la liaison isomorphe. Ils permettent la « reliaison » des UTXO associés aux ressources RVB++. Par exemple, si votre actif était initialement lié à un UTXO Bitcoin, vous pouvez le relier à un UTXO sur Cardano, Liquid, Fuel ou d’autres chaînes. Cela signifie que vous pouvez transférer le contrôle des actifs d’un compte BTC à un compte Cardano, le tout sans avoir besoin d’un pont inter-chaînes.

Du point de vue de l'utilisateur, cela équivaut à un transfert d'actifs inter-chaînes, le CKB agissant à la fois en tant qu'indexeur et base de données. Cependant, contrairement aux méthodes inter-chaînes traditionnelles, "Leap" ne modifie que les autorisations d'utilisation des données d'actifs, tandis que les données elles-mêmes restent stockées sur la chaîne CKB. Cette approche est plus simple que le modèle Lock-Mint et élimine la dépendance aux contrats d'actifs de mappage. L'explication ci-dessus est un aperçu produit de la liaison isomorphique et de Leap. Comprenons leur mise en œuvre technique à travers un exemple spécifique.

Mise en œuvre de la liaison isomorphique

Comprendre la mise en œuvre technique de la liaison isomorphe. Supposons qu'Alice possède 100 jetons TEST, avec des données stockées dans la cellule n°0, liées à UTXO#0 sur la chaîne Bitcoin. Maintenant, Alice souhaite transférer 40 jetons TEST à Bob. Tout d'abord, elle divise la cellule n°0 en deux nouvelles cellules: la cellule n°1, contenant 40 jetons TEST, qui est transférée à Bob, et la cellule n°2, contenant 60 jetons TEST, qui reste sous le contrôle d'Alice. Au cours de ce processus, le BTC UTXO#0 lié à la cellule n°0 est également divisé en UTXO#1 et UTXO#2, liés respectivement à la cellule n°1 et à la cellule n°2. Lorsqu'Alice transfère la cellule n°1 à Bob, elle peut également transférer le BTC UTXO#1 à Bob avec une seule opération, réalisant ainsi des transactions synchronisées sur les chaînes CKB et BTC.

Nous pouvons comprendre la liaison isomorphique en profondeur ici. En fait, le sens fondamental de ce concept est que la Cellule de CKB, l'eUTXO de Cardano et l'UTXO de BTC sont tous des modèles UTXO, et que CKB est compatible avec l'algorithme de signature Bitcoin/Cardano. La décomposition et le transfert de l'UTXO qui se produit sur les deux dernières chaînes peuvent également être synchronisés 1:1 avec la Cellule sur la chaîne CKB. De cette façon, lorsque nous opérons l'UTXO de BTC lié à l'actif RGB++, les résultats de l'opération peuvent être synchronisés avec la Cellule sur la chaîne CKB, tout comme la relation entre l'entité et l'ombre. De plus, nous devons également prêter attention à l'actif RGB++ est associé aux deux entités BTC UTXO et CKB Cell, tous deux composants de l'actif RGB++. Tous deux sont indispensables.

Si nous examinons le cas susmentionné d'Alice transférant de l'argent à Bob, le processus général est le suivant :1. Alice construit localement des données de transaction CKB (sans les télécharger sur la chaîne pour le moment). Cette transaction indique que Cell#0, qui enregistre les données d'actifs, sera détruite, Cell#1 sera générée et donnée à Bob, et Cell#2 sera conservée pour elle-même ;2. Alice génère localement une déclaration, lie Cell#1 à BTC UTXO#1, lie Cell#2 à BTC UTXO#2, et envoie à la fois Cell#1 et BTC UTXO#1 à Bob ;3. Ensuite, Alice génère localement un Engagement (similaire à un hachage), et le contenu original correspondant contient la déclaration à l'étape 2 + les données de transaction CKB générées à l'étape 1. Les données d'engagement seront ensuite enregistrées sur la chaîne Bitcoin ;4. Alice lance une transaction sur la chaîne Bitcoin, détruit UTXO#0, génère UTXO#1 et l'envoie à Bob, garde UTXO#2 pour elle-même, et écrit l'engagement sur la chaîne Bitcoin sous la forme d'un code opérationnel OP_Return ;5. Après l'achèvement de l'étape 4, envoyez la transaction CKB générée à l'étape 1 à la chaîne CKB.

Certains des détails plus compliqués ont été omis ci-dessus.En fait, lorsque Alice transfère ses actifs RGB++ à Bob, elle doit d'abord effectuer une vérification d'identité complexe pour prouver qu'elle est effectivement propriétaire de la Cellule n°0.Les éléments impliqués ici incluent: 1. Prouver que la Cellule n°0 et le BTC UTXO n°0 sont effectivement liés; 2. Alice prouve qu'elle est le véritable contrôleur de la Cellule n°0 et du BTC UTXO n°0. Faites attention, les Cellules et les Bitcoin UTXOs écrits avec des données d'actifs RGB++ peuvent être réécrits simultanément par des comptes Bitcoin. Pendant tout le processus d'interaction, des opérations en un clic peuvent être effectuées via des comptes Bitcoin.Les scénarios ci-dessus ne se limitent pas à la liaison isomorphe entre Bitcoin et CKB, mais peuvent être étendus à Cardano, Liquid, Litecoin et autres grandes catégories. Il y a encore beaucoup de place pour l'imagination.

Principes de mise en œuvre de Leap et scénarios de support

Nous avons mentionné précédemment que la fonction Leap consiste en réalité à basculer l'UTXO lié à l'actif RGB++, tel que le basculer de Bitcoin à Cardano, puis vous pouvez utiliser le compte Cardano pour contrôler l'actif RGB++.

Nous pouvons remarquer que tout au long de ce processus, les données d'actifs RGB++ sont toujours stockées sur la chaîne CKB, mais l'UTXO Bitcoin associé aux conditions de déverrouillage est modifié en eUTXO sur la chaîne Cardano. Bien sûr, le processus d'exécution spécifique est beaucoup plus compliqué que ce qui est mentionné ci-dessus, je n'entrerai donc pas dans les détails ici. De plus, il y a une hypothèse implicite dans le plan Leap, à savoir que la chaîne publique CKB sert de témoin tiers, d'indice et de facilité DA. En tant que chaîne publique, sa crédibilité dépasse de loin les méthodes traditionnelles de pont inter-chaînes telles que le MPC et la multi-signature. En fait, des scénarios très intéressants peuvent être réalisés grâce à la fonction Leap. Par exemple, nous pouvons réaliser des «transactions sur l'ensemble de la chaîne». Supposons que nous construisions un indexeur à travers Bitcoin, Cardano et CKB, et construisions une plate-forme de trading permettant aux acheteurs et aux vendeurs de négocier des actifs RGB++. Les acheteurs peuvent transférer leurs Bitcoins aux vendeurs, puis utiliser leurs comptes Cardano pour recevoir les actifs RGB++. Pendant ce processus, les données de l'actif RGB++ sont toujours enregistrées dans la Cellule, mais la Cellule sera transférée à l'acheteur, puis son autorisation de déverrouillage sera modifiée de l'UTXO Bitcoin du vendeur à l'eUTXO Cardano de l'acheteur.

Wrapper

Bien que la fonction Leap soit parfaite pour les actifs RGB++, il existe encore quelques goulots d'étranglement : pour Bitcoin et Cardano, les actifs RGB++ sont essentiellement des inscriptions/runes/pièces teintées basées sur l'opcode OP_RETURN. Ces nœuds de chaîne publique ne peuvent pas percevoir l'existence des actifs RGB++, et CKB participe en réalité à la coordination en tant qu'indexeur. Autrement dit, pour Bitcoin et Cardano, la couche RGB++ prend principalement en charge le Leap des inscriptions/runes/pièces teintées, et non le transfert inter-chaîne des actifs natifs tels que le BTC et l'ADA. À cet égard, la couche RGB++ a officiellement introduit Wrapper, qui peut être simplement compris comme un pont basé sur une preuve de fraude et une sur-collatéralisation. Prenons le wrapper rBTC comme exemple, il fait le pont entre BTC et la couche RGB++, et un ensemble de contrats intelligents s'exécutant sur la couche RGB++ surveillent les gardiens du pont. Si un gardien se comporte de manière malveillante, sa garantie sera réduite. Si les gardiens collaborent pour voler des BTC verrouillés, les détenteurs de rBTC peuvent recevoir une compensation intégrale.

Après avoir combiné Leap et Wrapper, divers actifs de l'écosystème BTCFi, tels que les actifs natifs RGB++, BRC20, ARC20, runes, etc., peuvent être transférés vers d'autres couches ou chaînes publiques.

L'image ci-dessous fait partie du processus de demande de LeapX. Vous pouvez voir qu'il prend en charge l'interopérabilité de presque tous les actifs BTCFi principaux dans différents écosystèmes. Et il existe des procédures de traitement correspondantes pour les actifs avec différentes méthodes d'émission. Certains utilisent un wrapper, et d'autres utilisent leap.

CKB-VM : moteur de contrat intelligent de BTCFi

Ci-dessus, nous avons principalement expliqué les concepts de liaison isomorphe et de saut de la couche RVB++. Examinons d’autres points ci-dessous. Dans BTCFi traditionnel, en raison de l’absence de prise en charge des contrats intelligents, seules quelques Dapps relativement simples peuvent être mises en œuvre. Certaines méthodes de mise en œuvre comportent certains risques de centralisation, tandis que d’autres sont maladroites et inflexibles. Afin de mettre en œuvre une couche de contrat intelligent disponible sur la blockchain, CKB fournit CKB-VM pour la couche RVB++. N’importe quel langage de programmation pouvant prendre en charge la machine virtuelle RISC-V peut être utilisé pour le développement de contrats sur la couche RVB++.Les développeurs peuvent utiliser leurs outils et langages préférés pour réaliser un développement et un déploiement de contrats intelligents efficaces et sécurisés dans un cadre et un environnement d’exécution de contrats intelligents unifiés. Ce qui suit est une méthode de transfert d’UDT de jeton défini par l’utilisateur dans CKB implémentée en langage C. On peut voir qu’à l’exception de la différence de langage, sa logique de base est la même que celle des jetons généraux. Étant donné que RISC-V dispose d’une prise en charge étendue du langage et du compilateur, les exigences pour les développeurs pour se lancer dans le développement de contrats intelligents sont relativement faibles. Nous pouvons facilement réécrire cette logique en utilisant JavaScript, Rust, Go, Java et Ruby. Au lieu d’avoir à apprendre un certain langage DSL pour rédiger des contrats. Bien sûr, le langage n’est qu’un aspect de la programmation, et l’apprentissage de cadres de contrats intelligents spécifiques est inévitable.

Écologie AA native : connectez de manière transparente BTC et RGB++

Enfin, permettez-nous de comprendre brièvement l'écologie native AA et l'abstraction de compte derrière RGB++ Layer. Puisque l'essence de BTCFi est de fournir une expérience Defi diversifiée pour les actifs natifs Bitcoin, qu'il soit compatible avec les portefeuilles Bitcoin grand public sera un facteur important à considérer pour les installations périphériques BTCFi. RGB++ Layer réutilise directement la solution native AA de CKB et peut être compatible avec d'importantes chaînes publiques UTXO telles que BTC et Cardano du côté développeur et utilisateur. Dans RGB++ Layer, les utilisateurs peuvent utiliser différents algorithmes de signature pour l'authentification. Par exemple, les utilisateurs peuvent manipuler directement des actifs sur RGB++ Layer à l'aide de comptes, de portefeuilles ou de méthodes d'authentification tels que BTC, Cardano ou même WebAuthn. Prenons l'exemple du middleware de portefeuille CCC, qui peut fournir aux portefeuilles et dApps la capacité d'interagir avec diverses chaînes publiques sur CKB. L'image ci-dessous est la fenêtre de connexion de CCC. Nous pouvons voir qu'il prend en charge des entrées de portefeuille grand public telles que Unisat et Metamask.

Un autre exemple est la mise en œuvre de WebAuthn, dont le portefeuille écologique CKB JoyID est un représentant typique. Avec JoyID, les utilisateurs peuvent s'authentifier directement via des biométriques tels que l'empreinte digitale ou la reconnaissance faciale, permettant une connexion et une gestion d'identité transparentes et hautement sécurisées. On peut dire que la base pour la liaison isomorphique et Leap est que la couche RGB++ dispose d'une solution native AA complète, qui est bien compatible avec les normes de compte des autres chaînes publiques. Cette fonctionnalité facilite non seulement le support de certains scénarios clés, mais ouvre également la voie à une UX claire.

Résumer

Dans ce qui précède, nous avons examiné l'image globale de la couche RGB++. Il peut être utilisé comme une infrastructure importante pour diverses Memecoins telles que les inscriptions/runes/pièces teintes pour réaliser des scénarios d'interaction de chaîne complète. L'environnement d'exécution de contrat intelligent construit par la couche RGB++ basée sur RiscV peut créer un sol pour la logique d'entreprise complexe requise par BTCFi. En raison des limites d'espace, cet article n'est qu'une vulgarisation simple de la technologie de base de la couche RGB++, et ne mène pas une vulgarisation systématique de nombreux détails complexes. À l'avenir, nous continuerons à surveiller les progrès de la couche RGB++ et à effectuer une analyse plus approfondie et approfondie d'une série de solutions techniques liées à ce projet. Restez à l'écoute!

déclaration:

1. Cet article est reproduit à partir de [.geek web3], les droits d'auteur appartiennent à l'auteur original [Faust & Misty Moon], si vous avez des objections à la reproduction, veuillez contacter leGate Learnl'équipe, et l'équipe s'en occupera dès que possible selon les procédures pertinentes.

2. Avertissement: Les points de vue et opinions exprimés dans cet article ne représentent que les points de vue personnels de l'auteur et ne constituent pas un conseil en investissement.

3. Les autres versions linguistiques de l'article sont traduites par l'équipe Gate Learn et ne sont pas mentionnées.Gate.io, l'article traduit ne peut être reproduit, distribué ou plagié.