Avec la popularité croissante de RGB++ et l'émission d'actifs connexes, les discussions sur les principes des protocoles RGB et RGB++ sont progressivement devenues un sujet d'intérêt pour un plus grand nombre de personnes. Cependant, il est réalisé que pour comprendre RGB++, il faut d'abord saisir le protocole RGB. Le protocole RGB original est quelque peu technique dans sa structure, avec des matériaux de référence dispersés, et il n'y a pas eu beaucoup de matériel de référence systématique et facilement compréhensible jusqu'à présent. Geek Web3 a précédemment publié deux interprétations systématiques de RGB et RGB++ (disponibles dans l'historique de notre compte public), mais selon les retours de la communauté, ces articles étaient longs et trop complexes. Afin de permettre à un plus grand nombre de personnes de comprendre rapidement les protocoles RGB et RGB++, l'auteur de cet article a hâtivement réalisé une brève interprétation pour les non-initiés de RGB et RGB++ lors d'un événement à Hong Kong. Il peut être lu en quelques minutes seulement, dans le but d'aider davantage d'enthousiastes de la communauté à mieux comprendre de manière plus intuitive RGB et RGB++.

Protocole RGB : Les utilisateurs doivent vérifier personnellement les données

Le protocole RGB est un type spécial de protocole d'actifs P2P, fonctionnant sous le système informatique de la chaîne Bitcoin. À certains égards, il est similaire aux canaux de paiement : les utilisateurs doivent exécuter leur client personnellement et vérifier les actions de transfert qui leur sont liées ("Vérifiez par vous-même"). Même si vous n'êtes que le destinataire des actifs, vous devez d'abord confirmer que l'énoncé de transfert de l'expéditeur est correct avant que le transfert puisse prendre effet. Cette approche, connue sous le nom de "transfert interactif", est nettement différente des méthodes traditionnelles de transfert et de réception d'actifs. Pourquoi est-ce nécessaire? La raison en est que le protocole RGB, afin de protéger la confidentialité, n'utilise pas le "protocole de consensus" que l'on trouve dans les blockchains traditionnelles comme Bitcoin et Ethereum (où les données, une fois dans le protocole de consensus, sont observées par presque tous les nœuds du réseau, rendant la confidentialité difficile à protéger). Sans un processus de consensus impliquant un grand nombre de nœuds, comment garantir que les changements d'actifs sont sûrs? C'est là que l'idée de "vérification par le client" ("Vérifiez par vous-même") entre en jeu. Vous devez exécuter votre client et vérifier personnellement les changements d'actifs qui vous concernent.

Par exemple, considérons un utilisateur RGB nommé Bob qui connaît Alice. Alice souhaite transférer 100 jetons TEST à Bob. Après avoir généré les informations de transfert “Alice vers Bob”, Alice envoie les informations de transfert et les données d'actifs associées à Bob pour qu'il vérifie personnellement. Ce n'est que lorsque Bob confirme que tout est correct que le transfert devient un transfert RGB valide. Ainsi, le protocole RGB demande aux utilisateurs de vérifier eux-mêmes la validité des données, remplaçant les algorithmes de consensus traditionnels. Cependant, sans consensus, les données reçues et stockées par différents clients RGB sont incohérentes. Chacun ne stocke localement que les données d'actifs qui les concernent et ne connaît pas les statuts d'actifs des autres. Bien que cela protège la vie privée, cela crée également des “îlots de données”. Si quelqu'un prétend avoir 1 million de jetons TEST et veut vous en transférer 100 000, comment leur faire confiance ? Dans le réseau RGB, si quelqu'un veut vous transférer des actifs, il doit d'abord fournir une preuve des actifs, retracer l'historique des actifs depuis leur émission initiale jusqu'à plusieurs transferts, en veillant à ce que les jetons qu'il souhaite vous transférer soient légitimes. C'est comme lorsque vous recevez des billets de banque non expliqués, vous demandez à l'expéditeur d'expliquer l'historique de ces billets, s'ils ont été émis par l'émetteur désigné, pour éviter les faux billets.

(Source de l'image: Coinex)

Le processus ci-dessus se déroule sous la chaîne Bitcoin, et ces étapes seules n'établissent pas de connexion directe entre RGB et le réseau Bitcoin. Pour remédier à cela, le protocole RGB utilise le concept de "scellés à usage unique," qui lient les actifs RGB aux UTXO (Unspent Transaction Outputs) sur la chaîne Bitcoin. Tant que l'UTXO Bitcoin n'est pas double-dépensé, les actifs RGB liés ne seront pas soumis à un double paiement, exploitant ainsi le réseau Bitcoin pour prévenir la "Réorganisation" des actifs RGB. Bien sûr, cela nécessite la publication des engagements sur la chaîne Bitcoin et l'utilisation de l'opcode OP_Return.

Dressons le workflow du protocole RGB :

1. Les actifs RGB sont liés aux UTXO Bitcoin, et Bob possède certains UTXO Bitcoin. Alice souhaite transférer 100 jetons à Bob. Avant de recevoir les actifs, Bob informe Alice de quel UTXO Bitcoin le sien devrait être utilisé pour lier ces actifs RGB.

(Source de l'image : Geekweb3/GeekWeb3)

1. Alice construit les données de transaction pour le transfert d'actifs RGB "Alice à Bob", ainsi que l'historique de ces actifs, et les donne à Bob pour vérification.
2. Après que Bob a confirmé que les données sont correctes localement, il envoie un reçu à Alice, l'informant que la transaction peut se poursuivre.
3. Alice construit les données de transfert RGB "Alice à Bob" dans un arbre de Merkle et publie la racine de Merkle sur la chaîne Bitcoin en tant qu'Engagement. Nous pouvons simplement comprendre l'Engagement comme le hachage des données de transfert.
4. Si quelqu'un souhaite confirmer à l'avenir que le transfert de « Alice à Bob » a effectivement eu lieu, il doit faire deux choses : obtenir les informations complètes sur le transfert de « Alice à Bob » sous la chaîne Bitcoin, puis vérifier si l'engagement correspondant (le hachage des données de transfert) existe sur la chaîne Bitcoin.

Bitcoin sert de journal historique pour le réseau RGB, mais le journal ne enregistre que le hash/Merkle root des données de transaction, pas les données de transaction elles-mêmes. En raison de l'adoption de la vérification côté client et des scellés à usage unique, le protocole RGB offre une sécurité extrêmement élevée. Comme le réseau RGB est composé de clients utilisateurs dynamiques de manière peer-to-peer, sans consensus, vous pouvez changer de contreparties de transaction à tout moment sans avoir besoin d'envoyer des demandes de transaction à un nombre limité de nœuds. Par conséquent, le réseau RGB présente une forte résistance à la censure. Cette structure organisationnelle le rend plus résistant à la censure par rapport aux chaînes publiques à grande échelle comme Ethereum.

(Source de l'image : BTCEden.org)

Certes, la haute sécurité, la résistance à la censure et la protection de la vie privée apportées par le protocole RGB s'accompagnent également de coûts significatifs. Les utilisateurs doivent exécuter leur client pour vérifier les données. Si quelqu'un vous envoie des actifs avec un long historique de transactions impliquant des milliers de transferts, vous devrez les vérifier tous, ce qui peut être assez contraignant.

De plus, chaque transaction nécessite de multiples communications entre les parties. Le destinataire doit vérifier la source d'actif de l'expéditeur, puis envoyer un reçu pour approuver la demande de transfert de l'expéditeur. Ce processus implique au moins trois échanges de messages entre les parties. Ce « transfert interactif » est très différent du « transfert non interactif » auquel la plupart des gens sont habitués. Imaginez quelqu'un ayant besoin de vous envoyer de l'argent et devant vous envoyer les données de la transaction pour votre inspection, en attendant votre message de réception avant de finaliser le processus de transfert.

De plus, comme mentionné précédemment, le réseau RGB manque de consensus et chaque client fonctionne de manière isolée, ce qui rend difficile la migration de scénarios de contrats intelligents complexes des chaînes publiques traditionnelles vers le réseau RGB. Cela s'explique par le fait que les protocoles DeFi sur Ethereum ou Solana reposent sur des grands registres visibles et transparents à l'échelle mondiale. Comment optimiser le protocole RGB, améliorer l'expérience utilisateur et relever ces défis devient un problème inévitable pour le protocole RGB.

RGB++ Introduit une approche de garde optimiste, remplaçant la vérification côté client.

Le protocole appelé RGB++ introduit une nouvelle approche en combinant le protocole RGB avec des chaînes publiques prises en charge par UTXO telles que CKB, Cardano et Fuel. Dans cette configuration, ce dernier sert de couche de validation et de stockage de données pour les actifs RGB, transférant les tâches de vérification des données initialement effectuées par les utilisateurs vers des plates-formes/chaînes tierces telles que CKB. Cela remplace efficacement la vérification côté client par une « vérification de plateforme décentralisée tierce ». Tant que vous faites confiance à des plates-formes/chaînes comme CKB, Cardano ou Fuel, vous êtes prêt à partir. Si vous ne leur faites pas confiance, vous pouvez toujours revenir au mode RGB traditionnel.

RGB++ et le protocole RGB original sont théoriquement compatibles entre eux; ce n'est pas un cas de l'un ou de l'autre, mais plutôt ils peuvent coexister.

Pour obtenir l'effet mentionné, nous devons exploiter un concept appelé "liaisons homomorphes". Les chaînes publiques telles que CKB et Cardano ont leurs propres modèles UTXO étendus, offrant plus de programmabilité par rapport aux UTXO sur la chaîne Bitcoin. La "liaison homomorphe" consiste à utiliser les UTXO étendus sur des chaînes telles que CKB, Cardano et Fuel comme "conteneurs" pour les données d'actifs RGB. Les paramètres des actifs RGB sont écrits dans ces conteneurs et affichés directement sur la blockchain. Chaque fois qu'une transaction d'actif RGB se produit, le conteneur d'actif correspondant peut également présenter des caractéristiques similaires, semblables à la relation entre les entités et les ombres. C'est l'essence de la "liaison homomorphe".

(Source de l'image : RGB++ LightPaper)

Par exemple, si Alice possède 100 jetons RVB et un UTXO (appelons-le UTXO A) sur la chaîne Bitcoin, ainsi qu’un UTXO sur la chaîne CKB marqué avec « RVB Token Balance : 100 » et des conditions déverrouillées associées à UTXO A :

Si Alice veut envoyer 30 jetons à Bob, elle peut d'abord générer un engagement avec l'énoncé correspondant : transférer 30 jetons RGB associés à UTXO A à Bob et transférer 70 jetons à un autre UTXO contrôlé par elle-même.

Ensuite, Alice dépense l'UTXO A sur la chaîne Bitcoin, publie la déclaration ci-dessus, puis lance une transaction sur la chaîne CKB. Cette transaction consomme le conteneur UTXO contenant 100 jetons RGB, créant deux nouveaux conteneurs : l'un contenant 30 jetons (pour Bob) et un autre contenant 70 jetons (contrôlé par Alice). Au cours de ce processus, la tâche de vérification de la validité des actifs d'Alice et des déclarations de transaction est accomplie par consensus entre les nœuds sur des réseaux tels que CKB ou Cardano, sans l'intervention de Bob. À ce stade, CKB et Cardano agissent respectivement comme la couche de validation et la couche de DA (Disponibilité des données) sous la chaîne Bitcoin.

(Source de l'image : RGB++ LightPaper)

Toutes les données d'actifs RGB des individus sont stockées sur la chaîne CKB ou Cardano, offrant une caractéristique mondialement vérifiable qui facilite la mise en œuvre de scénarios DeFi tels que les pools de liquidité et les protocoles de mise en jeu d'actifs. Bien sûr, l'approche ci-dessus sacrifie également la confidentialité. Il s'agit essentiellement d'un compromis entre la confidentialité et la facilité d'utilisation du produit. Si vous privilégiez la sécurité et la confidentialité maximales, vous pouvez revenir au mode RGB traditionnel. Si ces compromis ne vous dérangent pas, vous pouvez adopter en toute confiance le mode RGB++, en fonction entièrement de vos besoins personnels. (En fait, en tirant parti de la puissante fonctionnalité des chaînes publiques comme CKB et Cardano, des transactions privées peuvent être réalisées grâce à l'utilisation de ZK.)

Il est important de souligner que RGB++ introduit une présomption de confiance significative : les utilisateurs doivent croire de manière optimiste que la chaîne CKB/Cardano ou la plateforme réseau composée d'un grand nombre de nœuds à travers le protocole de consensus est fiable et sans erreur. Si vous ne faites pas confiance à CKB, vous pouvez suivre le processus de communication et de vérification interactif dans le protocole RGB d'origine en exécutant vous-même votre client.

Dans le cadre du protocole RGB++, les utilisateurs peuvent utiliser directement leurs comptes Bitcoin pour faire fonctionner leurs conteneurs d’actifs RVB sur les chaînes CKB/Cardano UTXO sans avoir besoin de transactions inter-chaînes. Il leur suffit de tirer parti des caractéristiques des UTXO dans les chaînes publiques susmentionnées et de définir les conditions de déverrouillage du conteneur Cell pour qu’il soit associé à une adresse Bitcoin/UTXO spécifique. Si les parties impliquées dans les transactions d’actifs RVB font confiance à la sécurité de CKB, elles n’auront peut-être même pas besoin de publier fréquemment des engagements sur la chaîne Bitcoin. Au lieu de cela, ils peuvent agréger et envoyer un engagement à la chaîne Bitcoin après que plusieurs transferts RVB aient eu lieu. C’est ce qu’on appelle la fonction de « pliage de transaction », qui peut réduire les coûts de transaction.

Il est important de noter que les «conteneurs» utilisés dans les liaisons homomorphiques doivent être pris en charge par les chaînes publiques qui utilisent le modèle UTXO ou qui ont des fonctionnalités similaires dans leur infrastructure de stockage d'état. Les chaînes basées sur l'EVM ne sont pas très adaptées à cette fin et peuvent rencontrer de nombreux défis. (Ce sujet pourrait être abordé dans un article séparé, car il implique beaucoup de contenu. Les lecteurs intéressés peuvent se référer aux articles précédents de Geek Web3 intitulés «RGB++ et Homomorphic Liens: Comment CKB, Cardano et Fuel Renforcent l'Écosystème Bitcoin.“)

En résumé, les chaînes publiques ou les couches d'extension de fonctionnalité adaptées à la mise en œuvre de liaisons homomorphes doivent présenter les caractéristiques suivantes :

1. Utilisez le modèle UTXO ou des schémas de stockage d'état similaires.
2. Offrir une programmabilité UTXO suffisante, permettant aux développeurs d'écrire des scripts de déverrouillage.
3. Avoir un espace d'état lié aux UTXO qui peut stocker les états d'actifs.
4. Avoir des ponts ou des nœuds légers liés à Bitcoin disponibles.

Avertissement：

1. Cet article est repris de [极客 Web3], Tous les droits d'auteur appartiennent à l'auteur original [Faust]. Si des objections sont soulevées à cette reproduction, veuillez contacter le Gate Learné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 aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.