Auteur : Faust & Wuyue, de GeekWeb3 & BTCEden

L'annonce du lancement de la couche RGB++ ce mois-ci, en juillet 2024, marque la transition complète du protocole RGB++ précédemment publié, de la théorie à un produit d'ingénierie. Avec sa grande vision de construire un écosystème BTCFi sur BTC, CKB, Cardano et d'autres chaînes publiques pan-UTXO (sortie de transaction non dépensée), le lancement de la couche RGB++ contribue également à introduire des scénarios plus spécifiques et pratiques pour la plate-forme, ce qui en fait le point central. d'attention pour d'innombrables personnes.

Basée sur le protocole RGB++, la couche RGB++ utilise la liaison isomorphe et Leap pour fournir une expérience d'interaction inter-chaînes « sans pont » pour les actifs natifs RGB++ ou les inscriptions/runes entre BTC, CKB, Cardano et d'autres chaînes publiques de type UTXO. Il exploite l'environnement de contrat intelligent complet Turing de CKB pour créer les conditions nécessaires permettant à Bitcoin d'émettre des actifs et de mettre en œuvre des fonctions DeFi complexes. Étant donné que l'écosystème complet d'abstraction de compte de CKB le soutient et est compatible avec les comptes et les portefeuilles Bitcoin, il ouvre également la voie à l'adoption à grande échelle de BTCFi.

Cet article a pour but d'aider à comprendre les principes généraux de fonctionnement et les caractéristiques fonctionnelles de la couche RGB++. Il met également en évidence les changements que la couche apportera à l'écosystème BTCFi en fonction de ses quatre caractéristiques distinctives.

1. Protocole RGB++ comme fondement théorique de la couche RGB++

Le protocole RGB++ a été publié en janvier pour remplacer la « vérification côté client » du protocole RGB par la vérification en chaîne CKB. Il utilise CKB comme indexeur décentralisé, déléguant des tâches telles que le stockage des données et la vérification de la source des actifs à CKB, cette dernière servant de couche de vérification et de couche de disponibilité des données (DA) pour le protocole RVB. Il s'agit d'aider à résoudre les problèmes de transactions non dépensées (UX) et les défauts défavorables dans les scénarios DeFi dans le protocole RVB.

Conformément au concept « d'encapsulation unique », la liaison isomorphe de RGB++ utilise Cell – un UTXO étendu sur la chaîne CKB – comme support de données pour les actifs d'inscription/de type rune afin d'établir une relation de liaison avec les UTXO sur la chaîne Bitcoin pour hériter de la sécurité de Bitcoin.

Par exemple, si Alice souhaite transférer des jetons TEST à Bob, elle peut générer une déclaration qui lie la cellule stockant les informations sur les actifs TEST à l'un des UTXO Bitcoin de Bob. Si Bob souhaite transférer les jetons TEST à quelqu'un d'autre, le Bitcoin UTXO lié doit également être transféré. De cette manière, il existe une relation de liaison 1 à 1 entre la cellule transportant les données d'actifs RGB++ et le Bitcoin UTXO. Tant que le Bitcoin UTXO n’est pas dépensé deux fois, l’actif RGB++ lié ne peut pas être dépensé deux fois. Avec ce mécanisme, les actifs RGB++ ont hérité de la sécurité de Bitcoin.

La couche RGB++ est un produit de la mise en œuvre technique du protocole RGB++. Ses deux caractéristiques principales sont la liaison isomorphe et la chaîne croisée sans pont Leap.

2. Liaison isomorphe et saut - Émission d'actifs et couche inter-chaînes sans pont pour BTCFi

Pour comprendre la liaison isomorphe et l’approche Leap, il est essentiel d’expliquer le modèle Cell de CKB. Une cellule est un UTXO étendu avec plusieurs champs tels que LockScript, TypeScript et Data. Le LockScript fonctionne de manière similaire au script de verrouillage de Bitcoin, utilisé pour la vérification des autorisations ; TypeScript est similaire au code de contrat intelligent, tandis que Data est utilisé pour stocker les données d'actifs.

