Protocole RGB++ et avenir du Bitcoin : aperçus de Cipher de Bitcoin Singapore 2024

Le 9 mars, lors de la conférence Bitcoin Singapore 2024, co-organisée par la Fondation Nervos et ABCDE, Cipher, fondateur de CELL Studio et auteur du protocole RGB++, a présenté un discours d'ouverture intitulé « Présentation et perspectives du protocole RGB++ ».

Voici un résumé des principaux points de la présentation de Cipher :

Défis rencontrés par le protocole RVB

Le protocole RVB existe depuis de nombreuses années, mais il n'a pas été largement adopté en raison de plusieurs facteurs :

Défis liés aux opérations interactives

Dans les transactions impliquant BTC , ETH , etc., le destinataire n'a qu'à fournir une adresse et l'expéditeur peut transférer des fonds aujourd'hui ou demain, ce qui est très pratique. En revanche, chaque transaction RVB nécessite que le destinataire émette au préalable une facture. Ensuite, l'expéditeur doit construire une transaction RVB et générer une preuve de l'historique des actifs à envoyer au destinataire. Dès réception de cette preuve, le destinataire doit effectuer une validation côté client (CSV). Après une validation réussie, ils doivent conserver cette preuve pour les transactions futures.

Par conséquent, les transactions RVB dépendent non seulement de la présence en ligne des deux parties, mais également du stockage par les deux parties de données historiques pertinentes. Cela constitue un obstacle important pour les produits destinés au consommateur.

Problèmes de disponibilité des données (DA)

Dans les transactions RVB, il est essentiel de joindre la preuve historique du bien. Si cette preuve est perdue, c'est aussi critique que la perte d'une clé privée. La question de savoir qui aidera les utilisateurs à sauvegarder leurs actifs est un problème de disponibilité des données. Dans le protocole RVB d'origine, visant à préserver la confidentialité, personne d'autre ne stocke les actifs des utilisateurs, ce qui signifie que ceux-ci doivent assumer la responsabilité de leur propre stockage de données.

Même avec un stockage de données approprié, envisagez un scénario dans lequel Alice souhaite transférer des ressources RVB vers Bob. Comment lui envoie-t-elle la preuve historique de ces biens ? Vous utilisez le courrier électronique ou Whatsapp ? De toute évidence, la transmission via un canal centralisé est inappropriée et nécessite l’utilisation d’un canal P2P spécialisé. Cependant, les canaux P2P soulèvent des questions de confidentialité : pourquoi quelqu’un aiderait-il à transmettre ces données sensibles ? Cela conduit à une série de questions complexes.

Problèmes d'interopérabilité

Les données de preuve historiques des actifs RGB sont conservées par les utilisateurs eux-mêmes et transmises au destinataire lors des transactions, mais ne sont pas rendues publiques. Cela entraîne la dispersion des données entre chaque individu du réseau. Pour quelqu'un qui construit une plateforme de trading, qu'elle soit centralisée ou décentralisée, des données provenant de plusieurs sources sont nécessaires pour maintenir l'état global du RVB. Certains fournisseurs de services RGB centralisent et stockent ces données pour les développeurs d'applications, mais cette approche diminue la confidentialité de RGB. Malgré cette solution, des défis subsistent, comme celui de faciliter les transferts de données entre différents fournisseurs de services détenant les données RVB de différents utilisateurs.

Problèmes avec l'environnement d'exécution de contrats/scripts intelligents

Il existe des défis importants associés aux environnements d’exécution de contrats intelligents ou de scripts en RVB. Il utilise une machine virtuelle (VM) nommée AluVM, mais les spécificités de son langage de programmation doivent encore être finalisées. De plus, les outils de développement critiques, tels que les compilateurs et les débogueurs, ne sont pas entièrement développés. Il manque également de soutien aux États partagés et aux contrats décentralisés (sans propriétaire). À l'heure actuelle, il est évident qu'AluVM en est encore à ses tout débuts.

Par conséquent, RGB est confronté à de nombreux problèmes complexes, chacun nécessitant un temps et des efforts considérables. Ces défis contribuent de manière significative aux retards dans la mise en œuvre effective du RVB.

Un aperçu du protocole RGB++

Les transactions RVB sont intimement liées aux transactions Bitcoin via un processus de cartographie. De plus, les transactions RVB nécessitent une infrastructure hors chaîne, englobant la disponibilité des données (DA), la validation côté client, la mise en réseau P2P, les machines virtuelles, les états partagés et les contrats décentralisés. Lorsqu’on envisage une telle infrastructure, la blockchain vient naturellement à l’esprit, compte tenu de ses capacités en matière de gestion des données, de validation, d’intégration de machines virtuelles, de mise en réseau P2P, d’incitation et de contrats intelligents. Le concept du protocole RGB++ est basé sur cette intuition fondamentale, proposant l'utilisation de la blockchain CKB basée sur le modèle UTXO et complète de Turing comme substitut à l'infrastructure hors chaîne requise par RGB.

