RGB renforce les capacités d’évolutivité et de confidentialité de Bitcoin et Lightning Network

TL; DR

• RGB fonctionne comme une solution de couche 2/3 sur le paradigme de validation côté client Bitcoin et Lightning Network, hébergeant toutes les données de contrats intelligents en dehors des transactions Bitcoin. Cette conception garantit le fonctionnement du système au-dessus du réseau Lightning, éliminant ainsi le besoin de modifications des protocoles LN.
  
• Les contrats intelligents RVB sont conçus pour l’évolutivité et la confidentialité. Le système prend en charge la propriété privée et mutuelle, résume et sépare les préoccupations, représentant une forme post-blockchain et complète de Turing d'informatique distribuée sans confiance sans nécessité d'introduire de nouveaux jetons.
  
• Les contrats RVB sont organisés en segments distincts appelés « fragments », chacun avec son propre historique et ses propres données, ce qui améliore l'évolutivité et empêche le mélange des historiques de différents contrats. Ils interagissent via le protocole Bifrost sur le réseau Lightning, permettant des changements coordonnés entre plusieurs parties, similaires aux DEX fonctionnant sur le réseau Lightning.
  
• RGB utilise des sceaux à usage unique defiutilisé sur les UTXO Bitcoin pour des raisons de sécurité. Toute partie possédant un historique d’état de contrat intelligent peut vérifier son caractère unique, en tirant parti du script de Bitcoin pour define droits de propriété et d'accès.
  
• Dans RVB, la propriété et la validation de l’État sont des entités distinctes. La propriété est gérée par le script Bitcoin, un système non Turing Complete. Les règles de validation, en revanche, sont dictées par le schéma RVB utilisant le script Turing Complete Simplicity/Contractum/Rust.
  
• Chaque contrat intelligent RVB est associé à un état unique à l'aide de sceaux à usage unique. Les sceaux et l’état suivent des règles et validations spécifiques fixées par le créateur du contrat, régies par un « schéma ». Ce schéma agit comme un ensemble de règles pour vérifier les données contractuelles côté client, permettant un niveau élevé d'évolutivité et de confidentialité du protocole.
  
• La conception de RGB est hautement interopérable avec les technologies Bitcoin et Lightning Network existantes, facilitant une intégration transparente avec ces plates-formes et toutes les mises à niveau futures.
  
• Contrairement au style de programmation impératif de nombreuses plateformes blockchain, RGB utilise un style déclaratif. Cette approche se concentre sur la description du résultat souhaité plutôt que sur le détail des étapes spécifiques pour y parvenir.
  
• RGB utilise diverses technologies avancées, notamment AluVM pour les tâches informatiques portables déterministes, PRISM pour le calcul de machines à états infinis partiellement répliquées et Storm pour le stockage sans confiance basé sur un séquestre utilisant des preuves zk. Ces technologies contribuent à la robustesse, à la confidentialité et à l’extensibilité du RVB.
  
• RGB (v0.10) introduit des améliorations notables à l'expérience utilisateur et aux processus d'intégration, rationalisant les opérations et minimisant les dépendances. La version mise à jour comprend une API de bibliothèque et un outil de ligne de commande plus unifiés, ce qui la rend plus accessible et conviviale.

Brève description

RGB est un protocole conçu pour émettre des jetons sur le réseau Bitcoin avec une confidentialité améliorée et une compatibilité avec le réseau Lightning. Il s'appuie sur le concept de « pièces colorées », comme celles utilisées dans le protocole OmniLayer où les métadonnées des transactions Bitcoin indiquent un transfert de jeton. Par exemple, les transactions USDT sur OmniLayer fonctionnent comme des transactions Bitcoin augmentées de données supplémentaires détaillant les mouvements des jetons USDT. Cependant, ces méthodes sont confrontées à des limitations telles que des contraintes de taille des données dans les sorties OP_RETURN, une analyse intensive de la blockchain et une confidentialité restreinte résultant de la visibilité sur la chaîne.

RGB résout ces problèmes en éloignant la majorité des processus de validation de la blockchain Bitcoin. Il adopte la validation côté client et utilise des sceaux à usage unique pour connecter les jetons aux UTXO de Bitcoin, tout en préservant la confidentialité des utilisateurs.

Les jetons sont transférés en s'engageant dans un message contenant des informations de paiement RVB au sein d'une transaction Bitcoin, permettant aux jetons de passer d'un UTXO à un autre sans laisser de trace sur le graphique de la transaction Bitcoin. Cela améliore considérablement la confidentialité, car les transactions RVB « téléportent » discrètement les jetons, les données spécifiques au RVB étant transmises via des canaux privés hors chaîne.