Si vous souhaitez émettre des actifs RGB++ sur la chaîne CKB, créez d'abord une cellule et écrivez le symbole du jeton et le code du contrat dans les champs appropriés. Ensuite, vous pouvez décomposer la cellule et la distribuer à de nombreuses personnes, tout comme le fractionnement et le transfert de Bitcoin UTXO.

Grâce à la similitude structurelle de la cellule avec les UTXO Bitcoin et à la similitude de CKB avec l'algorithme de signature de Bitcoin, les utilisateurs peuvent manipuler les actifs de la chaîne CKB à l'aide de portefeuilles Bitcoin. En tant que propriétaire d'une Cell, vous pouvez définir son script de verrouillage pour que sa condition de déverrouillage soit cohérente avec celle d'un Bitcoin UTXO, vous permettant ainsi de manipuler directement les Cells sur la chaîne CKB à l'aide de la clé privée d'un compte Bitcoin.

Les fonctionnalités soulignées ci-dessus peuvent également être implémentées entre CKB, BTC et d'autres chaînes publiques UTXO. Par exemple, vous pouvez utiliser un compte Cardano pour réécrire les données d'actifs sur la chaîne CKB, et les droits de contrôle des actifs RGB++ sont transférés d'un compte BTC vers un compte Cardano sans pont entre chaînes. N'oubliez pas que la liaison des actifs RGB++ aux UTXO sur les chaînes publiques telles que Bitcoin, Cardano, Liquid, etc. – de la même manière que les comptes bancaires sont liés aux numéros de téléphone et aux identifiants des clients dans des cas réels – vise à éviter les doubles dépenses.

Il convient également de noter que les actifs RGB++ sont un ensemble de données qui nécessitent un stockage multimédia comme dans une base de données. Les cellules de la chaîne CKB peuvent servir de base de données. Ensuite, la vérification des autorisations pourrait être définie pour autoriser l'accès aux comptes de différentes chaînes publiques comme BTC et Cardano afin de réécrire les données d'actifs RGB++ sur la chaîne CKB.

Les chaînes croisées « Leap » et sans pont proposées par RGB++ Layer sont basées sur la technologie de liaison isomorphe. Ils servent à « re-lier » les UTXO liés aux actifs RGB++. Par exemple, si vos actifs étaient auparavant liés aux UTXO Bitcoin, ils peuvent désormais être liés aux UTXO sur Cardano, Liquid, Fuel et d'autres chaînes. En conséquence, les autorisations de contrôle des actifs sont transférées des comptes BTC vers Cardano ou d’autres comptes.

Du point de vue de l'utilisateur, cela équivaut à un cross-chaining d'actifs, CKB jouant un rôle similaire à celui d'un indexeur et d'une base de données. Cependant, contrairement aux méthodes cross-chain traditionnelles, "Leap" modifie uniquement l'autorisation de modifier les données des actifs, tandis que les données elles-mêmes sont toujours stockées sur la chaîne CKB. Cette méthode est plus concise que le modèle Lock-Mint et élimine la dépendance aux contrats d'actifs mappés.

Approche de mise en œuvre technique de la liaison isomorphe

En supposant qu'Alice dispose de 100 jetons TEST dont les données sont stockées dans la cellule n°0 et ont une relation contraignante avec UTXO#0 sur la chaîne Bitcoin. Pour transférer 40 jetons TEST à Bob, elle doit diviser la cellule n°0 en deux nouvelles cellules, la cellule n°1 contenant 40 jetons TEST à transférer à Bob et la cellule n°2 contenant 60 jetons TEST toujours contrôlés par Alice.

