Avant-propos

L'émission d'actifs basés sur la BTC a toujours été un sujet brûlant. Des premières Colored Coins en 2011 au récent protocole Ordinal, la communauté BTC a toujours été capable de trouver de nouveaux acteurs et de nouveaux consensus, mais peu d'entre eux sont restés en place. Cependant, Lightning Labs a dévoilé des plans ambitieux pour développer des monnaies stables basées sur les actifs Taproot. Tether a également annoncé qu'il utiliserait le protocole RGB pour frapper des USDT sur la couche 1 de Bitcoin.

Cela signifie que le célèbre OmniLayer (anciennement Mastercoin) n'est plus le plus grand acteur de l'écosystème BTC. Et les protocoles de validation côté client (CSV) commencent à entrer dans la vision de tous. Ces protocoles permettent non seulement de maintenir l'intégrité des protocoles traditionnels des actifs Bitcoin, mais aussi d'améliorer l'évolutivité. Cependant, l'existence d'un éventail de protocoles d'actifs au sein de l'écosystème Bitcoin soulève des questions pertinentes : En quoi diffèrent-ils les uns des autres, et comment naviguer et saisir les opportunités dans ce paysage ?

Cet article vise à guider les lecteurs à travers une revue complète des différents protocoles d'actifs qui ont émergé dans l'histoire de Bitcoin. En outre, il cherche à approfondir les trajectoires potentielles d'évolution des protocoles d'actifs basés sur le bitcoin dans un avenir prévisible.

Pièces de monnaie colorées

Le concept des "Colored Coins" a été formulé pour la première fois par Yoni Assia, aujourd'hui PDG d'eToro, dans son article fondateur "bitcoin 2.X (aka Colored bitcoin)", publié le 27 mars 2012. L'article affirmait que la technologie sous-jacente de Bitcoin était aussi fondamentale et sans faille que le HTTP pour l'internet. C'est pourquoi le protocole du jeton Colored Coins a été conçu sur la base de la BTC.

Yoni Assia a imaginé la création d'économies BTC 2.0 grâce à cette innovation, permettant à n'importe quelle communauté de générer plusieurs monnaies de cette manière. L'utilisation de la technologie sous-jacente de Bitcoin pour le règlement des transactions et la prévention de la double dépense était, à l'époque, une idée pionnière.

Colored Coins est un protocole conçu pour émettre des actifs sur la blockchain Bitcoin. Il fonctionne en "colorant" une fraction spécifique de bitcoins pour qu'ils correspondent à d'autres actifs. Ces bitcoins marqués conservent leur fonctionnalité d'origine, mais ils représentent également un autre actif ou une autre valeur. La question pressante était toutefois de savoir comment cette idée pouvait se concrétiser sur le réseau Bitcoin.

Le 3 juillet 2014, ChromaWay a fait un grand pas en avant en développant le protocole EPOBC (Enhanced Colored Coins Order-based Protocol), qui a grandement simplifié le processus de création de pièces colorées pour les développeurs. Il s'agit du premier protocole à utiliser la fonction OP_RETURN de Bitcoin Script.

Le résultat est le suivant :

Une telle mise en œuvre est très concise, mais elle pose également de nombreux problèmes :

1. Question de la fongibilité et de la valeur minimale de liaison En liant 1000 sats dans la transaction de genèse pour une pièce de couleur, l'unité minimale de cette pièce de couleur devient 1 sat. Cela signifie que l'actif ou le jeton peut théoriquement être divisé en un maximum de 1000 unités (mais dans la pratique, ce nombre est inférieur pour éviter les attaques de poussière). Par exemple, la valeur minimale des satoshi a été fixée à 546 SAT, et pour les Ordinals, elle est encore plus élevée).
2. Problèmes de validation Afin de déterminer l'authenticité et la propriété d'une pièce colorée, l'historique de ses transactions doit être retracé et validé depuis la transaction initiale jusqu'à l'UTXO actuelle. Il faut donc développer des portefeuilles dédiés, des nœuds complets et même des scanners.
3. Risque potentiel de censure par les mineurs ColoredTransaction présente des caractéristiques distinctes, telles que l'écriture de métadonnées dans la sortie, ce qui entraîne un risque de censure par les mineurs.