De plus, pour garantir la propriété et éviter l’inflation, les destinataires doivent valider l’intégralité de l’historique des transactions des jetons reçus. RGB permet des mises à niveau futures sans avoir besoin de hard forks, garantissant que les mineurs ne peuvent pas retracer le flux d'actifs, offrant ainsi une plus grande résistance à la censure. Contrairement aux structures de blockchain traditionnelles, RGB fonctionne sans blocs ni chaînes, le positionnant comme un protocole décentralisé sans bloc, promettant une confidentialité, une sécurité et une évolutivité élevées.

Introduction et vision

Bon mot: Un système d'état et de contrat intelligent validé par le client fonctionnant au niveau de la couche 2/3 dans Bitcoin et Lightning Network.

Plus de détails:

RGB est un système de contrats intelligents évolutif et confidentiel pour Bitcoin et Lightning Network. Les contrats intelligents RVB fonctionnent avec validation côté client paradigme, logement toutes les données des contrats intelligents à l'extérieur Transactions Bitcoin, c'est-à-dire blockchain Bitcoin ou état du canal Lightning. Cela permet au système de fonctionner sur Lightning Network sans aucune modification des protocoles LN et constitue également une base pour un niveau élevé d'évolutivité et de confidentialité des protocoles.

Les contrats intelligents incarnent les principes de propriété privée et mutuelle, d’abstraction et de séparation des préoccupations. Ils représentent une forme « post-blockchain », Turing-complète d’informatique distribuée sans confiance qui ne nécessite pas l’introduction de jetons.

Les contrats RVB fonctionnent dans des segments distincts appelés « fragments ». Chaque fragment a son propre historique et ses propres données, ce qui signifie que les différents contrats ne mélangent pas leurs historiques. Cette méthode améliore l’évolutivité. Le terme « fragment » est utilisé pour montrer que RVB atteint des objectifs similaires à ceux prévus avec le concept de fragments d’Ethereum.

Bien qu'ils fonctionnent indépendamment, les contrats RVB peuvent interagir via le protocole Bifrost sur le Lightning Network. Cela permet des changements coordonnés entre plusieurs parties. Par exemple, il permet aux DEX de fonctionner sur le réseau Lightning.

Technologie et architecture

Présentation générale du fonctionnement RVB et des scellés à usage unique

Figure 1. Présentation générale du fonctionnement de RVB.
Source : Github de l’association LNP/BP.

En tant que mécanisme de sécurité, RVB utilise scellés à usage unique definégocié sur les UTXO Bitcoin, qui offrent la possibilité à toute partie ayant un historique d'état de contrat intelligent de vérifier son caractère unique. Essentiellement, RGB exploite le script Bitcoin pour son modèle de sécurité et definda possession ainsi que le des droits d'accès.

Figure 2. Principe de fonctionnement RVB de haut niveau.
Source : « Favoriser l'adoption massive de la crypto : comment le protocole RVB éclaire l'avenir du Bitcoin » par Waterdrip Capital.

Chaque contrat intelligent RVB est definé par un état de genèse, confectionné par le émetteur de contrats intelligents (ou, en termes simples, émetteur) et un graphe acyclique dirigé (DAG) de transitions d'état conservées sous forme de données validées par le client.

Figure 3. Transactions, sceau fermé et témoin.
Source : Github de l’association LNP/BP.

On peut le résumer ainsi : chaque transaction possède un UTXO, et la possession de cet UTXO confère à son propriétaire le droit de posséder l'État. La propriété détermine qui peut modifier l’état de la blockchain et « dépenser » l’UTXO. L'individu qui détient l'État est appelé le parti. État propriétaire.

La partie détient le pouvoir de modifier la section pertinente de l'état du contrat intelligent en générant une nouvelle transition d'état et en la confirmant dans une transaction, en utilisant la sortie contenant l'état précédent.

Le processus signifie fermeture d'un sceau sur la transition d'état, et une paire comprenant la transaction de dépense et les données de transaction extra correspondantes sur la transition d'état est appelée un témoin (représenté dans une image ci-dessus).

Propriété et accès : propriétés principales

Figure 4. Propriété et accès.
Source : Github de l’association LNP/BP.

La propriété de l’État et la validation sont des concepts distincts. Les règles de validation précisent comment l'état peut changer, mais elles n'identifient pas qui peut effectuer le changement. 

D'un autre côté, la propriété est contrôlée par le script Bitcoin au niveau de la blockchain Bitcoin, ce qui n'est pas Turing Complete. En revanche, les règles de validation sont régies par le schéma RVB utilisant le script Simplicity/Contractum, c'est-à-dire étant Turing Complete. 

Schéma RVB

Dans les contrats intelligents RVB, chaque contrat se voit attribuer un état unique via des sceaux à usage unique. Ces sceaux, ainsi que l’État, ont des règles et validations spécifiques, fixées au début par le créateur du contrat. Cette configuration est régie par un « schéma », fonctionnant comme un ensemble de règles pour valider les données contractuelles côté client. Le schéma peut inclure des scripts complexes faisant partie intégrante de la logique du contrat.