Dans ce processus, le BTC UTXO#0 lié à la cellule#0 doit être divisé en UTXO#1 et UTXO#2, puis lié respectivement à la cellule#1 et à la cellule#2. Ainsi, lorsqu'Alice transfère la cellule n°1 à Bob, elle peut également transférer BTC UTXO#1 à Bob, en un seul clic, pour réaliser des transactions synchrones sur les chaînes CKB et BTC.

L’importance fondamentale de la liaison isomorphe est son adaptabilité. Ceci est particulièrement essentiel puisque le Cell de CKB, l'eUTXO de Cardano et l'UTXO de Bitcoin sont tous des modèles UTXO et que CKB est compatible avec les algorithmes de signature Bitcoin/Cardano. Les méthodes de fonctionnement des UTXO sur les chaînes Bitcoin et Cardano fonctionnent également pour les cellules de la chaîne CKB. De cette façon, les comptes Bitcoin/Cardano peuvent être directement utilisés pour contrôler simultanément les actifs RGB++ sur la chaîne CKB et leurs UTXO Bitcoin/Cardano liés, réalisant ainsi des transactions synchrones 1:1.

En suivant le scénario Alice transféré à Bob ci-dessus, le flux de travail général est le suivant :

1. Alice construit localement des données de transaction CKB (pas encore en chaîne), spécifiant que la cellule n°0 sera détruite, la cellule n°1 à envoyer à Bob est générée et la cellule n°2 doit être conservée pour elle-même ;

   
   

2. Alice génère une déclaration localement, liant Cell#1 à UTXO#1 et Cell#2 à UTXO#2, et envoyant à la fois Cell#1 et UTXO#1 à Bob ;

   
   

3. Ensuite, Alice génère localement un Engagement (semblable à un hachage), correspondant au contenu original comprenant la déclaration de l'étape 2 + les données de transaction CKB générées à l'étape 1 ;

   
   

4. Alice initie une transaction sur la chaîne Bitcoin, détruit UTXO#0, génère UTXO#1 à envoyer à Bob, garde UTXO#2 pour elle-même et écrit l'engagement envers la chaîne Bitcoin sous la forme d'un opcode OP_Return ;

   
   

5. Une fois l'étape 4 terminée, la transaction CKB générée à l'étape 1 est envoyée à la chaîne CKB.

Notez que la cellule et le Bitcoin UTXO correspondant sont liés de manière isomorphe et peuvent être directement contrôlés par les comptes Bitcoin. Autrement dit, pendant le processus d'interaction, les utilisateurs peuvent effectuer des opérations en un clic via les comptes Bitcoin dans le portefeuille RGB++. Par conséquent, les actifs RGB++ liés aux UTXO Bitcoin aident à résoudre le problème de double dépense, car les actifs de la couche RGB++ héritent de la sécurité de Bitcoin.

Le scénario ci-dessus ne se limite pas à la liaison isomorphe entre Bitcoin et CKB, mais s'applique également à un large éventail de chaînes, notamment Cardano, Liquid, Litecoin, etc.

Principe de mise en œuvre et scénarios pris en charge de Leap

La fonction Leap consiste essentiellement à basculer l'UTXO lié aux actifs RGB++, par exemple en changeant la liaison de Bitcoin à Cardano, après quoi vous pouvez contrôler les actifs RGB++ à l'aide des comptes Cardano. Dans un tel cas, un transfert pourrait toujours être effectué sur la chaîne Cardano par la suite, divisant et transférant les actifs UTXO contrôlant RGB++ à plus de personnes. Bien que les actifs RGB++ puissent être transférés et distribués sur plusieurs chaînes publiques UTXO, ils peuvent contourner le modèle traditionnel de pont inter-chaînes Lock-Mint.

Dans ce processus, la chaîne publique CKB joue un rôle similaire à celui d'un indexeur, observant et traitant les requêtes Leap. Supposons que vous souhaitiez transférer des actifs RGB++ liés au BTC vers un compte Cardano, les principales étapes à suivre sont :