RGB++ introduit un concept appelé technologie de liaison isomorphe . Chaque transaction Bitcoin comprend une sortie. Dans le cas d'une transaction RVB, cela nécessite l'inclusion d'un segment OP_RETURN dans la sortie Bitcoin. Ce segment contient des données de hachage spécifiques, appelées engagement. Si cet engagement coïncide avec le hachage d'une transaction sur une autre blockchain publique, et si les entrées et sorties des deux transactions sont isomorphes - c'est-à-dire qu'elles correspondent dans leur structure - et en supposant que l'UTXO (Unspent Transaction Output) de cette blockchain alternative possède une capacité de calcul complète de Turing et les capacités de stockage d'état, la transaction sur la blockchain Bitcoin devient alors entièrement intégrée ou liée à la transaction sur cette autre blockchain. La blockchain CKB (Common Knowledge Base) satisfait à ces prérequis. Par conséquent, effectuer une transaction sur Bitcoin équivaut effectivement à effectuer une transaction correspondante sur la chaîne CKB. Tout changement dans l'état de la transaction Bitcoin reflète un changement dans l'état de la transaction sur la chaîne CKB, respectant les contraintes contractuelles présentes sur CKB. Cela résume l’essence de la technologie de liaison isomorphe. Cependant, ce concept englobe de nombreux aspects techniques complexes, notamment le maintien de la cohérence transactionnelle et la prévention des doubles dépenses, qui ne sont pas abordés en détail pour le moment.

La technologie de liaison isomorphe permet d'améliorer les capacités d'état de Bitcoin. Par exemple, considérons le btc_utxo#1 illustré dans le diagramme suivant. Ce Bitcoin UTXO (Unspent Transaction Output) ne présente généralement que deux états : un script de verrouillage et un montant, ce dernier représentant le solde. Cependant, dans la cellule bleue correspondante de la blockchain CKB (Common Knowledge Base), comme le montre le diagramme, les capacités sont plus larges. Contrairement à la fonctionnalité limitée du Bitcoin UTXO qui consiste simplement à afficher le solde, cette cellule isomorphe de la chaîne CKB peut stocker non seulement les données de solde, mais également divers autres types de données.

En plus du composant data, la Cell possède un script de type. Ce script répond à un objectif précis : il définit les conditions dans lesquelles les actifs sont reçus et impose des restrictions sur les types d'actifs.

De plus, la cellule contient un script de verrouillage, qui dans ce cas est explicitement lié à btc_utxo#1. Ce lien implique que la cellule sur la blockchain CKB ne peut être dépensée que si et quand btc_utxo#1 est dépensé.

Sur la plateforme CKB, nous avons implémenté un nœud Bitcoin light. Une fois qu'une transaction Bitcoin est initiée, elle est capturée par un mécanisme de relais, qui transfère ensuite cette transaction comme forme de preuve sur la blockchain CKB. Ce processus consiste à vérifier la présence de la transaction sur le nœud léger Bitcoin et à s'assurer que l'engagement est isomorphe à la transaction.

Grâce à cette approche, nous étendons considérablement les fonctionnalités de Bitcoin. Il ouvre la voie à l’émission d’un large éventail d’actifs directement sur Bitcoin et facilite l’expansion des contrats Turing-complete.

L’avantage de cette approche est que nous avons réussi à introduire le script Turing-complete dans le domaine Bitcoin tout en conservant un statut de sécurité presque identique à celui de Bitcoin Layer 1 (L1). En effet, tous les enregistrements historiques, transactions et engagements sont liés via la chaîne UTXO sur Bitcoin L1.

Le compromis, cependant, est une légère diminution de la confidentialité. Dans le cas du RVB, les données sont dispersées entre les utilisateurs individuels, ce qui rend difficile l'accès des autres aux données RVB d'un utilisateur particulier. Avec RGB++, toutes les données hors chaîne sont publiées sur la blockchain CKB, qui maintient ces états, entraînant une réduction de la confidentialité. Pourtant, le pire des cas n’est qu’une réduction du niveau de confidentialité des transactions Bitcoin ; il n'expose pas les adresses IP ou les informations d'identité personnelle.

En fait, nous pourrions implémenter une couche de confidentialité améliorée sur CKB. Il y a quatre ans, nous avons collaboré avec la communauté Grin pour rédiger un article discutant de l'utilisation de la technologie Mimblewimble sur CKB pour créer cette couche de confidentialité améliorée. À l’avenir, nous pourrions intégrer cette couche dans RGB++, permettant non seulement de dissimuler les montants des transactions, mais également de rompre les liens dans l’historique des transactions. La confidentialité qui en résulterait serait plus forte que celle du RVB.