Figure 5. Schéma RVB.
Source : Github de l’association LNP/BP.

Principes de validation et de conception côté client

Figure 6. Validation RVB côté client.
Source : Github de l’association LNP/BP.

1. Forte propriété : En RVB, les contrats intelligents ont clairement un defipropriétaire ou propriétaires recherchés. Seuls les propriétaires désignés détiennent le pouvoir de modifier l’état du contrat. Ces contrats définissent des droits ou des opérations distincts classés comme publics (accessibles à tous) ou possédés (restreints au propriétaire).
2. Confidentialité : Les informations contenues dans le contrat restent confidentielles et connues uniquement des participants, notamment des propriétaires de l'État. Les participants ont la possibilité de rendre certaines données publiques, mais par défaut, toutes les informations sont privées. Cette confidentialité empêche les outils d'analyse externes d'accéder aux données, garantissant ainsi qu'aucune information sensible n'est stockée dans les registres publics.
3. Séparation des préoccupations: RVB présente une conception modulaire avec des couches distinctes, chacune étant affectée à une tâche spécifique. Ces couches fonctionnent de manière indépendante, éliminant ainsi la nécessité pour les couches inférieures d’être conscientes de la structure des couches supérieures. Cette conception améliore l'organisation et l'efficacité du système.
4. Extensibilité: Le système est facilement extensible, permettant la création et l'intégration de contrats intelligents avancés sans qu'il soit nécessaire de modifier le protocole principal ou de recompiler l'intégralité de la bibliothèque RVB.
5. Déterminisme: La logique de validation de RGB est déterministe et donne systématiquement des résultats identiques avec les mêmes entrées et l'état dominant de la blockchain sous-jacente ou du canal Lightning Network. Cette cohérence est obtenue grâce à deux éléments principaux : a. La logique de validation de base, écrite en Rust, est la même sur tous les systèmes exécutant RVB. b. La logique de validation spécifique au contrat s'exécute sur AluVM, une machine virtuelle qui fournit un ensemble d'instructions cohérent quelle que soit la plateforme.
6. Interopérabilité LNP/BP : RGB est conçu pour fonctionner de manière transparente avec les technologies Bitcoin et Lightning Network existantes. Il est également conçu pour être compatible avec toute future mise à niveau de ces technologies.
   

Approche RVB et approche Pure Blockchain/L1

L’approche purement blockchain/L1 est erronée, déclare l’équipe RGB.

Figure 7. Commentaires RVB sur l'approche Blockchain/L1.
Source : Github de l’association LNP/BP.

Approche RVB : programmation déclarative ou impérative :

• La plupart des plateformes blockchain, y compris Ethereum, utilisent des contrats intelligents rédigés dans un style impératif. Dans cette approche, le contrat fonctionne comme un programme qui dirige explicitement l’exécution étape par étape des tâches, s’apparentant à une recette précise et détaillée.
• Ces programmes impératifs sont souvent assez restrictifs et limités par les capacités de la plateforme blockchain sous-jacente. Même s’ils sont parfois qualifiés de Turing-complets, ils présentent des limites importantes.

Nature déclarative des contrats intelligents RVB :

• RVB, en revanche, n'utilise pas de programmation impérative. Au lieu de cela, il utilise une forme spéciale de programmation fonctionnelle dans laquelle les contrats intelligents sont definé de manière déclarative.
• Dans la programmation déclarative, au lieu de détailler comment faire quelque chose, vous décrivez quel devrait être le résultat. C’est comme décrire à quoi devrait ressembler un repas plutôt que de fournir des instructions de cuisson étape par étape.
• Le « Schéma » en RVB est déclaratif definition d’un contrat intelligent. Il précise les règles et conditions du contrat, mais pas la séquence exacte des opérations pour les réaliser.

Changement de paradigme dans la programmation :

• Le passage du style impératif d’Ethereum au style déclaratif de RVB dans la programmation de contrats intelligents est similaire au passage de la programmation impérative traditionnelle à la programmation fonctionnelle ou déclarative dans le développement logiciel général.
• Ce changement nécessite un état d’esprit différent : se concentrer sur le « quoi » (les résultats souhaités) plutôt que sur le « comment » (les étapes spécifiques pour atteindre ces résultats).

Simplicité

Le plan initial impliquait d'incorporer Simplicity dans RGB, et des efforts étaient consacrés à assurer la compatibilité dès le premier jour. Cependant, étant donné la lenteur du développement de Simplicity et l'incertitude entourant son calendrier de sortie, il est devenu évident qu'il n'était pas pratique de s'y fier. La version RVB en cours, actuellement en préparation, a soulevé des questions sur l’inclusion de Simplicity.

Conscients de l'absence d'un calendrier fiable pour la simplicité, nous avons lancé un examen d'alternatives (WASM, EVM (pour plaisanter), IELE, etc.). Finalement, il est devenu évident que le développement d'une machine virtuelle propriétaire pour RVB était la seule option viable, remplaçant la dépendance initiale envers Simplicity.

