Protocole RGB : les utilisateurs doivent effectuer eux-mêmes la vérification des données

Le protocole RVB est un protocole d’actif P2P spécial et un système informatique sous la chaîne Bitcoin. Il est similaire à un canal de paiement à certains égards : les utilisateurs doivent exécuter le client eux-mêmes et vérifier leur propre comportement de transfert (Vérifier par vous-même). Même si vous n’êtes qu’un destinataire de ressource, vous devez d’abord vous assurer qu’il n’y a pas d’erreurs dans la déclaration de transfert de l’expéditeur de la ressource avant que la déclaration de transfert puisse prendre effet. Évidemment, c’est complètement différent de la forme traditionnelle d’envoi et de réception de ressources. C’est ce que nous appelons le « transfert interactif ».

Pourquoi devrait-il en être ainsi ? La raison en est que pour garantir la confidentialité, le protocole RVB n’adopte pas le « protocole de consensus » dans les blockchains traditionnelles telles que Bitcoin et Ethereum. (Une fois que les données passent par le protocole de consensus, elles seront observées par presque tous les nœuds du réseau, et la confidentialité n’est pas garantie). Comment s’assurer que les modifications d’actifs sont sûres sans un processus de consensus impliquant un grand nombre de nœuds ? L’idée appelée « Vérification du client » (Vérifier par vous-même) est utilisée ici. Vous devez gérer le client vous-même et vérifier personnellement les modifications d’actifs qui vous concernent. Supposons qu’il y ait un utilisateur RVB nommé Bob qui connaît Alice, et qu’Alice veuille transférer 100 jetons TEST à Bob. Une fois qu’Alice a généré les informations de transfert de « Alice à Bob », elle doit d’abord envoyer les informations de transfert et les données d’actif impliquées à Bob, et le laisser les vérifier personnellement pour s’assurer qu’elles sont correctes avant d’entrer dans le processus suivant, et enfin cela devient un transfert RVB valide. De cette façon, le protocole RVB permet aux utilisateurs de vérifier personnellement la validité des données, remplaçant ainsi l’algorithme de consensus traditionnel. Mais sans consensus, les données reçues et stockées par les différents clients RVB sont incohérentes. Tout le monde ne stocke que ses propres données d’actifs localement et ne connaît pas l’état des actifs des autres. Tout en protégeant la vie privée, il s’agit également d’un « îlot de données ». Si quelqu’un prétend avoir 1 million de jetons TEST et veut vous en transférer 100 000, comment pouvez-vous le croire ? Dans le réseau RVB, si quelqu’un veut vous transférer de l’argent, il doit d’abord montrer une preuve d’actifs, retracer la source historique des actifs depuis l’émission initiale jusqu’aux multiples changements de mains, et s’assurer que le jeton à vous transférer est propre. C’est comme lorsque vous recevez des billets d’origine inconnue et que vous demandez à l’autre partie d’expliquer l’origine historique de ces billets et s’ils ont été fabriqués par l’émetteur désigné, afin d’éviter la fausse monnaie.