Les Colored Coins sont essentiellement un système de suivi des actifs qui utilise les règles de validation de Bitcoin pour suivre les transferts d'actifs. Toutefois, pour prouver qu'une sortie spécifique (txout) représente un actif particulier, vous devez fournir toute la chaîne de transferts depuis l'origine de l'actif. Cela signifie que la validation d'une transaction peut nécessiter une longue chaîne de preuves. Pour y remédier, des propositions telles que OP_CHECKCOLORVERIFY ont été faites pour aider à valider les transactions de Colored Coin directement sur BTC, mais la proposition n'a pas été adoptée.

La première ICO en crypto-monnaie : Mastercoin

Le concept de Mastercoin a été initialement proposé par J.R. Willett. En 2012, il a publié un livre blanc intitulé "The Second Bitcoin Whitepaper", qui expose l'idée de créer de nouveaux actifs ou jetons sur la blockchain Bitcoin existante. Ce concept a fini par être connu sous le nom de "MasterCoin", qui a ensuite été rebaptisé "Omni Layer".

En 2013, le projet Mastercoin a réalisé une première version de ce que l'on appelle aujourd'hui une ICO (Initial Coin Offering) et a réussi à lever des millions de dollars. Cette opération est considérée comme la première ICO de l'histoire. L'une des applications les plus remarquables de Mastercoin est Tether (USDT), un stablecoin fiat-collatéralisé bien connu, qui a été initialement émis sur la couche Omni.

En fait, l'idée du Mastercoin a précédé celle des Colored Coins. Si nous en parlons en second lieu, c'est parce que MasterCoin est une solution relativement plus complète que les Colored Coins. MasterCoin a mis en place une couche de nœuds complète, offrant des fonctionnalités plus complexes telles que les contrats intelligents. En revanche, Colored Coins est plus simple et plus direct, et se concentre principalement sur la "coloration" ou le marquage des UTXOs de Bitcoin pour représenter d'autres actifs.

La principale différence entre les deux est que, sur la blockchain, le Mastercoin enregistre uniquement divers types de transactions et ne stocke pas les informations relatives aux actifs. Dans les nœuds du Mastercoin, une base de données du modèle d'état est maintenue en analysant les blocs Bitcoin, et cette base de données réside dans les nœuds hors de la blockchain.

Comparé aux Colored Coins, le Mastercoin peut exécuter une logique plus complexe. En outre, comme il n'enregistre ni ne vérifie les états sur la blockchain, ses transactions n'ont pas besoin d'être consécutives (colorées en continu).

Toutefois, pour mettre en œuvre la logique complexe de Mastercoin, les utilisateurs doivent faire confiance à l'état conservé dans la base de données hors chaîne au sein des nœuds ou exécuter leurs propres nœuds Omni Layer pour effectuer des vérifications.

En résumé :

La principale différence entre le Mastercoin et les Colored Coins est que le Mastercoin ne conserve pas toutes les données nécessaires au protocole sur la blockchain. Au lieu de cela, il s'appuie sur le système de consensus de Bitcoin pour gérer ses propres publications et commandes de transactions, puis il maintient l'état dans une base de données hors chaîne.

Selon les informations fournies par OmniBolt : Omni Layer propose un nouveau protocole d'actifs UBA (UTXO Based Asset) à Tether, qui utilisera la mise à jour Taproot. Ce protocole intégrera des informations sur les actifs dans la feuille de tapotement, ce qui permettra des fonctions telles que les paiements conditionnels. Parallèlement, OmniBolt travaille à l'intégration de Stark dans l'infrastructure du réseau Lightning de l'Omni Layer.

Le concept de validation côté client

Pour comprendre le concept de validation côté client (CSV), il faut remonter à l'année qui a suivi l'émergence des Colored Coins et de Mastercoin, c'est-à-dire 2013. Cette année-là, Peter Todd, l'un des premiers chercheurs sur le bitcoin et la cryptographie, a publié un article intitulé "Disentangling Crypto-Coin Mining : Timestamping, Proof-of-Publication, and Validation". Bien que le titre ne mentionne pas explicitement la validation côté client, une lecture attentive révèle qu'il s'agit de l'un des premiers écrits présentant ce concept.

Peter Todd a cherché des moyens de rendre le fonctionnement de Bitcoin plus efficace. Il a développé un concept plus complexe de validation côté client, basé sur l'idée d'horodatage. En outre, il a introduit le concept de "sceau à usage unique", qui sera mentionné plus loin.

Pour suivre le raisonnement de Peter Todd, nous devons d'abord comprendre quel problème Bitcoin résout réellement. Selon Peter Todd, le bitcoin répond à trois problèmes :