Nous avons donc décidé de créer AluVM – une machine virtuelle basée sur Rust purement fonctionnelle et hautement portable pour les contrats intelligents validés côté client (RVB), Lightning Network, l'informatique distribuée déterministe et de pointe.

Prisme

PRISM signifie informatique « machines à états infinis partiellement répliquées ».

Technologie RVB defines règles pour l'évolution des contrats intelligents à un niveau de base, appelé Schema, mais cela ne limite pas toutes les actions futures du contrat avec un algorithme unique et global. Au lieu de cela, chaque nœud du réseau effectue des opérations individuelles, et l’état du contrat ainsi que le contrat lui-même restent valides tant que ces opérations respectent les règles du schéma. 

De plus, cette approche ne contraint pas l’évolution historique du contrat avec un algorithme prédéterminé. Ainsi, un contrat peut présenter des comportements variés tant que chaque modification répond à des règles de validation spécifiques. Cette méthode se concentre sur des règles locales plutôt que sur un algorithme global.

En revanche, Ethereum utilise un algorithme global dans lequel chaque opération affecte l’ensemble de l’état du contrat intelligent. Avec RGB, vous travaillez avec seulement une partie de l’état du contrat, en appliquant les règles localement. Cela offre un plus large éventail de possibilités d’évolution des contrats.

Ci-dessous, vous pouvez voir une vue d'ensemble des différences entre les canaux d'état et la validation côté client : 

Figure 8. Séparation des systèmes distribués.
Source : Github de l’association LNP/BP.

Les différences plus spécifiques sont les suivantes : 

Figure 9. Comparaison des canaux d'état et de la validation côté client.
Source : Github de l’association LNP/BP.

AluVM

AluVM – (unité logique algorithmique VM) est une machine virtuelle RISC purement fonctionnelle conçue pour les tâches informatiques portables déterministes

AluVM se distingue en utilisant un système basé sur des registres qui interdit l'accès aléatoire à la mémoire. Cette conception améliore l'adéquation d'AluVM aux applications telles que les contrats intelligents, l'exécution de code à distance et l'informatique distribuée et de pointe. Les principaux atouts d'AluVM résident dans son déterminisme, sa robustesse et sa capacité d'analyse formelle de code.

Principales caractéristiques: Exceptionnel, Portabilité, Sandboxing, Sécurité, Extensibilité.

L'architecture de jeu d'instructions (ISA) d'AluVM est conçue pour être adaptable, lui permettant de créer différents environnements d'exécution pour diverses applications. AluVM lui-même est une machine virtuelle et ISA hautement prévisible, fonctionnelle et basée sur des registres. 

Tout en limitant l'accès aléatoire à la mémoire, l'AluVM ISA excelle dans l'exécution de tâches arithmétiques, y compris celles liées aux courbes elliptiques. De manière unique, l'environnement de la VM peut étendre l'AluVM ISA, permettant l'ajout de fonctionnalités telles que le chargement de données dans les registres de la VM et la prise en charge d'instructions spécialisées (par exemple, SIMD) adaptées à des applications spécifiques.

AluVM est principalement destiné à être utilisé dans les systèmes distribués où la cohérence et la fiabilité sur les différentes plates-formes sont plus cruciales que la vitesse de traitement. Les principales utilisations d'AluVM, avec les extensions ISA appropriées, incluent la technologie blockchain, les calculs essentiels au consensus dans les réseaux, l'informatique de pointe, l'informatique multipartite (qui couvre l'apprentissage automatique déterministe), la validation côté client, l'informatique Internet2 restreinte et les algorithmes génétiques. Ces applications bénéficient de la capacité d’AluVM à fonctionner de manière cohérente et sécurisée dans divers environnements.

Figure 10. Comparaison AluVM.
Source : Github de l’association LNP/BP.

Contrat

Contractum se distingue des autres langages de programmation de contrats intelligents en combinant les capacités fonctionnelles de Haskell avec la proximité du bare metal vu dans Rust. Il occupe une niche jusqu’alors inaccessible aux smart contracts :

Figure 11. Comparaison de Contractum, Simplicity et d’autres langages.
La source: contractum.org

Contractum est un langage de programmation utilisé pour créer des contrats RVB. Les contrats conclus avec Contractum sont vérifiés à l'aide d'une méthode appelée validation côté client. Cette approche n’ajoute aucune donnée à la blockchain Bitcoin, ce qui peut être comparé à une forme de technologie de sharding, encore améliorée grâce à l’utilisation de preuves à connaissance nulle. 

La validation côté client sépare également le développement du contrat des transactions blockchain, ce qui rend impossible le suivi ou l'analyse de ces transactions par les méthodes traditionnelles d'analyse blockchain.

Figure 12. Caractéristiques du contrat.
La source: contractum.org