(Source de l'image: Coinex)

Les processus ci-dessus se produisent sous la chaîne Bitcoin, et ces processus seuls ne peuvent pas rendre directement RGB lié au réseau Bitcoin. À cet égard, le protocole RGB adopte une idée appelée "sceau à usage unique" pour lier les actifs RGB à UTXO sur la chaîne Bitcoin. Tant que le Bitcoin UTXO n'est pas double-consommé, les actifs RGB liés ne seront pas double-dépensés. De cette façon, le réseau Bitcoin peut être utilisé pour prévenir la "Réorganisation" des actifs RGB. Bien sûr, cet engagement doit être publié sur la chaîne Bitcoin et l'opcode OP_Return est utilisé.

Voici un résumé du flux de travail du protocole RGB :

1. Les actifs RGB sont liés à Bitcoin UTXO, et Bob possède certains Bitcoin UTXOs. Alice souhaite transférer 100 jetons à Bob. Avant de recevoir les actifs, Bob dit à Alice à l'avance quel Bitcoin UTXO de Bob doit être utilisé pour lier ces actifs RGB.

(Source de l'image: Geekweb3/GeekWeb3)

1. Alice construit des données de transfert d'actifs RGB "Alice à Bob", ainsi que les sources historiques de ces actifs, et les donne à Bob pour vérification.
2. Après que Bob a confirmé localement que les données sont OK, il envoie un reçu à Alice, lui disant que la transaction peut être effectuée.
3. Alice construit les données de transfert RGB de « 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 "Alice vers Bob" mentionné ci-dessus s'est réellement produit, il doit faire deux choses : obtenir les informations complètes sur le transfert "Alice vers Bob" sous la chaîne Bitcoin, puis vérifier s'il existe une transaction correspondante sur la chaîne Bitcoin Commitment (hash des données de transfert), c'est tout.

Ici, Bitcoin agit comme le journal historique du réseau RGB, mais seul le hachage/la racine de Merkle des données de transaction est enregistré dans le journal, au lieu des données de transaction elles-mêmes. Grâce à la validation côté client et à la scellée unique, le protocole RGB bénéficie d'une sécurité extrêmement élevée; Comme le réseau RGB est composé de clients utilisateurs dynamiques sous une forme pair-à-pair et sans consensus, vous pouvez changer la contrepartie à tout moment sans envoyer de demandes de transaction à un nombre limité de nœuds, les réseaux RGB étant extrêmement résistants à la censure, cette forme organisationnelle est plus résistante à la censure que les grandes chaînes publiques telles qu'Ethereum.

(Source de l'image : BTCEden.org)

Bien sûr, une sécurité extrêmement élevée, la résistance à la censure et la protection de la vie privée ont des coûts évidents : les utilisateurs doivent exécuter le client pour vérifier les données eux-mêmes. Si l'autre partie vous envoie des actifs qui ont changé de mains des dizaines de milliers de fois et ont une longue histoire, vous devez tous les vérifier sous pression.

De plus, 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. Au cours de ce processus, au moins trois messages doivent être échangés entre les deux parties. Ce type de « transfert interactif » est en sérieux désaccord avec le « transfert non interactif » auquel la plupart des gens sont habitués.

Pouvez-vous imaginer quelqu'un voulant vous transférer de l'argent, mais devant vous envoyer les données de la transaction pour vérification, et ce n'est qu'après avoir reçu votre message de réception que le processus de transfert peut être complété?

De plus, nous avons mentionné que le réseau RGB n'a pas de consensus et que chaque client est une île, ce qui n'est pas propice à la migration de scénarios de contrats intelligents complexes sur la chaîne publique traditionnelle vers le réseau RGB, car le protocole Defi sur Ethereum ou Solana repose sur un grand livre globalement visible et transparent. Comment optimiser le protocole RGB, améliorer l'expérience utilisateur et résoudre les problèmes ci-dessus? Cela est devenu un problème inévitable pour le protocole RGB.

RGB++: La vérification côté client devient une garde optimiste

Le protocole appelé RGB++ propose une nouvelle idée. Il combine le protocole RGB avec des chaînes publiques prenant en charge UTXO telles que CKB, Cardano et Fuel. Ce dernier sert de couche de vérification et de couche de stockage de données pour les actifs RGB, et convertit les données initialement traitées par les utilisateurs en travail de vérification et les transmet à des plateformes tierces/chaînes publiques telles que CKB. Cela revient à remplacer la vérification client par une 'plateforme tierce décentralisée de vérification', tant que vous faites confiance aux chaînes publiques comme CKB, Cardano, Fuel, etc.. Même si vous ne leur faites pas confiance, vous pouvez également revenir au mode RGB traditionnel.

RGB++ et le protocole RGB d'origine sont théoriquement compatibles entre eux.

Pour atteindre les effets mentionnés ci-dessus, nous devons utiliser une idée appelée « liaison isomorphe ». Les chaînes publiques telles que CKB et Cardano ont leur propre UTXO étendu, qui est plus programmable que l'UTXO sur la chaîne BTC. La « liaison isomorphe » consiste à utiliser l'UTXO étendu sur les chaînes CKB, Cardano et Fuel comme « conteneurs » pour les données d'actifs RGB, écrire les paramètres des actifs RGB dans ces conteneurs et les afficher directement sur la chaîne de blocs. Chaque fois qu'une transaction d'actif RGB se produit, le conteneur d'actif 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 ».

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

Par exemple, si Alice possède 100 jetons RGB et UTXO A sur la chaîne Bitcoin, et a également un UTXO sur la chaîne CKB, cet UTXO est marqué avec "Solde de jetons RGB : 100", et les conditions de déverrouillage sont liées à UTXO A.

Si Alice souhaite 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 à UTXO A à Bob, et transférer 70 autres UTXOs 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 UTXO 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 effectuée par des nœuds réseau tels que CKB ou Cardano via un consensus, sans l'intervention de Bob. À ce moment, CKB et Cardano servent de couche de vérification et de couche DA sous la chaîne Bitcoin.

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

Les données d'actifs RGB de tout le monde sont stockées sur la chaîne CKB ou Cardano, qui a des caractéristiques vérifiables à l'échelle mondiale et est propice à la mise en œuvre de la finance décentralisée, telle que les pools de liquidité et les protocoles de mise en gage d'actifs. Bien sûr, l'approche ci-dessus sacrifie également la confidentialité. L'essence est de faire un compromis entre la confidentialité et la facilité d'utilisation du produit. Si vous recherchez une sécurité et une confidentialité ultimes, vous pouvez revenir au mode RGB traditionnel; si cela ne vous dérange pas, vous pouvez utiliser en toute sécurité le mode RGB++, tout dépend de vos besoins personnels. (En fait, avec la complétude fonctionnelle puissante des chaînes publiques telles que CKB et Cardano, ZK peut être utilisé pour mettre en œuvre des transactions privées)

Il convient de souligner ici que RGB++ introduit une hypothèse de confiance importante : les utilisateurs doivent être optimistes quant au fait que la chaîne CKB/Cardano, ou la plateforme réseau composée d'un grand nombre de nœuds reposant sur des protocoles de consensus, est fiable et sans erreur. 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.

Sous le protocole RGB++, les utilisateurs peuvent utiliser directement leurs comptes Bitcoin pour gérer leurs conteneurs d'actifs RGB sur les chaînes UTXO telles que CKB/Cardano sans transfert inter-chaînes. Il suffit de tirer parti des caractéristiques de l'UTXO dans la chaîne publique susmentionnée et de définir la condition de déverrouillage du conteneur Cell associée à une certaine adresse Bitcoin/UTXO Bitcoin. 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 transactions RGB, un Engagement peut être envoyé à la chaîne Bitcoin. Cela s'appelle la fonction de "pliage de transaction", qui peut réduire les coûts d'utilisation.

Mais soyez prudent, le "conteneur" utilisé dans la liaison isomorphe a besoin d'une chaîne publique qui prend en charge le modèle UTXO, ou d'une infrastructure aux caractéristiques similaires dans le stockage d'état. La chaîne EVM n'est pas adaptée et rencontrera de nombreux pièges. (Ce sujet peut être écrit séparément et implique beaucoup de contenu. Les lecteurs intéressés peuvent se référer aux articles précédents de Geek Web3.)"RGB++ et liaison isomorphe : Comment CKB, Cardano et Fuel renforcent l'écosystème Bitcoin"；

en résumé, Un protocole de chaîne publique/d'expansion de fonction adapté à la réalisation de liaison isomorphe devrait présenter 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 le statut de l'actif;
4. Il existe des ponts ou des nœuds légers liés à Bitcoin;

Avertissement :

1. Cet article est reproduit à partir de [Geek Web3], le titre original est "Conception du protocole RGB et RGB++ en quelques minutes : instructions simples", les droits d'auteur appartiennent à l'auteur original [Faust], si vous avez des objections à la reproduction, veuillez contacterÉquipe Gate Learn, l'équipe le traitera dès que possible selon les procédures pertinentes.

2. Les vues et opinions exprimées dans cet article ne représentent que les vues personnelles de l'auteur et ne constituent pas des conseils en investissement.

3. D'autres versions linguistiques de l'article sont traduites par l'équipe Gate Learn. Sans référenceGate.io, copier, distribuer ou plagier les articles traduits est interdit.