1. La preuve de la publication : L'essence de la preuve de la publication est de résoudre le problème de la double dépense. Par exemple, si Alice veut transférer des bitcoins à Bob, bien qu'elle ait signé une transaction de transfert à Bob, ce dernier peut ne pas savoir physiquement qu'une telle transaction existe. C'est pourquoi nous avons besoin d'un lieu public pour publier les transactions, et tout le monde peut interroger les transactions à partir de ce lieu.
2. Consensus de commande : Dans les systèmes informatiques, le temps physique que nous connaissons habituellement n'existe pas. Dans les systèmes distribués, le temps est souvent un horodatage de Lamport, qui ne fournit pas une mesure de notre temps physique mais ordonne nos transactions.
3. Validation (facultatif) : La validation sur Bitcoin consiste à vérifier les signatures et les montants transférés dans les transactions en BTC. Peter Todd estime toutefois que cette validation n'est pas nécessaire pour construire un système de jetons au-dessus de Bitcoin ; il s'agit simplement d'une option d'optimisation.

À ce stade, vous vous souvenez peut-être d'OmniLayer, dont nous avons parlé précédemment. OmniLayer lui-même ne délègue pas le calcul et la validation de l'état à Bitcoin, mais il réutilise la sécurité de Bitcoin. Colored Coins, quant à lui, confie le suivi de l'état à Bitcoin. L'existence de ces deux systèmes a déjà démontré que la validation ne doit pas nécessairement avoir lieu sur la blockchain.

Comment la validation côté client permet-elle de vérifier efficacement les transactions ?

Tout d'abord, examinons ce qui doit être vérifié :

1. État (vérification de la logique de la transaction)
2. Vérifiez que les entrées (TxIn) sont valides pour éviter les doubles dépenses.

Il est facile de remarquer que pour les actifs émis en bitcoins, chaque transaction nécessite une vérification de l'ensemble de l'historique des transactions concernées afin de s'assurer que les intrants référencés n'ont pas été dépensés et que l'état est correct. Ce n'est pas du tout pratique. Comment pouvons-nous donc améliorer la situation ?

Peter Todd suggère de simplifier ce processus en changeant l'objectif de la vérification. Au lieu de confirmer que la production n'a pas été dépensée deux fois, cette méthode vise à s'assurer que les intrants d'une transaction ont été publiés et qu'ils ne sont pas en conflit avec d'autres intrants. En ordonnant les entrées dans chaque bloc et en utilisant un arbre de Merkle, ce type de vérification peut être effectué plus efficacement car il ne nécessite qu'une petite partie des données à chaque fois, et non l'historique complet de la chaîne de l'entrée.

La structure de l'arbre d'engagement proposée par Peter Todd est la suivante :

CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CTxIn

Mais comment stocker un tel arbre d'engagement sur la blockchain ? C'est ici que nous pouvons introduire le concept de "scellé à usage unique".

Sceau à usage unique

Le sceau à usage unique est l'un des concepts fondamentaux pour comprendre le CSV. Il est similaire au scellé physique à usage unique utilisé pour protéger les conteneurs de marchandises. Un scellé à usage unique est un objet unique qui peut être fermé précisément une fois sur un message. En termes simples, un scellé à usage unique est un mécanisme abstrait utilisé pour éviter les doubles dépenses.

Le protocole SealProtocol comporte trois éléments et deux actions.

Éléments de base :

1. l : sceau
2. m : message, qui est l'information ou la transaction
3. w : témoin, quelqu'un ou quelque chose qui peut vérifier le sceau

Opérations de base : Il existe deux actions de base :

1. Close(l, m) → w : Fermer le sceau l sur le message m, en produisant un témoin w.
2. Verify(l, w, m) → bool : Vérifie si le sceau l a été fermé sur le message m.

La sécurité de la mise en œuvre d'un sceau à usage unique signifie qu'un attaquant ne peut pas trouver deux messages différents m1 et m2 tels que la fonction Verify renvoie un vrai pour le même sceau.

En termes simples, un sceau à usage unique garantit qu'un bien ou un élément de données n'est utilisé ou verrouillé qu'une seule fois. Dans le contexte du bitcoin, cela signifie généralement qu'un UTXO ne peut être dépensé qu'une seule fois. Ainsi, les résultats des transactions Bitcoin peuvent être considérés comme des sceaux à usage unique, et lorsqu'un résultat est utilisé comme entrée dans une autre transaction, ce sceau est "brisé" ou "utilisé".