Pour s'engager dans la conception de Contractum, il est important de se familiariser avec les technologies utilisées par les contrats intelligents RVB :

Figure 13. Technologies utilisées par les contrats intelligents RVB.
La source: contractum.org

Mises à jour récentes de la nouvelle version RGB v0.10

Dans la dernière itération de RGB (version 0.10), plusieurs améliorations techniques avancées ont été mises en œuvre, améliorant ainsi les capacités du framework pour le développement d'applications complexes. Ces mises à jour se concentrent principalement sur l'introduction d'un Global State pour chaque contrat RGB, l'intégration des interfaces de contrat et l'adoption d'un système de type strict.

État global dans les contrats RVB

La fonctionnalité Global State est une innovation essentielle dans RGB v0.10, permettant à chaque contrat de maintenir un état universellement accessible. Cet état est accessible non seulement à la machine virtuelle RVB mais également aux clients externes tels que les portefeuilles et autres applications.

L'utilité de cet État global est essentielle pour la construction d'applications sophistiquées sur la plate-forme RVB, en particulier celles nécessitant une gestion d'état complexe comme les actifs synthétiques et les pièces stables algorithmiques. Il permet une interaction plus dynamique avec l’état du contrat, dépassant les limites des architectures de contrats intelligents traditionnelles.

Interfaces contractuelles

RGB v0.10 introduit les « interfaces de contrat » en tant que protocole de communication standardisé pour divers contrats intelligents. Ces interfaces fonctionnent de manière similaire aux contrats ABI (Application Binary Interfaces) et ERC (Ethereum Request for Comments) d’Ethereum.

Une distinction clé de l’approche de RGB est la standardisation non obligatoire de ces interfaces et leur emballage inhérent avec des contrats, éliminant ainsi le besoin d’une distribution séparée. Cela facilite les interactions sémantiques entre les utilisateurs et les contrats via les interfaces utilisateur des portefeuilles et autres logiciels.

Ces interfaces ne sont pas statiques ; les développeurs peuvent augmenter les contrats existants avec des interfaces supplémentaires au fil du temps, améliorant ainsi les fonctionnalités sans modifier le noyau immuable du contrat.

Système de type strict

Le nouveau format d'encodage dans RGB v0.10 utilise un système de « types stricts ». Ce système est une nouvelle approche de type de données fonctionnelle conçue pour une représentation et une introspection efficaces des états contractuels dans le cadre RVB.

Le système de type strict garantit la taille des données au moment de la compilation, ce qui est particulièrement bénéfique pour le fonctionnement sur des appareils aux ressources limitées, tels que les portefeuilles matériels bas de gamme avec des capacités de mémoire limitées.

De plus, l'ensemble de la couche consensus RVB de la version 0.10 est compilé en types stricts, fournissant une base pour les preuves formelles de compatibilité binaire entre différentes versions logicielles. Cette fonctionnalité simplifie et sécurise non seulement l'utilisation de RVB, mais permet également aux émetteurs d'actifs et aux développeurs de contrats d'ajouter des métadonnées supplémentaires à leurs actifs ou contrats. Ces métadonnées peuvent jouer un rôle crucial dans la vérification de l’identité et de l’authenticité des actifs ou des contrats dans l’écosystème RVB.

Contrats intelligents basés sur Rust

Les contrats intelligents RVB peuvent désormais être rédigés dans Rust, en tirant parti des capacités du langage en matière de sécurité et de performances des types.

L'intégration stricte des types de système facilite la compilation directe des types de données Rust dans les structures contractuelles RVB, améliorant ainsi l'efficacité et la fiabilité du code contractuel.

Capacités améliorées d’introspection d’état

Les contrats intelligents dans RGB v0.10 peuvent introspecter leur propre état dans le code de validation exécuté par la machine virtuelle RGB.

Cette fonctionnalité est particulièrement utile pour créer des contrats complexes qui interagissent avec les transactions Bitcoin, les contrats de journaux discrets et d'autres structures de données complexes, améliorant ainsi la portée et les fonctionnalités des contrats intelligents RVB.

Format de facture basé sur une URL

La mise à jour introduit un nouveau format de facture qui remplace l'ancien système codé Bech32m.

Ces nouvelles factures basées sur une URL sont nettement plus courtes et plus conviviales, facilitant une vérification plus facile et une ouverture automatique avec un logiciel préconfiguré.

Prise en charge de WASM (WebAssembly)

La bibliothèque standard RVB est désormais compatible avec les environnements dépourvus d'accès aux E/S et au système de fichiers, tels que les pages Web ou les plugins de navigateur.

Cela élargit les cas d'utilisation potentiels du RVB, lui permettant de fonctionner de manière transparente dans un large éventail d'applications et d'extensions Web.

Descripteurs de racine pivotante et dérivation personnalisée

RGB v0.10 utilise des engagements OP_RETURN basés sur la racine pivotante (appelés tapret), nécessitant une prise en charge au niveau du descripteur pour les portefeuilles afin de reconnaître les transactions avec des sorties modifiées.