En résumé, nous avons réalisé la vision du RVB de manière plus simple et étendu encore plus ses capacités.

Libérer le potentiel des actifs Bitcoin L1

Voici une introduction simplifiée au concept de saut.

La technologie de liaison homomorphe , qui peut être appliquée à Bitcoin , est également applicable à Litecoin, Liquid et à d'autres chaînes basées sur UTXO. Comme mentionné précédemment, dans les systèmes RGB et RGB++, le bénéficiaire est un Bitcoin UTXO, doté du seul pouvoir de dépenser. Lorsque je crée une transaction RGB++ sur Bitcoin, j'ai la possibilité de désigner le bénéficiaire non pas comme un Bitcoin UTXO, mais comme un Litecoin UTXO. Par conséquent, cet actif « saute » vers Litecoin, puisque sa dépense ultérieure nécessite un déverrouillage par un Litecoin UTXO. De même, cet actif peut passer à Liquid, ou même revenir à Bitcoin.

Bien entendu, il y a un cas particulier à considérer. Lorsqu'un actif passe à la blockchain CKB, sa couche d'interprétation des données, sa couche contractuelle et sa propriété se trouvent toutes sur CKB. Cela signifie qu'il ne dépend plus d'aucune autre chaîne et peut directement s'engager dans des transactions et interagir avec des contrats intelligents sur CKB. Cela peut être décrit comme un saut vers L2. Sur L2, les utilisateurs peuvent effectuer des milliers, voire des dizaines de milliers de transactions jusqu'à ce que quelqu'un décide de transférer l'actif vers Bitcoin. C'est ce que nous appelons le pliage de transactions. Qu'elles soient RGB ou RGB++, les transactions s'effectuent sur la blockchain Bitcoin, où les frais de minage sont chers. Cependant, une fois qu’un actif passe à CKB et subit un repli de transaction, les frais deviennent considérablement inférieurs et il peut facilement revenir à la blockchain Bitcoin à tout moment. L’ensemble de ce processus ne repose sur aucun pont multi-signatures ni sur la confiance en des individus ; la seule exigence est d'attendre quelques confirmations de blocage supplémentaires. Passer de la blockchain Bitcoin à la blockchain CKB nécessite d'attendre 6 confirmations de bloc Bitcoin. Pour passer de la blockchain CKB à Bitcoin, 24 confirmations de bloc CKB sont nécessaires, pour éviter les retours de bloc.

C'est pourquoi nous disons que nous avons introduit un nouveau paradigme. Bien sûr, il ne s'agit pas de notre invention mais plutôt d'une idée qui existait dans les premiers matériaux RVB, où les actifs RVB pouvaient passer d'une chaîne UTXO à l'autre. Après avoir combiné l'exhaustivité de Turing avec le passage à CKB, nous avons découvert que les applications potentielles sont vastes et très différentes du récit traditionnel des ponts multi-signatures d'Ethereum.

Perspectives d'avenir

Parlons ensuite de l’évolutivité. Le taux de transaction de Bitcoin est d'environ 7 transactions par seconde (TPS), tandis que CKB culmine à environ 200 TPS. Si l’on prend en compte les coûts d’exécution du contrat et de validation du script, le TPS pourrait être réduit à environ 50, ce qui représente moins d’une multiplication par dix par rapport au Bitcoin. Ce n’est pas suffisant, alors quelles sont les options pour une mise à l’échelle ? Nous voyons deux directions principales :

• Canaux d'État : les canaux d'État représentent une solution d'évolutivité ultime, offrant un plafond très performant. Le défi réside toutefois dans la complexité de la mise en œuvre de contrats multipartites, rendant les canaux étatiques plus adaptés aux transactions de paiement et aux interactions entre individus et serveurs. Jan est sur le point de diriger l’équipe pour faire progresser la recherche sur les chaînes publiques.

  
  

• AppChain Stack : En construisant une solution Layer 2 (L2) basée sur le modèle UTXO, l'AppChain L2 sécurisera son ancrage sur CKB, en s'alignant isomorphiquement avec lui. Cette approche nous permet de développer des stratégies de mise à l'échelle innovantes au sein de ce nouveau paradigme. Il s’agit également d’un objectif clé pour CELL Studio au cours de l’année à venir.

  
  

Enfin, j'aimerais décrire la mission et la feuille de route de RGB++. RGB++ vise à développer des modules de protocole fondamentaux pour faciliter une utilisation et une intégration faciles par les développeurs et utilisateurs tiers. La feuille de route du protocole RGB++ est la suivante, et le protocole est déjà en ligne sur le réseau principal Bitoin et le SDK RGB++ a été publié le 3 avril.

Par Cipher, fondateur de CELL Studio et auteur du protocole RGB++.