Pour les actifs sur Bitcoin, Bitcoin lui-même fait office de "témoin" (w) pour le sceau à usage unique. En effet, pour vérifier une transaction Bitcoin, les nœuds doivent s'assurer que chaque entrée de la transaction fait référence à une UTXO valide et non dépensée. Si une transaction tente de dépenser deux fois un UTXO qui a déjà été utilisé, les règles de consensus de Bitcoin et le réseau de nœuds honnêtes rejetteront cette transaction.

En d'autres termes, c'est encore plus simple :

Un sceau à usage unique traite toute blockchain comme une base de données, où l'on stocke un engagement envers un certain message et où l'on maintient son statut comme étant dépensé ou non dépensé.

En résumé, les actifs qui utilisent la validation côté client présentent les caractéristiques suivantes :

1. Stockage des données hors chaîne : L'historique des transactions, la propriété et les autres données pertinentes des actifs utilisant la validation côté client sont principalement stockés en dehors de la chaîne. Cela réduit considérablement le besoin de stockage de données sur la chaîne et contribue à renforcer la protection de la vie privée.
2. Mécanisme d'engagement : Bien que les données relatives aux actifs soient stockées en dehors de la chaîne, les modifications ou les transferts de ces données sont enregistrés dans la chaîne par le biais d'engagements. Ces engagements permettent aux transactions sur la chaîne de faire référence à des états hors chaîne, ce qui garantit l'intégrité et l'immuabilité des données hors chaîne.
3. Témoins sur la chaîne (pas nécessairement BTC) : Même si la plupart des données et de la validation ont lieu hors chaîne, les actifs utilisant la validation côté client peuvent toujours tirer parti de la sécurité de la blockchain sous-jacente (preuve de publication, ordre de transaction) grâce à des engagements intégrés dans la chaîne.
4. Travail de validation effectué du côté du client : La majeure partie du travail de validation est effectuée sur l'appareil de l'utilisateur. Cela signifie que chaque nœud du réseau n'a pas besoin de participer à la validation de chaque transaction ; seules les parties concernées doivent vérifier la validité de la transaction.

Pour ceux qui utilisent des actifs avec validation côté client, il y a un point supplémentaire à noter :

Lors de la transaction et de la validation d'actifs avec une validation hors chaîne côté client, il est nécessaire non seulement de présenter la clé privée qui détient l'actif, mais aussi de fournir une preuve complète du chemin de Merkle pour l'actif correspondant.

RGB, le pionnier du CSV

Le concept de RVB a été proposé par Giacomo Zucco, une figure bien connue de la communauté, après 2015. C'était une période où Ethereum était en plein essor, où les ICO (Initial Coin Offerings) proliféraient et où de nombreuses tentatives ont été faites pour créer des projets au-delà du Bitcoin, tels que Mastercoin et Colored Coins.

Giacomo Zucco a été déçu par cette évolution. Il estime qu'aucun de ces projets n'est à la hauteur du potentiel de Bitcoin et que les tentatives précédentes de mise en œuvre de jetons sur Bitcoin sont inadéquates. À cette époque, il rencontre Peter Todd et se passionne pour les idées de ce dernier sur la validation côté client (CSV). C'est ainsi qu'il a proposé l'idée du RVB.

Outre les caractéristiques susmentionnées des actifs qui utilisent la validation côté client, la principale différence avec RGB et les protocoles d'actifs antérieurs est l'ajout d'une VM (machine virtuelle) d'exécution pour l'exécution de contrats Turing-complets. Pour garantir la sécurité des données contractuelles, un schéma et une interface ont été conçus. Le schéma, similaire à celui d'Ethereum, déclare le contenu et les fonctions d'un contrat, tandis que l'interface est responsable de la mise en œuvre de fonctions spécifiques, un peu comme les interfaces dans les langages de programmation.

Les schémas de ces contrats sont chargés de restreindre les comportements qui dépassent les attentes pendant l'exécution de la VM. Par exemple, RGB20 et RGB21 sont respectivement chargés d'imposer certaines restrictions sur les jetons fongibles et non fongibles lors des transactions.

Le mécanisme d'engagement utilisé dans RGB, Pedersen Hash

Son avantage réside dans sa capacité à s'engager sur une valeur sans la divulguer. L'utilisation du hachage de Pedersen pour construire un arbre de Merkle signifie que vous pouvez créer un arbre de Merkle protégeant la vie privée et pouvant cacher ses valeurs. Cette structure est utile dans certains protocoles de préservation de la vie privée, tels que certains projets de crypto-monnaie anonymes. Cependant, il peut ne pas convenir aux actifs CSV, qui seront mentionnés plus loin en comparaison avec Taproot Assets.

Conception de machines virtuelles pour la simplicité RGB → AluVM