L'introduction d'index de dérivation personnalisés dans cette version empêche les portefeuilles non RVB de dépenser par inadvertance des sorties contenant des actifs RVB, préservant ainsi l'intégrité de ces actifs.

Dépendances simplifiées

La couche de consensus RVB de la version 0.10 a réduit ses dépendances, s'éloignant notamment d'une implémentation personnalisée à l'épreuve des balles dérivée à l'origine des projets Grin.

Cette réduction des dépendances améliore la stabilité de l’API et la robustesse globale du système.

Processus d'intégration rationalisé

La mise à jour simplifie les flux de travail opérationnels en réduisant le besoin de plusieurs appels d'API et d'encodage complexe de structures de données multilingues.

Les états du contrat RVB sont désormais représentés sous forme d'objets JSON, permettant une sérialisation simple dans différents langages de programmation.

Améliorations de l'expérience utilisateur

La nouvelle version de RGB simplifie l'expérience utilisateur en consolidant des composants auparavant disparates dans une API de bibliothèque unifiée et un outil de ligne de commande.

Bien que le nœud RVB puisse toujours être utilisé sur des serveurs domestiques, son utilisation n'est plus obligatoire pour interagir avec le système RVB, réduisant ainsi la barrière à l'entrée pour les utilisateurs et les applications de portefeuille.

Cette section comprend un remerciement spécial à Waterdrip Capital pour avoir mis en lumière les dernières fonctionnalités de son article intitulé « Conduire l'adoption massive de la crypto : comment le protocole RVB illumine l'avenir du Bitcoin ».

Concurrents RVB

Figure 14. FRGB vs Ethereum en termes simples.
Source : Github de l'association LNP/BP

Racine pivotante

Taproot Assets, anciennement connu sous le nom de Taro, est un protocole conçu pour lancer des jetons sur le réseau Bitcoin. Ce protocole exploite le modèle UTXO de Taproot ainsi que des solutions associées telles que Tapscript et taptweak. Ces outils sont utilisés pour stocker des informations sur l'offre et le solde d'un actif dans les données de transaction Bitcoin.

Figure 15. Schéma de stockage des informations sur les jetons Taproot Assets.
Source : « Taproot Assets : émettre des actifs sur Bitcoin » par Voltage

Taproot Assets utilise une méthode analogue au concept Ordinals, dans laquelle les jetons BRC-20 stockent des informations d'approvisionnement dans les métadonnées des satoshis énumérés. À l’inverse, Taproot Assets intègre ces informations dans la sortie Taproot d’une transaction Bitcoin, en utilisant ce que l’on appelle un « arbre Merkle clairsemé ». Essentiellement, Taproot Assets intègre un arbre Merkle dans la transaction Bitcoin, qui sert de preuve du solde d'un utilisateur spécifique et de l'offre globale de jetons. Cet arbre, à son tour, reflète les données de « l'Univers » – un référentiel qui conserve l'historique complet des actifs et est géré par l'émetteur du jeton.

Figure 16. Arbre d'état numérique.
Source : « Taproot Assets : émettre des actifs sur Bitcoin » par Voltage

Arbre numérique d'état – L'architecture de Taproot Assets offre deux options pour la preuve d'équilibre : les données hors chaîne de l'Univers ou l'arbre Merkle clairsemé intégré dans l'UTXO.

Mécanisme opérationnel

1. Le créateur du jeton exécute une transaction P2TR (Pay to Taproot) à l'aide du protocole Taproot Assets. 
2. Les informations sur l'actif, sous la forme d'un arbre Merkle, sont stockées dans l'UTXO de cette transaction (en fait, le bloc Genesis). 
3. Pour transférer le jeton, le propriétaire de la clé Taproot modifie les informations de solde dans l'arborescence Merkle, garantissant ainsi que l'offre globale d'actifs reste constante. 
4. De telles modifications sont introduites via une nouvelle transaction Taproot. Cependant, pour chaque transfert de jeton, une transaction en chaîne distincte n'est pas requise. Semblable aux rollups ou au Lightning Network, le protocole permet au propriétaire de traiter un « lot » de transferts, publiant ensuite l’état mis à jour des soldes.

Avantages des actifs Taproot

• L'un des principaux avantages de Taproot Assets est sa compatibilité totale avec le réseau Lightning, améliorant les possibilités d'évolutivité et réduisant les coûts de transaction.
• Taproot Assets crée une couche distincte pour les opérations d'enregistrement avec des jetons personnalisés. Bien qu'il s'appuie principalement sur des données hors chaîne, il rend public l'état des soldes sur le réseau principal. 
• Cette approche est plus flexible, évolutive et complète que le BRC-20, mais elle pose également plus de complexité pour les utilisateurs inexpérimentés.

BitVM