1. Publier un Engagement sur la chaîne Bitcoin, déclarant la dissociation de la Cellule liée au BTC UTXO ;

   
   

2. Publier un engagement sur la chaîne Cardano, déclarant la liaison de la cellule au Cardano UTXO ;

   
   

3. Modifiez le script de verrouillage de la cellule, en changeant la condition de déverrouillage d'une clé privée de compte Bitcoin à une clé privée de compte Cardano

Notez que les données des actifs RGB++ sont toujours stockées sur la chaîne CKB tout au long de ce processus. La condition de déverrouillage passe d’une clé privée Bitcoin à une clé privée Cardano. Bien entendu, le processus d’exécution spécifique est beaucoup plus complexe que celui décrit ci-dessus, mais nous ne le détaillerons pas ici.

Dans le passage aux chaînes publiques non CKB, le principe implicite est que la chaîne publique CKB agit en tant que témoin tiers, indexeur et installation DA. En effet, en tant que chaîne publique, sa crédibilité dépasse de loin les méthodes traditionnelles de pont entre chaînes telles que le calcul multipartite (MPC) et la multi-signature.

Un autre scénario intéressant qui peut être implémenté sur la base de la fonction Leap est celui des « transactions en chaîne complète ». Un exemple de ce scénario est celui où un indexeur est mis en place sur Bitcoin, Cardano et CKB pour créer une plateforme de trading permettant aux acheteurs et aux vendeurs d'échanger des actifs RGB++. Dans un tel cas, les acheteurs peuvent transférer leurs bitcoins aux vendeurs et recevoir des actifs RGB++ avec leurs comptes Cardano.

Tout au long du processus, les données des actifs RGB++ sont toujours enregistrées dans des cellules qui sont transférées à l'acheteur et leurs autorisations de déverrouillage passent de la clé privée Bitcoin du vendeur à la clé privée Cardano de l'acheteur.

Emballage

Bien que la fonction Leap soit parfaite pour les ressources RGB++, il existe encore quelques goulots d'étranglement :

Pour Bitcoin et Cardano, les actifs RGB++ sont essentiellement des inscriptions/runes/pièces colorées basées sur l'opcode OP_RETURN. Les nœuds de ces chaînes publiques ne peuvent pas percevoir l’existence d’actifs RGB++, puisque CKB participe à la coordination en tant qu’indexeur. En d’autres termes, pour Bitcoin et Cardano, la couche RGB++ prend principalement en charge le saut d’inscriptions/runes/pièces colorées, plutôt que la chaîne croisée d’actifs natifs comme BTC et ADA.

En guise de remède, la couche RGB++ a introduit Wrapper, un pont basé sur des preuves de fraude et de sur-garantie. En prenant le wrapper rBTC comme exemple, il relie BTC à la couche RGB++. Un ensemble de contrats intelligents exécutés sur la couche RGB++ surveille les gardiens du pont. Si les tuteurs agissent de manière malveillante, leurs garanties seront réduites. S’ils s’entendent pour voler des BTC verrouillés, les détenteurs de rBTC recevront une compensation complète.

Avec la combinaison de Leap et Wrapper, divers actifs de l'écosystème BTCFi, par exemple les actifs natifs RGB++, BRC20, ARC20, les runes, etc., peuvent être reliés à d'autres couches ou chaînes publiques.

Le diagramme suivant montre une partie du processus d'utilisation de LeapX. Il prend en charge l’interopérabilité de presque tous les actifs BTCFi traditionnels avec différents écosystèmes. Il existe des flux de traitement correspondants pour les actifs émis de différentes manières, certains utilisant soit des wrappers, soit Leap.

3. CKB-VM : le moteur de contrat intelligent pour BTCFi

En raison du manque de prise en charge des contrats intelligents dans le BTCFi traditionnel, seules des applications décentralisées relativement simples (dApps) peuvent être mises en œuvre dans un espace en évolution. Certaines méthodes de mise en œuvre peuvent comporter certains risques de centralisation, tandis que d'autres sont plutôt maladroites ou peu flexibles.