RGB visait non seulement à mettre en œuvre un protocole d'actifs validé côté client, mais aussi à étendre l'exécution d'une machine virtuelle Turing-complète et la programmation de contrats. Initialement, le RGB prétendait utiliser un langage de programmation appelé Simplicity, qui génère une preuve d'exécution et permet une vérification formelle (pour éviter les bogues) des contrats rédigés dans ce langage. Cependant, le développement de ce langage ne s'est pas déroulé comme prévu, entraînant des complications qui ont finalement entravé l'ensemble du protocole RVB. Finalement, RGB a commencé à utiliser une VM appelée AluVM, développée par Maxim, dans le but d'éviter tout comportement non défini, similaire à l'original Simplicity. Le nouveau AluVM serait remplacé à l'avenir par un langage de programmation appelé Contractum, s'éloignant ainsi de l'utilisation actuelle de Rust.

Sens de la mise à l'échelle de la couche RVB 2 : Lightning network ou Sidechain ?

Les actifs validés côté client ne peuvent pas être échangés en continu et en toute sécurité en dehors de la chaîne, car ils dépendent toujours de L1 pour la publication et la commande des transactions. Cela signifie qu'en l'absence d'une solution de mise à l'échelle de niveau 2, leur vitesse de transaction est toujours limitée par la vitesse de production des blocs de leur témoin L1. Cela signifie que si les transactions du RVB sont effectuées directement sur Bitcoin, dans le respect d'exigences strictes en matière de sécurité, le délai entre deux transactions liées devrait être d'au moins dix minutes (temps de blocage de BTC), ce qui est souvent d'une lenteur inacceptable.

Le RVB et le réseau Lightning

En termes simples, le Lightning Network fonctionne en demandant aux parties à une transaction de signer un ensemble de contrats (transactions d'engagement) en dehors de la chaîne. Ces contrats garantissent que si l'une des parties viole l'accord, la partie lésée peut soumettre le contrat (transaction d'engagement) à la CTB pour règlement, récupérer ses fonds et pénaliser le contrevenant. En d'autres termes, le Lightning Network garantit la sécurité des transactions hors chaîne par le biais d'un protocole et d'une conception théorique des jeux.

RGB pourrait construire sa propre infrastructure Lightning Network en concevant des détails de contrat de canal de paiement adaptés à RGB lui-même. Toutefois, la mise en place d'une telle infrastructure n'est pas aisée en raison de la grande complexité du Lightning Network, surtout si l'on tient compte des années de travail de Lightning Labs dans ce domaine et de la part de marché de LND de plus de 90 %.

Sidechain Prime de RGB

Le LNP-BP, qui gère actuellement le protocole RGB, a publié en juin 2023 une proposition de Maxim pour une solution de mise à l'échelle des actifs validée côté client, appelée Prime. Maxim y critique les solutions existantes de mise à l'échelle de la sidechain et du Lightning Network, dont le développement est trop complexe. Il s'est dit convaincu qu'en dehors de Prime, les autres méthodes d'expansion, y compris les canaux Lightning multi-nœuds de NUCLEUS et les usines de canaux Ark/Enigma, nécessiteraient plus de deux ans de développement. Cependant, Prime pourrait être achevé en un an seulement.

Prime n'est pas conçue comme une blockchain traditionnelle. Il s'agit plutôt d'une couche modulaire de publication d'épreuves créée spécifiquement pour la validation côté client. Il se compose de quatre éléments principaux :

1. Service d'horodatage : Ce service peut finaliser une séquence de transactions en seulement 10 secondes.
2. Épreuves : Elles sont stockées sous la forme d'arbres de Merkle partiels (PMT) et sont produites et publiées avec les en-têtes de blocs.
3. Scellés à usage unique : Il s'agit d'un protocole abstrait de scellés à usage unique conçu pour éviter les doubles dépenses. Lorsqu'il est mis en œuvre sur Bitcoin, il peut être lié à des UTXO, de manière similaire à la conception actuelle de RGB.
4. Protocole de contrat intelligent : Contrats partagés pour RGB (qui peuvent être remplacés)

Nous voyons donc que pour résoudre le problème des délais de confirmation des transactions dans RGB, Prime utilise un service d'horodatage pour confirmer rapidement les transactions hors chaîne et les regrouper avec des identifiants dans des blocs. Dans le même temps, les preuves de transaction sur Prime peuvent être consolidées par le biais des PMT, puis ancrées sur la BTC à la manière d'un point de contrôle.