BitVM est un projet d'avant-garde visant à transformer Bitcoin en une plateforme informatique entièrement décentralisée. Présenté le 9 octobre 2023, le livre blanc BitVM présente une technologie qui est actuellement en phase de test et nécessite des développements supplémentaires pour atteindre son plein potentiel.

Fonctionnalité de base et concept de BitVM

À la base, BitVM utilise le concept de cumuls optimistes pour externaliser les calculs des contrats intelligents du réseau, effectuant ensuite une vérification en chaîne basée sur des « preuves de fraude ». Théoriquement, une fois les informations du contrat intelligent enregistrées dans une transaction Taproot (sous forme de code binaire), l'échange de données et les calculs sont censés avoir lieu directement entre les parties. Cette approche vise à réduire la congestion de la blockchain. Cependant, si le prouveur (la partie qui prouve, c'est-à-dire le titulaire du contrat) transmet des données erronées, un vérificateur peut lancer une vérification en chaîne. Ce processus constitue la base du concept de preuve de fraude.

Gestion de la vérification en chaîne dans un réseau informatiquement limité

Le défi réside dans la manière d’effectuer une vérification du fonctionnement dans un réseau qui, intrinsèquement, ne prend pas en charge de tels calculs. Pour résoudre ce problème, BitVM utilise un arbre Merkle pour créer un schéma de porte NAND logique, qui est ensuite enregistré dans une transaction Taproot. Essentiellement, l'arbre Merkle dans les données de transaction agit comme un schéma NAND, dans lequel chaque « branche » porte l'une des deux valeurs possibles : 1 ou 0. Le calcul en chaîne se déroule petit à petit, la sortie d'une « branche » devenant l'entrée pour le suivant. Des échanges de transactions constants pour la vérification de la valeur ont lieu entre les parties au contrat intelligent. Si la version de calcul du prouveur s’avère incorrecte, le vérificateur reçoit ses actifs verrouillés dans la transaction Taproot.

Figure 17. Représentation schématique de NAND.
Source : « Le gros problème avec BitVM : le calcul arbitraire est désormais possible sur Bitcoin sans fork » par Bitcoin Magazine

Construire NAND à l'aide de Taproot et Merkle Tree

Des informations détaillées sur la façon dont BitVM facilite la création de NAND à l'aide des arbres Taproot et Merkle, ainsi que son impact sur les calculs, peuvent être trouvées dans la documentation technique.

Cette approche permet une vérification précise, étape par étape, des calculs de contrats intelligents, conformément aux principes d'intégrité et de sécurité de la blockchain.

Les défis du bilatéralisme des contrats intelligents

Un problème important persiste dans BitVM en raison de la structure bilatérale des contrats intelligents, facilitant l'échange direct de données uniquement entre le vérificateur et le prouveur, à l'exclusion de la participation de tiers. Cette contrainte entrave le développement de dApp et impose des solutions supplémentaires pour les constructions sous contrat multipartites. 

De plus, les caractéristiques complexes et de bas niveau de BitVM impliquent que la construction de produits fonctionnels tirant parti de cette base peut s'étendre sur plusieurs années. Un développement et une innovation substantiels sont impératifs pour traduire cette technologie fondamentale en applications pratiques.

Pour une analyse approfondie et détaillée, n'hésitez pas à lire un BitVM Whitepaper - https://bitvm.org/bitvm.pdf 

Conclusion

Le protocole RGB est un développement technique dans l'écosystème Bitcoin, introduisant des fonctionnalités de mise en œuvre de contrats intelligents et d'émission de jetons directement liés au réseau Bitcoin. Ceci est réalisé grâce à une combinaison de validation côté client et d’utilisation de sceaux à usage unique, qui relient les jetons aux UTXO de Bitcoin tout en préservant la confidentialité des transactions.

L'un des principaux avantages techniques du RVB est son approche de l'évolutivité et de la confidentialité. En déplaçant l'essentiel du travail de validation hors de la blockchain Bitcoin et en utilisant des méthodes cryptographiques pour la vérification des transactions, RGB réduit efficacement la charge de données sur la blockchain. Cette approche est propice au maintien de l’efficacité du réseau, d’autant plus que les volumes de transactions augmentent.

La compatibilité de RGB avec le Lightning Network est un autre aspect important, permettant un traitement des transactions plus évolutif et plus efficace. Cette fonctionnalité est particulièrement pertinente compte tenu de la demande croissante de méthodes de transaction plus rapides et plus rentables dans le domaine des cryptomonnaies.

Cependant, la nature complexe de la technologie RVB présente des défis en termes d’accessibilité et de compréhension pour les utilisateurs. L’architecture du protocole et les méthodes cryptographiques avancées utilisées peuvent être difficiles à comprendre et à mettre en œuvre, en particulier pour ceux qui découvrent la technologie blockchain. Cette complexité pourrait entraver une adoption plus large et un engagement des utilisateurs.