Pour disposer d'une couche de contrat intelligent disponible sur la blockchain, CKB a introduit la CKB-VM via la couche RGB++. Il vise à permettre à tout langage de programmation prenant en charge la machine virtuelle RISC-V d'être utilisé pour le développement sous contrat sur la couche RGB++. Il permet aux développeurs d'utiliser leurs outils et langages préférés pour développer et déployer des contrats intelligents efficaces et sécurisés dans un cadre de contrat intelligent et un environnement d'exécution unifiés.

Généralement, les conditions d'entrée pour le développement de contrats intelligents par les développeurs avec RISC-V sont relativement faibles en raison de sa prise en charge étendue du langage et du compilateur. Bien entendu, le langage n’est qu’un aspect de la programmation, et l’apprentissage de cadres de contrats intelligents spécifiques est inévitable. Cependant, avec la couche RGB++, la logique peut être facilement réécrite en JavaScript, Rust, Go, Java et Ruby, plutôt que d'apprendre un langage DSL spécifique pour rédiger des contrats.

Le diagramme ci-dessous montre une méthode de transfert de jetons définis par l'utilisateur (UDT) avec CKB en utilisant le langage C. Outre les différentes langues, sa logique de base est la même pour les jetons généraux.

4. Écosystème AA natif : connecter de manière transparente BTC et RGB++

Enfin, étant donné que BTCFi doit essentiellement fournir diverses expériences DeFi pour les actifs Bitcoin natifs, la compréhension de l'écosystème d'abstraction de compte derrière la couche RGB++ ainsi que ses portefeuilles Bitcoin traditionnels est un facteur important à prendre en compte par les installations périphériques BTCFi.

RGB++ Layer réutilise directement la solution AA native de CKB, qui est compatible avec les principales chaînes publiques UTXO comme BTC et Cardano tant du côté développeur que côté utilisateur. Avec la couche RGB++, différents algorithmes de signature peuvent être utilisés pour l'authentification. Autrement dit, les utilisateurs peuvent manipuler directement les actifs sur la couche RGB++ à l'aide de comptes, de portefeuilles ou de méthodes d'authentification BTC, Cardano ou même WebAuthn.

Un exemple est le middleware de portefeuille, CCC, qui peut fournir l'opérabilité de diverses chaînes publiques à CKB pour les portefeuilles et les dApps. L'image suivante montre la fenêtre de connexion de CCC et comment elle prend en charge les entrées de portefeuille grand public telles que Unisat et Metamask.

Un autre exemple est la mise en œuvre de WebAuthn avec JoyID, un portefeuille de l'écosystème CKB, qui en est un représentant typique. Les utilisateurs de JoyID peuvent authentifier directement leurs comptes via des méthodes biométriques (telles que les empreintes digitales ou la reconnaissance faciale) pour obtenir une connexion et une gestion des identités transparentes et hautement sécurisées.

On peut dire que la couche RGB++ dispose d'une solution AA native complète, qui peut également s'adapter aux normes de compte d'autres chaînes publiques. Cette fonctionnalité facilite non seulement la prise en charge de certains scénarios clés, mais élimine également les obstacles pour les UX.

Résumé

Cet article a présenté les technologies de base de la couche RGB++ sans expliquer plusieurs détails complexes.

Il souligne que la couche RGB++ peut constituer une infrastructure importante pour réaliser des scénarios d’interaction en chaîne complète, y compris pour diverses pièces mèmes et inscriptions/runes/pièces colorées. L'environnement d'exécution de contrats intelligents basé sur RISC-V de la couche peut également aider à créer le terrain nécessaire au développement de la logique métier complexe requise par BTCFi.

Au fur et à mesure que la couche RGB++ progresse, une analyse plus approfondie de la série de solutions techniques liées au projet sera fournie. S'il vous plaît restez à l'écoute!