Protocole CSV Assets basé sur Taproot : Actifs Taproot

Taproot Assets est un protocole d'actifs CSV basé sur Taproot, conçu pour émettre des actifs sur la blockchain Bitcoin. Ces actifs peuvent être échangés instantanément, en grandes quantités et à faible coût via le réseau Lightning. Le cœur de Taproot Assets est l'utilisation de la sécurité et de la stabilité de Bitcoin avec la vitesse, l'évolutivité et le faible coût du Lightning Network. Le protocole a été conçu et développé par roasbeef, le directeur technique de Lightning Labs. Roasbeef est probablement la seule personne sur la planète à avoir personnellement dirigé le développement d'un client Bitcoin (BTCD) et d'un client Lightning Network (LND), démontrant ainsi une profonde compréhension de BTC.

Les transactions Taproot ne comportent que le hachage de la racine du script de l'actif, ce qui rend difficile pour les observateurs externes d'identifier si elles impliquent des actifs Taproot, car le hachage lui-même est générique et peut représenter n'importe quelles données. Avec la mise à jour Taproot, Bitcoin a acquis la capacité d'exécuter des contrats intelligents (TapScript). Sur cette base, l'encodage des actifs de Taproot Assets crée essentiellement une définition de jeton similaire à l'ERC20 ou à l'ERC721. Ainsi, Bitcoin acquiert non seulement la capacité de définir des actifs, mais aussi celle de rédiger des contrats intelligents, jetant ainsi les bases d'une infrastructure de contrats intelligents pour Bitcoin.

La structure d'encodage de Taproot Assets est la suivante :

par roasbeef, directeur technique de Lighting Labs

En tant que protocole d'actifs CSV, Taproot Assets a une conception plus concise que RGB. La plus grande différence entre Taproot Assets et RGB en termes d'évolutivité de l'application réside dans la VM d'exécution, Taproot Assets utilise la même VM TaprootScript que la VM native par défaut de BTC. Ces dernières années, de nombreuses recherches sur l'infrastructure de la BTC ont été basées sur TapScript, mais en raison de la lenteur de la mise à niveau de la BTC, elles ne peuvent être appliquées dans un court laps de temps, de sorte que l'on peut prédire que Taproot Assets sera un terrain d'essai pour ces nouvelles idées à l'avenir.

Différences entre Taproot Assets et RGB

1. Validation des transactions et convivialité des nœuds légers

Taproot Assets, grâce à la mise en œuvre d'un arbre de somme, présente une efficacité de vérification et une sécurité élevées. Il permet de vérifier l'état et d'effectuer des transactions simplement en possédant une preuve, sans avoir à parcourir l'ensemble de l'historique des transactions. En revanche, l'utilisation par le RGB des engagements de Pedersen rend difficile la vérification effective de la validité des données d'entrée. Par conséquent, le RVB nécessite de retracer l'historique des transactions des intrants, ce qui peut devenir une charge importante lorsque les transactions s'accumulent au fil du temps. La conception de l'arbre de somme Merkel permet également à Taproot Assets de faciliter la vérification des nœuds légers, une fonctionnalité qui n'était pas disponible auparavant dans les protocoles d'actifs construits au-dessus de Bitcoin.

2. VM d'exécution

Taproot Assets a été développé en réponse à la mise à jour Taproot du réseau Bitcoin. Il utilise TaprootScriptVM, qui est le moteur d'exécution de scripts fourni avec Bitcoin suite à la mise à jour de Taproot. En outre, il utilise vPSBT, une variante du PSBT de Bitcoin, ce qui indique qu'une fois que le mécanisme de canal éclair de Taproot Assets sera développé, il pourra immédiatement réutiliser toute l'infrastructure actuelle de LND (Lightning Network Daemon), ainsi que les produits précédents de Lightning Labs (LND détient actuellement plus de 90 % de parts de marché dans le réseau éclair). De plus, la récente proposition populaire de BitVM est basée sur TaprootScript, ce qui signifie théoriquement que toutes ces améliorations pourraient éventuellement bénéficier à Taproot Assets.

Cependant, le fonctionnement du RVB est quelque peu différent. Sa machine virtuelle et ses règles de validation (SCHEMA) font partie d'un système autonome, formant un écosystème quelque peu fermé. Le RGB opère au sein de son propre écosystème et sa relation avec l'écosystème plus large du bitcoin n'est pas aussi étroite que certains pourraient le penser. Par exemple, en ce qui concerne la mise à niveau de Taproot, la seule interaction réelle de RGB est l'encodage des données d'engagement sur la blockchain dans le Witness TapLeaf. Cela montre que le RGB et la mise à niveau de Taproot ne sont que très peu liés.