De plus, bien que RGB améliore la confidentialité en gardant les données contractuelles hors de la blockchain, cet aspect soulève également des questions sur la vérifiabilité des données et la capacité d'auditer les transactions, qui sont cruciales pour certaines applications et la conformité réglementaire.

La dernière mise à jour de RGB, la version 0.10, le positionne comme un concurrent notable dans le paysage évolutif des technologies blockchain, en particulier face aux protocoles émergents tels que Taproot Assets et BitVM. Contrairement à Taproot Assets, qui se concentre sur l'exploitation du modèle UTXO de Taproot pour l'émission de jetons sur le réseau Bitcoin, RGB se distingue par ses fonctionnalités avancées de confidentialité et sa gestion des données hors chaîne, offrant une approche distincte de la fonctionnalité de contrat intelligent et de la gestion des jetons.

De même, alors que BitVM introduit un nouveau concept d'informatique décentralisée sur Bitcoin, les avancées de la version 0.10 de RGB en matière de validation côté client, d'interfaces contractuelles et d'un système de type strict présentent son approche unique visant à améliorer l'évolutivité et l'interaction des utilisateurs au sein de l'écosystème Bitcoin. Ces améliorations mettent en évidence les prouesses de RGB à relever les défis d’évolutivité et d’efficacité, domaines dans lesquels les protocoles traditionnels et émergents sont souvent confrontés à des limites.

La simplification des dépendances et des processus d'intégration dans la dernière version de RGB indique en outre l'accent mis sur l'expérience utilisateur et la stabilité du système, ce qui le distingue de ses concurrents. Cela positionne RGB non seulement comme une plate-forme robuste pour les contrats intelligents et l’émission de jetons axés sur la confidentialité et évolutifs, mais également comme une solution avant-gardiste dans l’espace plus large de la blockchain.

En conclusion, le protocole RGB constitue un développement technologique important au sein du réseau Bitcoin, offrant des capacités avancées pour les contrats intelligents et l’émission de jetons. Il aborde les questions clés d’évolutivité et de confidentialité, mais se heurte à des défis en termes de complexité et d’auditabilité potentielle. Le développement en cours et les futures itérations du protocole se concentreront probablement sur l’équilibre entre ces capacités avancées avec l’accessibilité des utilisateurs et les considérations réglementaires.

Références des termes : 

1. Turing terminé : En termes pratiques, le système peut exécuter n’importe quel problème informatique avec suffisamment de temps et de mémoire. La plupart des langages de programmation modernes sont Turing-complets, ce qui signifie leur capacité théorique à résoudre n'importe quel problème informatique.
   
2. Schéma: Un schéma de contrat sert de code réel pour un contrat intelligent, qui peut être utilisé comme « modèle de contrat » par les émetteurs sans qu'il soit nécessaire de coder ou d'auditer le code personnalisé fourni par des sources externes. Le schéma RVB n'est pas un script mais une structure de données.
   
3. Contrats de journaux discrets (DLC) dans le contexte des chaînes publiques sont des contrats intelligents spécialisés utilisés principalement dans le réseau Bitcoin. Ils permettent l'exécution privée et efficace d'accords financiers complexes basés sur des événements externes, comme les prix des actifs. Les DLC fonctionnent hors chaîne, préservant la confidentialité des détails du contrat et de l'identité des participants. Ils utilisent des sources de données externes, ou oracles, pour la résolution des contrats. Lorsqu'ils sont intégrés aux canaux publics, les DLC améliorent l'évolutivité en permettant le règlement de plusieurs transactions sans encombrer la blockchain, ce qui les rend idéaux pour les transactions financières privées et efficaces qui dépendent des résultats du monde réel.
   
4. tempête – stockage sans confiance basé sur un séquestre utilisant des preuves zk. Storm combine un stockage sans confiance basé sur le dépôt avec des preuves sans connaissance pour faciliter les transactions sécurisées et privées. Dans ce système, les données ou les actifs sont conservés sous séquestre et publiés uniquement lorsque des conditions spécifiques sont remplies, garantissant ainsi un environnement sans confiance dans lequel aucune autorité centrale n'est nécessaire. L'intégration de zk-proofs permet de vérifier ces transactions tout en conservant la plus grande confidentialité, car elles permettent la validation des données sans révéler aucun détail sous-jacent.
   
5. Prométhée – informatique distribuée sans confiance basée sur l’arbitrage. Prometheus représente une approche de l'informatique décentralisée, combinant des mécanismes d'arbitrage pour la résolution des litiges, des interactions sans confiance pour des opérations sécurisées et décentralisées et l'efficacité des canaux étatiques pour la gestion informatique hors chaîne.
   
6. A Ordinateur de jeu d'instructions réduit est un type d'architecture de microprocesseur qui utilise un petit ensemble d'instructions hautement optimisé plutôt que l'ensemble d'instructions hautement spécialisé que l'on trouve généralement dans d'autres architectures.