De RGB à RGB++, redécouvrons le potentiel de CKB en tant que couche 2 de Bitcoin et couche de règlement hors chaîne
TechFlow SélectionTechFlow Sélection
De RGB à RGB++, redécouvrons le potentiel de CKB en tant que couche 2 de Bitcoin et couche de règlement hors chaîne
RGB++ consiste essentiellement à échanger de la confidentialité contre une meilleure convivialité, tout en permettant des scénarios impossibles à réaliser avec le protocole RGB.
Dédié à des analyses Web3 approfondiesRédaction : Shew, Faust, Geek web3
Conseiller : CyberOrange, Unipass
Résumé (long) : Le protocole RGB est un protocole d'extension prometteur pour BTC. Il s'agit fondamentalement d'un système de calcul hors chaîne qui adopte une logique similaire à celle du réseau Lightning : chaque utilisateur vérifie et autorise personnellement les modifications liées à ses actifs (Verify by yourself), puis soumet le résultat ou l’engagement validé par l’initiateur de la transaction sur la blockchain Bitcoin.
-
Le protocole RGB reprend certaines idées proches des « colored coins » et de Mastercoin, en associant des « actifs parasites » aux UTXO Bitcoin. Il stocke sur la chaîne Bitcoin un « commitment » (preuve cryptographique) des données de transactions hors chaîne, plutôt que de publier intégralement les données comme le fait le protocole Ordinals. À partir de ce commitment inscrit sur Bitcoin, les clients RGB peuvent vérifier si les historiques RGB fournis par d'autres clients sont valides.
-
En outre, seul le hash ou le commitment ne permet pas de retrouver les données initiales. Les tiers ne peuvent donc pas observer directement les données hors chaîne correspondant aux commitments, préservant ainsi la confidentialité. Comparé aux inscriptions, le simple stockage du commitment sur chaîne économise également de l’espace. D’un point de vue externe, on ignore complètement ce que font réellement les clients RGB.
-
RGB exploite aussi la caractéristique des UTXO Bitcoin, qui ne peuvent être dépensés qu’une seule fois, via un mécanisme appelé « one-time seal » (scellement unique). Ce dernier lie la propriété d’un actif RGB à un UTXO Bitcoin. Ainsi, RGB bénéficie de la sécurité robuste de Bitcoin, évitant toute double dépense des actifs RGB (tant que l’UTXO Bitcoin n’est pas doublé, l’actif RGB ne peut pas l’être non plus).
-
Cependant, en tant que système de contrats intelligents opérant hors chaîne sur Bitcoin, RGB dépend de clients locaux stockant chacun leurs propres données historiques. Chaque client (utilisateur) conserve uniquement les données qui le concernent et n’a aucune visibilité sur les actifs des autres. Ce phénomène d’« îlots de données » protège certes la vie privée, mais pose problème en cas d’adoption massive, rendant RGB plus proche d’un réseau pair-à-pair composé d’échanges OTC.
-
L’approche RGB++ consiste à utiliser les Cellules (Cells) de la blockchain CKB pour représenter les relations de propriété des actifs RGB. Elle transfère les données d’actifs auparavant stockées localement dans les clients RGB vers la chaîne CKB, sous forme de Cells, établissant une relation d’association 1:1 entre ces Cells et les UTXO Bitcoin. CKB devient alors une base de données publique et une couche de pré-règlement hors chaîne pour les actifs RGB, remplaçant les clients RGB individuels et assurant une gestion de données plus fiable ainsi qu’une interaction plus fluide avec les contrats RGB. Cette « liaison isomorphe » constitue une tendance pour d’autres solutions Layer2 basées sur le modèle UTXO.
-
Le protocole RGB ne prend en charge que des flux de transfert interactifs, nécessitant des communications fréquentes entre les deux parties. Ce modèle convient mal aux scénarios DeFi et complique l’émission d’actifs RGB. En remplaçant les clients indépendants par CKB, il devient possible d’effectuer des transactions RGB non interactives, facilitant ainsi le déploiement de fonctionnalités DeFi, de distributions airdrop, et permettant aux actifs BTC d’interagir directement avec les actifs présents sur CKB sans pont跨链.
-
RGB++ repose essentiellement sur un compromis entre confidentialité et convivialité, tout en ouvrant des cas d’usage impossibles avec le protocole RGB classique. Si l’utilisateur privilégie la simplicité d’utilisation et la complétude fonctionnelle, il optera pour RGB++. S’il valorise davantage la confidentialité et la sécurité « Verify by yourself », il préférera le protocole RGB traditionnel. Le choix dépend entièrement de l’utilisateur (en théorie, la confidentialité pourrait être restaurée dans RGB++ grâce à des méthodes comme le ZK).
Principe du protocole RGB et ses avantages/inconvénients
Le protocole RGB est une solution relativement complexe. Nous allons expliquer son fonctionnement à travers un exemple concret de transfert d’un actif RGB.
Supposons qu’il existe un jeton nommé TEST conforme au protocole RGB. Alice souhaite que Bob lui transfère 100 jetons TEST, autrement dit, générer une transaction de transfert Bob → Alice.
Précisons d’abord que RGB utilise une approche appelée « one-time seal ». Bien qu’on parle de Bob transférant à Alice, cela signifie en réalité que Bob contrôle un UTXO A sur la chaîne Bitcoin, et cet UTXO A est lié à certains actifs RGB.
Si Bob déclare vouloir transférer une partie des actifs RGB associés à l’UTXO A à Alice, il peut formuler cette déclaration ainsi : transférer 30 jetons TEST liés à l’UTXO A pour qu’ils soient désormais associés à l’UTXO B. Puisque Alice est propriétaire de l’UTXO B, elle obtient alors la propriété des 30 jetons TEST.
(Source : Discoco Labs)
Sur la chaîne Bitcoin, la propriété est toujours enregistrée via les UTXO. Affirmer qu’un UTXO B a le droit de contrôler un certain montant d’actifs RGB revient à dire que le propriétaire de l’UTXO B peut contrôler ce montant — une particularité propre aux blockchains UTXO comme Bitcoin, différente du modèle habituel basé sur les adresses de compte.
Ayant compris ce point, examinons maintenant le flux de travail de RGB afin de mieux percevoir ses différences avec les anciens systèmes d’actifs parasitaires sur UTXO Bitcoin tels que les colored coins ou Mastercoin :
1. Selon le principe de RGB, Alice doit d’abord émettre une facture (invoice) précisant son intention. Cette facture contient les informations suivantes :
-
ID du contrat : Alice indique avec quel contrat d’actif RGB elle souhaite interagir
-
Interface : permet à Bob de connaître toutes les interfaces disponibles du contrat
-
Opération : nom de l’interface du contrat que Bob doit appeler
-
État : état du contrat que Bob doit modifier — ici, le nombre de jetons à transférer à Alice
-
Scellé (Seal) : UTXO utilisé pour le scellement unique, qu’on peut simplifier comme l’UTXO d’Alice destiné à recevoir l’autorisation d’actif RGB de Bob.
Finalement, Alice obtient une facture ayant la forme suivante :
Cette facture suit le format suivant :
2. Alice doit envoyer cette facture à Bob. Bob vérifie les informations, puis génère selon l’intention d’Alice une nouvelle transaction RGB pour transférer les actifs à Alice.
Mais attention : Bob doit prouver qu’il possède bien une partie des actifs TEST. Pourquoi ? Parce que RGB suppose par défaut « l’absence d’enregistrement global visible de l’état des actifs », contrairement à Ethereum où un contrat public centralisé gère et enregistre tous les actifs.
Sous RGB, chaque client n’enregistre que les données liées à ses propres actifs (soldes actuels, historique d’origine, etc.), et les données conservées par chaque client sont généralement différentes. Personne ne peut donc confirmer l’état des actifs d’autrui, d’où la nécessité de fournir une preuve lors d’un échange pair-à-pair.
Une analogie parlante : vous effectuez une transaction en espèces, mais vous ignorez si les billets de votre interlocuteur sont de faux imprimés par lui-même. Vous exigez alors qu’il vous explique clairement d’où viennent ces billets, par quels intermédiaires ils sont passés, pour juger s’il tente de vous tromper.
Une fois que les deux parties se reconnaissent mutuellement, elles peuvent procéder en toute confiance. Chaque transaction RGB nécessite uniquement l’accord des participants, c’est un échange purement P2P (similaire à un OTC).
Évidemment, ce modèle protège la vie privée : l’état des actifs et les historiques de transaction de chacun restent inaccessibles au monde extérieur. Ce que vous faites avec votre contrepartie reste confidentiel. Comme les espèces permettent un meilleur anonymat que les virements bancaires. Toutefois, cela nuit à l’expérience utilisateur.
Dans notre exemple Alice/Bob, après avoir reçu la facture d’Alice et compris son intention, Bob doit extraire depuis ses données locales historiques celles relatives aux actifs TEST, puis les transmettre conjointement à la nouvelle transaction Bob → Alice, afin qu’Alice puisse les vérifier. Cela prouve que le nouveau transfert RGB / changement de propriété repose sur une source valide.
Généralement, les données locales stockées par le client sont appelées « Stash » (collection), contenant l’historique des actifs RGB. On peut assimiler le Stash au journal d’un contrat d’actif RGB.
3. Une fois qu’Alice reçoit les données de Bob ainsi que la nouvelle transaction Bob → Alice, elle en vérifie la validité. Si la vérification réussit, Alice génère une « signature de confirmation » qu’elle renvoie à Bob.
4. Après avoir reçu la signature de confirmation d’Alice, Bob diffuse le commitment (engagement) correspondant à la transaction Bob → Alice sur le réseau BTC, qui sera finalement inscrit sur la chaîne BTC, lui conférant une « finalité ».
(Schéma du commitment, dont la structure est essentiellement une racine Merkle)
Si la transaction Bob → Alice déclare que le propriétaire de l’UTXO B aura 30 jetons TEST, alors Alice, en prouvant qu’elle est bien propriétaire de l’UTXO B, peut utiliser ces jetons.
5. Si, à l’avenir, Alice veut transférer ses jetons TEST à un tiers, ce dernier pourra vérifier l’historique fourni par Alice en le comparant au commitment enregistré sur la chaîne Bitcoin. Cela empêche toute falsification de données.
L’avantage de RGB est de permettre des calculs complexes de contrats intelligents hors chaîne. Il déplace essentiellement le calcul hors de la chaîne BTC, n’y enregistrant que le commitment, protégeant la confidentialité tout en déclarant hors chaîne l’association entre les UTXO Bitcoin et la propriété des actifs RGB, utilisant Bitcoin pour graver et réaliser les changements de propriété des actifs RGB.
Puisque toutes les déclarations de transaction doivent être vérifiées et autorisées par les parties concernées, le modèle de sécurité repose sur l’hypothèse d’agents rationnels : tant que les utilisateurs sont raisonnables et que Bitcoin est sécurisé, la propriété des actifs RGB est « fondamentalement sûre ».
Toutefois, les défauts de RGB sont évidents (problèmes d’îlots de données et de stockage fragmenté mentionnés précédemment). Premièrement, pour transférer à autrui, il faut souvent obtenir au préalable l’accord et la confirmation de l’autre partie, impliquant que les deux parties soient presque simultanément en ligne ;
Deuxièmement, faute d’un enregistrement global visible, la publication de contrats RGB adopte même des formes très inhabituelles : les utilisateurs doivent au préalable obtenir auprès de l’émetteur du contrat la liste des interfaces disponibles. La méthode concrète peut passer par email ou par scan de QR code. (Selon les propos actuels de l’équipe, afficher le code sur le site officiel ou en tête de compte Twitter pourrait aussi convenir.)
Examinons maintenant l’état des contrats dans RGB. L’état initial (Genesis) d’un contrat RGB est défini dès sa création par son créateur (nom du jeton, offre totale, etc., dans un contrat RGB-20). Ensuite, l’état du contrat évolue avec les transactions RGB successives, mais cette évolution est non linéaire, formant un graphe acyclique orienté (DAG).
(La zone visible du owner1 est en bleu et vert, celle du Owner2 en bleu et jaune)
Par exemple, lorsque Bob transfère à Alice, il ne présente que l’historique partiel allant de l’initialisation du contrat jusqu’à l’obtention des jetons par Bob, un chemin de données assez étroit. Alice ne peut alors connaître que les informations de cette branche spécifique, ignorant les transferts des autres. Cela protège la vie privée des utilisateurs RGB, mais entraîne un inconvénient majeur : les utilisateurs ont du mal à connaître l’état global du contrat RGB, comme la quantité d’actifs RGB détenue par chacun. Cela crée de nombreux problèmes.
Par exemple, une fois la dernière étape du transfert Bob → Alice atteinte, et que le commitment est gravé sur la chaîne BTC de façon irréversible, Bob peut supprimer localement certaines données — s’il a donné tous ses jetons TEST, il peut directement effacer les données locales associées pour réduire la pression de stockage.
Quant à Alice, la destinataire, elle doit conserver localement toutes les données liées à cette transaction. (Si Bob supprime ses données locales et que le nœud client d’Alice subit une panne totale, les actifs d’Alice ne risquent-ils pas d’être définitivement gelés ? Car aucune autre copie des données n’existe, sauf sauvegarde préalable.)
Cela revient fondamentalement à un problème de disponibilité des données (DA) et de stockage : les nouvelles données RGB ne peuvent pas être diffusées de manière fiable et globalement visible, transformant les différents clients en « îlots de données ». Le schéma Plasma, jadis populaire dans l’écosystème Ethereum mais abandonné ensuite, a également échoué en raison de l’impossibilité de résoudre le problème DA.
De plus, le protocole RGB exige de nombreuses communications entre les deux parties, souvent tributaires d’infrastructures centralisées. Les détails techniques restent flous, l’équipe allant jusqu’à suggérer l’usage du courrier électronique.
Il est clair que le design de RGB n’est pas convivial pour les utilisateurs occasionnels. Certes, les gros détenteurs soucieux de confidentialité accepteront de faire des sauvegardes et de maintenir leur client, mais pour la majorité des petits utilisateurs, ces contraintes restent trop lourdes, freinant fortement une adoption à grande échelle. À ce jour, personne n’a vu émerger d’actif RGB véritablement phénoménal.
Le schéma ci-dessous illustre le flux de transfert d’un actif RGB, aidant le lecteur à mieux comprendre l’ensemble du processus.
En résumé, RGB utilise les UTXO Bitcoin pour modifier la propriété des actifs RGB, et garantit via la publication de commitments sur la chaîne BTC que les données hors chaîne ne puissent être falsifiées par les clients. En réalité, le « one-time seal » de RGB consiste à lier via une déclaration de transaction hors chaîne un UTXO Bitcoin à la propriété d’un actif RGB, s’appuyant ainsi sur la sécurité puissante de Bitcoin pour protéger les actifs RGB. Toutefois, en raison des problèmes de DA et de stockage, l’ergonomie et l’expérience utilisateur du protocole RGB original sont médiocres, et les actifs risquent d’être gelés (rendus inutilisables) en cas de perte de données.
RGB++ : une version améliorée de RGB basée sur CKB
Dans la section précédente, nous avons résumé les forces et faiblesses du système RGB. Parmi celles-ci, les îlots de données clients et l’absence de visibilité globale de l’état du contrat constituent les principaux freins à l’ergonomie de RGB.
En effet, les avantages et inconvénients de RGB sont marqués. Ceux qui accordent une haute importance à la confidentialité et à la sécurité préféreront exécuter eux-mêmes un client et faire des sauvegardes, mais les utilisateurs occasionnels n’ont manifestement pas cette patience (la plupart des utilisateurs du réseau Lightning dépendent de nœuds tiers plutôt que d’exécuter leurs propres clients).
C’est pourquoi Cipher, cofondateur de Nervos, a proposé RGB++, un schéma visant à déléguer à la blockchain publique CKB la gestion de l’état des actifs RGB, la publication des contrats et la validation des transactions. CKB agit comme une plateforme tierce de stockage de données et de calcul, supprimant la nécessité pour l’utilisateur d’exécuter un client RGB local.
CKB, reposant sur un modèle UTXO étendu (Cell), permet d’enregistrer les informations hors chaîne de RGB dans des Cells, et d’établir une relation d’association 1:1 entre ces Cells et les UTXO Bitcoin. Cela permet une solution de stockage et de vérification des données RGB basée sur CKB, résolvant ainsi les problèmes d’ergonomie, en tant que complément renforcé du schéma RGB d’origine.
Ce passage peut sembler complexe. Développons davantage :
Comme mentionné plus haut, RGB associe via un engagement sur chaîne et des déclarations hors chaîne les UTXO Bitcoin à la propriété des actifs RGB. Mais les données du contrat d’actif RGB sont fragmentées et stockées localement sur différents clients, sans vue globale disponible.
RGB++ utilise l’UTXO étendu de CKB — la Cellule — pour exposer directement sur la chaîne CKB la relation d’association entre les UTXO Bitcoin et les actifs RGB correspondants, et fait en sorte que la blockchain CKB remplace les clients P2P des utilisateurs pour valider l’efficacité de chaque transfert RGB.
Avec un tel enregistrement public des données RGB, de nombreux cas d’usage auparavant impossibles sous RGB deviennent réalisables.
(Flux de transaction RGB++ : enregistrer les informations d’actifs RGB dans une Cell, associer cette Cell à un UTXO Bitcoin, puis inclure dans un engagement à la fois la transaction RGB++ sur CKB et l’UTXO Bitcoin associé aux actifs RGB++, avant d’inscrire cet engagement sur la chaîne Bitcoin)
Certains penseront immédiatement à l’EVM. Peut-on utiliser l’EVM pour porter l’état et la validation RGB ? Réponse : c’est très compliqué, car les actifs RGB sont fondamentalement parasitaires des UTXO Bitcoin, avec une relation d’association 1:1. Établir un lien entre les UTXO Bitcoin et les données de contrat EVM serait techniquement malaisé, alors qu’une blockchain UTXO conviendrait mieux directement.
De plus, les « actifs » sur Ethereum sont souvent des biens publics mutualisés (point-to-pool), un contrat centralisant les données de milliers d’utilisateurs, donnant un pouvoir absolu au contrôleur. Cette logique de gestion des actifs entre en conflit profond avec Bitcoin UTXO et RGB, dont la philosophie vise une pleine propriété privée — chacun contrôle totalement ses actifs (comme les espèces vs WeChat Pay), évitant ainsi les problèmes typiques des chaînes EVM : abus de pouvoir par le propriétaire du contrat, bogues entraînant des pertes, difficulté de migration des données du contrat, etc.
(Extrait d’un article précédent de Geek web3 : « Ma Jiang, personnalité du cercle tech : les blockchains hautes performances peinent à innover, les contrats intelligents impliquent une redistribution du pouvoir »)
Par conséquent, pour exprimer harmonieusement la relation d’association entre les UTXO Bitcoin et les actifs RGB hors chaîne, le meilleur choix reste une chaîne UTXO. CKB supporte un UTXO étendu — la Cell — et sa machine virtuelle CKB VM utilise un jeu d’instructions RISC-V, plus facile à compatibiliser avec divers algorithmes cryptographiques, y compris ceux de vérification des clés publiques/privées Bitcoin, rendant ainsi la mise en œuvre technique de RGB++ plus aisée.
Implémentation technique de RGB++
RGB++ utilise l’UTXO étendu de CKB — la Cell. Une Cell contient les champs suivants :
Capacity indique la taille de l’espace chaîne de la Cell, data désigne les données contenues dans la Cell, pouvant être lues ou modifiées.
Type correspond au code programme attaché à la Cell, limitant les conditions de modification des données. Par exemple, si votre Cell contient 100 jetons TEST, mais que vous déclarez transférer 110 jetons, cela violera les règles définies dans Type et sera rejeté.
Lock représente la logique de vérification de propriété de la Cell, analogue au script de déblocage d’un UTXO Bitcoin.
On peut considérer la Cell comme une version améliorée de l’UTXO, dotée des champs Type et Capacity supplémentaires, et permettant de personnaliser le type de données dans data. Le mécanisme de changement de propriété d’une Cell suit celui des UTXO Bitcoin, via des scripts de déblocage.
RGB++ propose donc d’utiliser les Cells de CKB pour exprimer les relations de propriété des actifs RGB. Il transfère les données d’actifs auparavant stockées localement dans les clients RGB vers la chaîne CKB sous forme de Cells, faisant de CKB une base de données publique pour les actifs RGB. Ces Cells représentant les actifs RGB entretiennent une relation d’association 1:1 avec les UTXO Bitcoin, relation explicitement indiquée dans le champ Lock de la Cell.
Par exemple, si un actif RGB est lié à l’UTXO Bitcoin A, la Cell correspondante peut définir sa condition de vérification de propriété identique à celle de l’UTXO A (c’est-à-dire configurer le script Lock selon les conditions de déblocage de l’UTXO A). Si vous contrôlez l’UTXO A, vous pouvez directement manipuler la Cell miroir sur CKB, bien entendu, CKB vérifiera que vous êtes bien le propriétaire de l’UTXO A.
CKB implémente un nœud léger Bitcoin synchronisant les en-têtes de blocs Bitcoin. Lorsque vous déclarez une transaction RGB et souhaitez modifier la Cell associée, vous devez d’abord prouver que vous contrôlez bien l’UTXO Bitcoin A. La preuve comporte deux étapes :
-
Prouver auprès du nœud léger Bitcoin sur CKB que l’UTXO A existe bien sur la chaîne Bitcoin, en fournissant une preuve Merkle ;
-
Fournir une signature numérique prouvant que vous êtes bien le propriétaire de l’UTXO A.
Dans RGB++, après qu’un utilisateur déclare un transfert d’actif RGB via l’interface, une transaction est déclenchée sur CKB, modifiant la Cell contenant les données de l’actif RGB et changeant sa propriété. Initialement, la Cell appartenait peut-être au contrôleur de l’UTXO Bitcoin 1 ; après changement, le contrôleur de l’UTXO Bitcoin 2 devient le nouveau propriétaire. Tout cela est visible publiquement sur CKB.
Notez que les workflows liés aux engagements sur la chaîne BTC continuent de s’exécuter sur le réseau principal Bitcoin. Autrement dit, RGB++ doit toujours publier un commitment sur la chaîne Bitcoin, lié aux enregistrements de transactions RGB++ sur CKB. Cette étape ne diffère pas du protocole RGB traditionnel.
La différence réside dans le fait que les tâches autrefois assumées localement par les clients dans RGB (vérification de la provenance des actifs par la contrepartie, stockage local des historiques, publication de contrats via canaux externes, etc.) sont désormais prises en charge par CKB, supprimant ainsi la nécessité pour l’utilisateur d’exécuter un client local.
Cela résout à la fois le problème des îlots de données clients et l’absence d’état global visible. En outre, les contrats RGB peuvent être directement déployés sur CKB, visibles publiquement, et référencés par les Cells RGB, évitant ainsi les opérations inhabituelles liées à la publication de contrats sous RGB.
En résumé
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@godrealmx