3. Contrats intelligents

Dans la mise en œuvre actuelle du RVB, les contrats et la VM sont fortement mis en avant. Cependant, Taproot Assets ne semble pas se concentrer sur les contrats intelligents, du moins pas encore. La mise en œuvre actuelle du RVB n'a pas encore expliqué comment les modifications de l'état global sont synchronisées avec les contrats individuels (UTXO). En outre, si les engagements de Pedersen peuvent garantir le montant total des actifs, on ne sait pas très bien comment les autres États seraient protégés contre les manipulations, car il n'y a pas eu beaucoup d'explications à ce sujet.

D'autre part, Taproot Assets a une conception plus simple, mais ne stocke actuellement que les soldes d'actifs et ne gère pas d'états plus complexes, ce qui rend les discussions sur les contrats intelligents prématurées. Cependant, selon Lightning Labs, il est prévu de se concentrer sur la conception de contrats intelligents pour Taproot Assets l'année prochaine.

4. Centre de synchronisation

Le principe de base mentionné plus haut concernant les actifs vérifiés côté client indique que la détention de la preuve est aussi importante que la détention de la clé privée. Cependant, il y a un risque de perdre la preuve puisqu'elle est conservée du côté du client. Comment y remédier ? Dans Taproot Assets, ce problème peut être évité grâce à l'utilisation d'un "univers". Un univers est un arbre de Merkle clair, vérifiable par le public, qui couvre un ou plusieurs actifs. Contrairement à une arborescence Taproot standard, un univers n'est pas utilisé pour conserver les actifs Taproot. Au lieu de cela, il s'engage sur un sous-ensemble d'un ou plusieurs historiques d'actifs.

Dans le système RGB, ce rôle est rempli par Storm, qui synchronise les données de preuve hors chaîne par l'intermédiaire d'un réseau peer-to-peer (p2p). Cependant, pour des raisons historiques liées à l'équipe de développement du RVB, ces équipes utilisent actuellement des formats de preuve incompatibles. L'équipe chargée de l'écosystème du RVB, la DIBA, a indiqué qu'elle développerait un "carbonado" pour résoudre ce problème, mais l'état d'avancement de ce projet n'est pas clair.

5. Mise en œuvre de l'ingénierie

Toutes les bibliothèques utilisées par Taproot Assets sont bien testées, car Lightning Labs a son propre client Bitcoin (BTCD), son propre client Lightning Network (LND), et un large éventail d'implémentations de bibliothèques de portefeuilles. En revanche, la plupart des bibliothèques utilisées pour la mise en œuvre de la norme RVB sont autodéfinies. Du point de vue des normes industrielles, la mise en œuvre du RVB en est encore au stade expérimental.

Un bref aperçu de l'avenir de la mise à l'échelle de la BTC

En poursuivant la discussion, il devient évident que les protocoles d'actifs validés par le client ont dépassé le cadre des protocoles traditionnels et s'orientent désormais vers une mise à l'échelle informatique.

Nombreux sont ceux qui affirment qu'à l'avenir, le bitcoin existera en tant qu'"or numérique", tandis que d'autres blockchains créeront des écosystèmes d'applications. Cependant, j'ai une opinion différente. Comme on le voit dans de nombreuses discussions sur les forums Bitcoin, on parle beaucoup des différentes monnaies parallèles et de leur durée de vie éphémère. La disparition rapide de ces alt-coins a transformé les capitaux et les efforts qui les entourent en bulles. Le bitcoin constitue déjà une base solide de consensus ; il n'est pas nécessaire d'élaborer de nouvelles solutions de niveau 1 (L1) uniquement pour les protocoles d'application. Ce que nous devrions faire, c'est tirer parti de Bitcoin, cette infrastructure robuste, pour construire un monde décentralisé à plus long terme.

Moins de calcul sur la chaîne, plus de vérification sur la chaîne

Du point de vue de la conception des applications, Bitcoin a très tôt choisi une philosophie centrée non pas sur le calcul sur la chaîne, mais sur la vérification (complétude de Turing et état pour les contrats intelligents). L'essence d'une blockchain est une machine d'état répliquée. Si le consensus d'une blockchain se concentre sur le calcul sur la chaîne, il est difficile d'affirmer que le fait que chaque nœud du réseau répète ces calculs est une approche raisonnable ou évolutive. Si l'accent est mis sur la vérification, la validation des transactions hors chaîne pourrait être l'approche la plus adaptée à l'évolutivité de Bitcoin.

Où la vérification a-t-elle lieu ? Ce point est crucial.

Pour les développeurs qui créent des protocoles au-dessus de Bitcoin, la manière d'utiliser Bitcoin pour la vérification critique, ou même de placer la vérification en dehors de la chaîne, et la manière de concevoir des schémas sécurisés, sont des questions qui relèvent des concepteurs de protocoles eux-mêmes. Ils ne devraient pas et n'ont pas besoin d'être associés à la chaîne elle-même. La façon de mettre en œuvre la vérification conduira à différentes solutions de mise à l'échelle pour la BTC.

Du point de vue des implémentations basées sur la vérification, nous disposons de trois directions pour la mise à l'échelle :

1.Vérification sur chaîne (OP-ZKP)

L'implémentation de l'OP-ZKP directement dans TaprootScriptVM permettrait de doter Bitcoin lui-même de la capacité d'effectuer la vérification ZKP. Associé à des protocoles de règlement conçus par Covenant, cela pourrait permettre de créer une solution de mise à l'échelle Zk-Rollup qui hériterait de la sécurité de Bitcoin. Cependant, contrairement au déploiement d'un contrat de vérification sur Ethereum, les mises à jour de Bitcoin sont intrinsèquement lentes, et l'ajout d'un op-code aussi spécialisé, qui pourrait nécessiter des mises à jour, est forcément un défi.

2. vérification sur semi-chaîne (BitVM)

La conception de BitVM garantit qu'elle n'est pas destinée à une logique de transaction ordinaire. Robin Linus a également indiqué que l'avenir de BitVM réside dans la création d'un marché inter-chaînes gratuit pour diverses SideChains. L'approche de BitVM est considérée comme semi-on-chain parce que la plupart des calculs de vérification ne se feront pas on-chain mais off-chain. La raison principale de la conception autour de la racine de Bitcoin est l'utilisation de TapScriptVM pour la vérification informatique lorsque cela est nécessaire, héritant théoriquement de la sécurité de Bitcoin. Ce processus génère également une chaîne de confiance pour la vérification, qui ne nécessite qu'un seul vérificateur honnête parmi "n" vérificateurs, connue sous le nom de "Optimistic Rollups".

BitVM entraîne une surcharge importante sur la chaîne, mais peut-il utiliser les preuves de fraude ZK pour gagner en efficacité ? La réponse est non, car la mise en œuvre des preuves de fraude ZK repose sur la capacité à effectuer la vérification ZKP sur la chaîne, ce qui nous ramène aux difficultés de l'approche OP-ZKP.

3. vérification hors chaîne (validation côté client, réseau Lightning)

La vérification complète en dehors de la chaîne fait référence aux protocoles d'actifs CSV et au réseau Lightning dont il a été question précédemment. Comme nous l'avons vu dans les discussions précédentes, il n'est pas possible d'empêcher totalement la collusion dans les conceptions de CSV. Ce que nous pouvons faire, c'est utiliser la cryptographie et la conception de protocoles pour maintenir les dommages causés par la collusion malveillante dans des limites contrôlables, rendant de telles actions non rentables.

Les avantages et les inconvénients de la vérification hors chaîne sont tout aussi clairs. L'avantage est qu'il utilise un minimum de ressources sur la chaîne et qu'il a un énorme potentiel d'évolutivité. L'inconvénient est qu'il est presque impossible d'hériter entièrement de la sécurité de Bitcoin, ce qui limite considérablement les types et les méthodes de transactions hors chaîne qui peuvent être effectuées. En outre, la vérification hors chaîne implique également que les données sont conservées hors chaîne, gérées par les utilisateurs eux-mêmes, ce qui impose des exigences plus élevées en matière de sécurité de l'environnement d'exécution du logiciel et de stabilité du logiciel.

Tendance de l'évolution de l'échelle

Actuellement, les solutions populaires de la couche 2 sur Ethereum, en termes de paradigme, valident les calculs de la couche 2 par le biais de la couche 1, ce qui signifie que le calcul de l'état est déplacé vers la couche 2, mais que la vérification est toujours conservée à la couche 1. À l'avenir, nous pourrions de la même manière pousser les calculs de vérification hors de la chaîne, ce qui libérerait encore davantage les performances de l'infrastructure actuelle de la blockchain.

Clause de non-responsabilité：

1. Cet article est repris de[mirror]. Tous les droits d'auteur appartiennent à l'auteur original[Ben77]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.