Transfert hors chaîne : Le chemin évolutif des protocoles d'actifs bitcoin

Introduction

L'émission d'actifs basés sur la BTC a toujours été un sujet brûlant. De la première apparition des Colored Coins en 2011 au très populaire Ordinal Protocol, la communauté BTC a toujours été en mesure de faire émerger de nouveaux acteurs et de nouveaux consensus. Cependant, peu d'entre eux ont résisté à l'épreuve du temps. Avec l'annonce par l'ambitieux Lightling Labs de son projet de création d'une Stable Coin au-dessus de Taproot Assets, et la déclaration par Tether de son choix du RGB pour frapper des USDT sur la première couche de Bitcoin, il est clair que l'OmniLayer (Mastercoin), autrefois célèbre, n'est plus le plus grand acteur de l'écosystème BTC. Les protocoles d'actifs CSV (Client-Side Validation) commencent à attirer l'attention. Ils diffèrent des protocoles d'actifs BTC traditionnels en intégrant également des caractéristiques d'évolutivité de Bitcoin. Mais face à une telle multitude de protocoles d'actifs dans l'écosystème de la BTC, il convient de se demander quelles sont leurs différences. Et comment choisir et trouver nos propres opportunités parmi ces nombreux protocoles d'actifs ?

Cet article vise à guider les lecteurs dans l'examen des différents protocoles d'actifs qui sont apparus dans l'histoire de Bitcoin, en se penchant sur la trajectoire potentielle des protocoles d'actifs basés sur Bitcoin dans un avenir prévisible.

Pièces de monnaie colorées

L'idée des pièces colorées a été proposée pour la première fois par Yoni Assia, l'actuel PDG d'eToro, dans un article écrit le 27 mars 2012 et intitulé "bitcoin 2.X (aka Colored bitcoin)". L'article postule que le bitcoin, en tant que technologie sous-jacente, est parfait, tout comme le HTTP est le fondement de l'internet. C'est pourquoi le protocole de jetons Colored Coins a été conçu sur la base de la réutilisation de la BTC.

Yoni Assia a cherché à créer une économie BTC 2.0 par le biais de cette méthode - n'importe quelle communauté pourrait créer une variété de monnaies de cette manière. Cette approche consistant à utiliser le bitcoin comme technologie sous-jacente pour compenser les transactions et éviter la double dépense était sans aucun doute une idée très audacieuse à l'époque.

En tant que protocole d'émission d'actifs basés sur le bitcoin, la méthode de Colored Coins consiste à "colorer" une certaine quantité de bitcoins pour représenter ces actifs. Ces bitcoins marqués restent fonctionnellement des bitcoins, mais ils représentent également un autre actif ou une autre valeur. Mais comment cette idée pourrait-elle être mise en œuvre sur Bitcoin ?

Le 3 juillet 2014, ChromaWay a développé un protocole Enhanced Pay-to-Script-Hash (P2SH) basé sur les pièces de monnaie colorées (EPOBC), qui simplifie le processus de création de pièces de monnaie colorées pour les développeurs. Ce protocole a été le premier à adopter la fonctionnalité OP_RETURN de Bitcoin Script.

La mise en œuvre finale est illustrée dans l'image suivante :

)

Cette mise en œuvre est très succincte, mais elle pose également de nombreux problèmes :

Jetons homogénéisés et valeur contraignante minimale

Dans la transaction Genesis, si une pièce de couleur est liée à 1000 sats, la plus petite unité de fractionnement de cette pièce de couleur est 1 sat. Cela signifie que l'actif ou le jeton peut être divisé ou attribué en un maximum de 1000 parties (mais ce n'est que théorique, pour éviter les attaques de poussière, par exemple, le sat était fixé à 546 SAT, et plus tard à ordinal qui est plus élevé).

Questions relatives à la vérification

Pour s'assurer de l'authenticité et de la propriété d'une pièce colorée, il est nécessaire de la retracer et de la vérifier depuis la transaction de création de l'actif jusqu'à l'UTXO actuel. Il est donc essentiel de développer un portefeuille dédié et de l'accompagner d'un nœud complet, voire d'un navigateur.

Risque potentiel de censure des mineurs

En raison des caractéristiques distinctes de ColoredTransaction, qui implique l'écriture d'informations de métadonnées dans la sortie, il existe une possibilité de censure de la part des mineurs.

Les pièces de couleur sont essentiellement un système de suivi des actifs, utilisant les règles de vérification de Bitcoin pour suivre les transferts d'actifs. Toutefois, pour prouver qu'une sortie spécifique (txout) représente un certain actif, il est nécessaire de suivre toute la chaîne de transfert depuis l'origine de l'actif jusqu'à aujourd'hui. Cela signifie que la vérification de la légitimité d'une transaction peut nécessiter une longue chaîne de preuves. Pour résoudre ce problème, une proposition a été faite pour OP_CHECKCOLORVERIFY afin d'aider à vérifier directement l'exactitude des transactions de Colored Coins sur BTC, mais cette proposition n'a pas été adoptée.

La première ICO dans l'industrie des crypto-monnaies : Mastercoin

Le concept initial de Mastercoin a été proposé par J.R. Willett. En 2012, il a publié un livre blanc intitulé "The Second Bitcoin Whitepaper", qui décrit le concept de création de nouveaux actifs ou jetons sur la blockchain existante de Bitcoin, connue plus tard sous le nom de "MasterCoin". Il a ensuite été rebaptisé Omni Layer.

Le projet Mastercoin a organisé une première vente de jetons (ce que nous appelons aujourd'hui une ICO ou Initial Coin Offering) en 2013, qui a permis de lever des millions de dollars. Cette opération est considérée comme la toute première ICO de l'histoire. L'application la plus notable de Mastercoin est Tether (USDT), la monnaie stable fiat la plus connue, qui a été initialement émise sur la couche Omni.

En fait, le concept de Mastercoin est antérieur à celui des Colored Coins. La raison pour laquelle il est abordé en second lieu ici est que, comparé aux Colored Coins, Mastercoin est une solution relativement plus complexe. Mastercoin a mis en place une couche de nœuds complète, offrant ainsi des fonctionnalités plus complexes (telles que les contrats intelligents), tandis que Colored Coins était plus simple et plus direct, se concentrant principalement sur la "coloration" ou le marquage des UTXO de Bitcoin pour représenter d'autres actifs.

La principale différence avec les Colored Coins est que Mastercoin ne publie que les différents types de transactions sur la chaîne, sans enregistrer les informations relatives aux actifs. Dans les nœuds Mastercoin, une base de données de modèles d'état est maintenue en analysant les blocs Bitcoin dans les nœuds hors chaîne.

Comparé aux Colored Coins, le Mastercoin peut exécuter une logique plus complexe. Et parce qu'il n'enregistre pas l'état et n'effectue pas de validation sur la chaîne, ses transactions ne nécessitent pas de continuité (coloration continue).

Toutefois, pour mettre en œuvre la logique complexe de Mastercoin, les utilisateurs doivent se fier à l'état de la base de données hors chaîne des nœuds ou utiliser leurs propres nœuds Omni Layer à des fins de vérification.

En résumé :

La principale différence entre Mastercoin et Colored Coins est que Mastercoin a choisi de ne pas conserver toutes les données nécessaires au protocole sur la chaîne. Au lieu de cela, elle a utilisé de manière parasitaire le système de consensus de la BTC pour mettre en œuvre sa propre publication et son propre ordonnancement des transactions, tout en conservant 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 pour encoder les informations sur les actifs dans les feuilles de tap, permettant des fonctionnalités telles que les paiements conditionnels. Parallèlement, OmniBolt introduit Stark dans l'infrastructure Lightning Network d'OmniLayer.

Le concept de validation côté client

Pour comprendre le concept de validation côté client, 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 a publié un article : "Disentangling Crypto-Coin Mining : Timestamping, Proof-of-Publication, and Validation". Bien que le titre de l'article ne semble pas directement lié à la validation côté client, une lecture attentive révèle qu'il contient les premières réflexions sur la validation côté client.

Peter Todd, l'un des premiers chercheurs dans le domaine du bitcoin et de la cryptographie, a toujours été à la recherche d'une méthode permettant de rendre le fonctionnement du bitcoin plus efficace. Il a développé un concept plus complexe de validation côté client, basé sur le concept d'horodatage. En outre, il a introduit le concept de "sceau à usage unique", qui sera mentionné plus loin.

En suivant les réflexions de Peter Todd, commençons par comprendre les problèmes que le BTC (Bitcoin) a réellement résolus. Selon Peter Todd, la BTC a résolu trois problèmes :

Preuve de publication

L'essence de la preuve de publication est de résoudre le problème de la double dépense. Par exemple, Alice possède des bitcoins qu'elle souhaite transférer à Bob. Bien qu'elle signe une transaction pour la transférer à Bob, ce dernier peut ne pas être physiquement au courant de l'existence de la transaction. Il est donc nécessaire de disposer d'un lieu public pour publier les transactions, où tout le monde peut les consulter.

Consensus de l'ordre

Dans les systèmes informatiques, le temps physique que nous percevons habituellement n'existe pas. Dans les systèmes distribués, le temps est souvent représenté par des horodatages Lamport, qui ne mesurent pas notre temps physique mais ordonnent nos transactions.

Validation (facultatif)

La validation sur BTC fait référence à la vérification des signatures et des montants des transferts de BTC. Toutefois, Peter Todd estime que cette validation n'est pas nécessaire pour construire un système de jetons au-dessus de la BTC, mais qu'elle constitue plutôt une option d'optimisation.

À ce stade, vous pouvez penser à Ominilayer mentionné plus haut. Ominilayer ne délègue pas le calcul et la vérification de l'état à la CTB, mais utilise quand même la sécurité de la CTB. Les pièces de couleur, quant à elles, délèguent le suivi de l'état à la CTB. L'existence des deux démontre que la validation ne doit pas nécessairement se faire au niveau de la chaîne.

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

Voyons d'abord ce qui doit être validé :

• État (validation de la logique de transaction)

• Validité de l'entrée TxIn (pour éviter les doubles dépenses)

Il est évident que pour les actifs émis sur la BTC, chaque transaction nécessite une vérification de l'ensemble de l'historique de la transaction concernée afin de s'assurer que l'intrant référencé n'a pas été dépensé et que l'état est correct. C'est très inefficace. Comment l'améliorer ?

Peter Todd pense que nous pouvons simplifier ce processus en changeant l'objectif de la validation. Au lieu de confirmer qu'un produit n'a pas été dépensé deux fois, cette méthode se concentre sur la confirmation que les intrants de la transaction ont été publiés et 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 validation peut être effectué plus efficacement, car chaque validation ne nécessite qu'une petite partie des données, et non l'historique complet de la chaîne de cette entrée.

Peter Todd a proposé la structure suivante pour un arbre d'engagement :

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

Mais comment stocker un tel arbre d'engagement sur la chaîne ? Cela nous amène au concept de scellé à usage unique.

Sceau à usage unique

Le sceau à usage unique est l'un des concepts fondamentaux pour comprendre la validation côté client, à l'instar des sceaux physiques à usage unique utilisés pour protéger les conteneurs d'expédition de marchandises dans le monde réel. Un scellé à usage unique est un objet unique qui ne peut se refermer qu'une seule fois sur un message. En bref, un sceau à usage unique est un mécanisme abstrait utilisé pour empêcher la double dépense.

Pour SealProtocol, il y a trois éléments et deux actions.

Éléments de base :

1. l： sceller, c'est-à-dire sceller
2. m： message, message
3. In：witness, témoin

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

1. Close(l,m) → w : dans messagemupper closing seall, générer un witnessIn。
2. Verify(l,w,m) → bool : Verify seallAre you in the news?mis closed.

Deux messages différents ne peuvent pas être trouvés par un attaquanterm1etm2, et la fonction Verify renvoie le même sceau.

Tout d'abord, le sceau à usage unique est un concept qui garantit qu'un bien ou des données ne sont utilisés ou verrouillés qu'une seule fois. Dans le contexte du bitcoin, cela signifie généralement qu'un UTXO (unspent transaction output) ne peut être dépensé qu'une seule fois. Par conséquent, le résultat d'une transaction en bitcoins peut être considéré comme un sceau unique, et lorsque ce résultat est utilisé pour une autre transaction, le sceau est "brisé" ou "utilisé".

Pour les actifs CSV sur BTC, Bitcoin lui-même fait office de "témoin" scellé une seule fois. En effet, pour valider une transaction Bitcoin, un nœud doit vérifier 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é dépensé, les règles de consensus de Bitcoin et les nœuds honnêtes du réseau rejetteront la transaction.

Peut-on faire plus simple ?

sceau à usage unique En d'autres termes, toute blockchain est considérée comme une base de données. Nous stockons la promesse d'un certain message dans cette base de données d'une manière ou d'une autre, et nous maintenons un statut consommé ou à consommer pour ce message.

Oui, c'est aussi simple que cela.

En résumé, les actifs vérifiés par le client présentent les caractéristiques suivantes :

1. Stockage des données hors chaîne : La plupart des données relatives à l'historique des transactions, à la propriété et à d'autres aspects des actifs vérifiés par le client sont stockées en dehors de la chaîne. Cela réduit considérablement les besoins de stockage de données sur la chaîne et contribue à améliorer 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 seront enregistrés dans la chaîne par le biais d'engagements. Ces engagements permettent aux transactions de la chaîne de faire référence à des états hors chaîne, garantissant ainsi l'intégrité et la non-altération des données hors chaîne.
3. Témoin sur la chaîne (pas nécessairement BTC) : Bien que la plupart des données et des vérifications soient hors chaîne, les actifs vérifiés par le client peuvent toujours profiter de la sécurité de la chaîne sous-jacente (émission de preuves, ordre des transactions) par le biais d'engagements intégrés dans la chaîne.
4. La vérification se fait du côté du client : La majeure partie du travail de vérification est effectuée sur l'appareil de l'utilisateur. Cela signifie que tous les nœuds du réseau ne doivent pas participer à la vérification de chaque transaction, seuls les participants concernés doivent vérifier la validité de la transaction.

Pour ceux qui utilisent la vérification des actifs côté client, il y a un autre point à noter :

Lorsque vous effectuez des transactions hors chaîne et que vous vérifiez des actifs vérifiés par le client, vous devez non seulement montrer la clé privée qui détient l'actif, mais aussi prouver le chemin de merkel complet de l'actif correspondant.

Le pionnier de la validation côté client (CSV) : RVB

Le concept de RVB a été proposé par Giacomo Zucco, une figure bien connue de la communauté, après 2015. En raison de l'essor d'Ethereum et de la prolifération des ICO, et avant les ICO, de nombreuses personnes ont essayé de faire des choses en dehors du bitcoin, comme les projets Mastercoin et Colored Coins. .

Giacomo Zucco a exprimé sa déception. Il estime que ces projets sont inférieurs à Bitcoin et que les méthodes précédentes de mise en œuvre des jetons sur Bitcoin sont inappropriées. Au cours de ce processus, il a rencontré Peter Todd et a été fasciné par l'idée de Peter Todd de la validation côté client. Il a ensuite commencé à proposer l'idée duRGB.

La plus grande différence entre RGB et les protocoles d'actifs précédents est qu'en plus des caractéristiques mentionnées précédemment de vérification des actifs côté client, il ajoute également une VM d'exécution pour mettre en œuvre un moteur d'exécution de contrat Turing-complet. En outre, afin de garantir la sécurité des données contractuelles, un schéma et une interface sont également conçus. Schema est similaire à Ethereum, déclarant le contenu et les fonctions du contrat, tandis que Interface est responsable de la mise en œuvre de fonctions spécifiques, tout comme l'interface dans les langages de programmation.

Les schémas de ces contrats sont chargés de restreindre les comportements qui n'excèdent pas le comportement attendu lors de l'exécution de la vm, tels que RGB20 et RGB21, qui sont respectivement chargés de certaines restrictions sur les transactions de jetons fongibles et de jetons non fongibles.

Mécanisme d'engagement du RVB : Le hachage de Pedersen

En ce qui concerne les mécanismes d'engagement, le RGB adopte la méthode de Pedersen Hash. Son avantage est de pouvoir 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égé qui cache les valeurs qu'il contient. Cette structure peut être utilisée dans certains protocoles spécifiques de protection de la vie privée, tels que certains projets de crypto-monnaies anonymes. Cependant, il peut ne pas convenir aux actifs CSV, qui seront mentionnés plus loin dans la comparaison avec Taproot Assets.

La conception des machines virtuelles du RGB : De la simplicité à AluVM

RGB vise non seulement à mettre en œuvre un protocole d'actifs validé par le client, mais aussi à s'étendre à l'exécution de machines virtuelles Turing-complètes et à la programmation de contrats. Au début de sa conception, le RVB prétendait utiliser un langage de programmation appelé Simplicity. Ce langage a la particularité de générer une preuve d'exécution lors de l'exécution d'expressions, ce qui facilite la vérification formelle des contrats écrits dans ce langage (pour éviter les bogues). Cependant, le développement de cette langue n'a pas été idéal et a fini par rencontrer des difficultés. Cela a conduit directement à la naissance difficile du protocole RGB cette année-là. Finalement, RGB a commencé à utiliser AluVM, développé par Maxim, dans le but d'éviter tout comportement indéfini, similaire au Simplicity initial. Le nouveau AluVM serait remplacé à l'avenir par un langage de programmation appelé Contractum, qui utilise actuellement Rust.

L'orientation de l'expansion de la couche 2 de RGB : Lightning Network ou Sidechain ?

Les actifs validés par le client ne peuvent pas effectuer de transactions continues en toute sécurité hors de la chaîne. Comme les actifs validés par le client s'appuient toujours sur L1 pour la publication et le séquençage des transactions, leur vitesse de transaction est limitée par la vitesse de génération des blocs de leur témoin L1. Cela signifie que si les transactions du RGB 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 doit être d'au moins dix minutes (le temps de blocage de BTC). Il ne fait aucun doute qu'une telle vitesse de transaction est inacceptable dans la plupart des cas.

Le RVB et le réseau Lightning

En termes simples, le principe du Lightning Network est que les deux parties impliquées dans une transaction signent un ensemble de contrats (transactions d'engagement) en dehors de la chaîne. Ainsi, si l'une des parties viole le contrat, 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 l'autre partie. En d'autres termes, le Lightning Network garantit la sécurité des transactions hors chaîne grâce à la conception de protocoles et à la théorie des jeux.

RGB peut construire sa propre infrastructure Lightning Network en concevant des règles contractuelles pour les canaux de paiement qui lui conviennent, mais la complexité du Lightning Network est extrêmement élevée, et la construction de ce système n'est pas une tâche facile. En revanche, Lightnling Labs cultive ce domaine depuis de nombreuses années et LND détient une part de marché de plus de 90 %.

La chaîne latérale de RGB : Prime

LNP-BP, qui maintient actuellement le protocole RGB, et Maxim, qui publiera en juin 2023 une proposition appelée Prime, un système d'expansion des actifs validé par le client. Il y critique les schémas existants d'expansion de la sidechain et du réseau Lightning, qu'il juge trop complexes dans leur développement. Maxim a indiqué qu'il pensait qu'en plus de Prime, d'autres méthodes d'expansion incluaient les canaux NUCLEUS multi-nœuds Lightning et les usines de canaux Ark/Enigma, qui nécessitent tous deux plus de deux ans de développement. Toutefois, Prime peut être achevé en un an seulement.

Prime n'est pas une conception traditionnelle de la blockchain, mais une couche de publication de preuve modulaire conçue pour la validation du client, qui se compose de quatre parties :

1. Service d'horodatage : Détermination de la séquence d'une transaction en 10 secondes seulement.

2. Preuve : Stockée au format PMT, produite et publiée avec l'en-tête du bloc.

3. Sceau unique : Un protocole abstrait de sceau unique, garantissant la protection contre la double dépense. S'il est mis en œuvre sur Bitcoin, il peut être lié à UTXO, de la même manière que la conception actuelle de RGB.

4. Protocole de contrat intelligent : Contrats partageables - RGB (remplaçable).

Pour résoudre le problème des délais de confirmation des transactions RGB, Prime utilise un service d'horodatage pour confirmer rapidement les transactions hors chaîne et encapsuler les transactions et les identifiants dans des blocs. Simultanément, les preuves de transaction sur Prime peuvent être fusionnées par PMT et ensuite ancrées à BTC d'une manière similaire aux points de contrôle.

Protocole d'actifs CSV basé sur Taproot : Actifs Taproot

Taproot Assets est un protocole d'actifs CSV basé sur Taproot, utilisé pour émettre des actifs validés par le client sur la blockchain Bitcoin. Ces actifs peuvent être échangés instantanément, en grandes quantités et à faible coût par l'intermédiaire du réseau Lightning. Taproot Assets s'appuie sur la sécurité et la stabilité du réseau Bitcoin ainsi que sur la vitesse, l'évolutivité et le faible coût du Lightning Network. Ce protocole a été conçu et développé par roasbeef, directeur technique de Lightnling Labs, qui est peut-être la seule personne sur cette planète à avoir personnellement dirigé le développement d'un client Bitcoin (BTCD) et d'un client Lightning Network (LND), et qui a une connaissance approfondie 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é de réaliser des contrats intelligents (TapScript). Sur cette base, le codage des actifs de Taproot Assets s'apparente à la création d'une définition de jeton similaire à l'ERC20 ou à l'ERC721. Ainsi, le bitcoin a non seulement la fonction de définition des actifs, mais aussi la capacité de rédiger des contrats intelligents, ce qui jette les bases de l'infrastructure des contrats intelligents sur le bitcoin.

La structure de codage de Taproot Assets est la suivante : [La description s'arrête ici, indiquant la partie suivante de l'article qui approfondira probablement les détails techniques de la structure de codage de Taproot Assets].

Image via Lightning Labs CTO roasbeef

En tant que protocole d'actifs CSV (CoinSwap), Taproot Assets est conçu pour être plus rationnel que RGB. Ils maximisent l'utilisation des avancées actuelles dans l'écosystème BTC, telles que la mise à jour Taproot et PSBT (Partially Signed Bitcoin Transactions). La différence la plus significative entre Taproot Assets et RGB en termes d'extensibilité de l'application réside dans l'exécution de la VM (machine virtuelle). Taproot Assets utilise TaprootScriptVM, qui est identique à la VM native utilisée par BTC. Ces dernières années, de nombreuses études d'infrastructure pour la CTB ont été basées sur TapScript. Cependant, en raison de la lenteur des mises à niveau de la BTC, ces études n'ont pas été rapidement mises en œuvre, ce qui fait de Taproot Assets un terrain d'essai potentiel pour ces nouvelles idées.

Quelles sont les différences entre Taproot Assets et RGB ?

1. Validation des transactions et compatibilité avec les nœuds légers

Grâce à la mise en œuvre d'un arbre de somme, Taproot Assets peut se targuer d'une efficacité de vérification et d'une sécurité élevées (la vérification et la transaction peuvent être effectuées simplement avec une preuve de détention, sans parcourir l'ensemble de l'historique des transactions). En revanche, l'utilisation par le RGB des engagements de Pedersen entrave la validation effective des entrées, car le RGB doit retracer l'historique des transactions, ce qui devient une charge importante au fil du temps. La conception de l'arbre de somme de Merkel facilite également la vérification des nœuds légers dans les actifs Taproot, une caractéristique qui n'existait pas dans les protocoles d'actifs précédents construits sur la BTC.

1. VM d'exécution

Taproot Assets a vu le jour à la suite de la mise à niveau de Taproot. Ils utilisent TaprootScriptVM, le moteur d'exécution de scripts inhérent à Bitcoin après la mise à jour de Taproot, et vPSBT, une variante du PSBT de BTC. Une fois que le mécanisme de canal de foudre de Taproot Assets est achevé, il peut immédiatement réutiliser toute l'infrastructure actuelle de LND et les produits antérieurs de Lightning Labs (LND domine actuellement plus de 90 % du réseau de foudre). La récente proposition BitVM, également basée sur TaprootScript, prend théoriquement en charge Taproot Assets. Cependant, la VM et les règles de validation du RGB (SCHEMA) sont autonomes et forment un écosystème relativement fermé. Le développement de RGB est largement confiné à son écosystème, et son intégration à l'écosystème Bitcoin n'est pas aussi étroite qu'on pourrait le penser. Par exemple, le seul lien entre le RVB et la mise à niveau de la racine pivotante est l'encodage des données d'engagement de la chaîne dans la feuille pivotante du témoin.

1. Contrats intelligents

Dans la mise en œuvre actuelle du RGB, les contrats et la VM sont fortement mis en avant. Cependant, les contrats intelligents n'ont pas encore fait leur apparition dans Taproot Assets. Actuellement, le RGB n'explique pas comment les modifications de l'état global sont synchronisées avec les différents contrats (UTXO), ni comment les engagements de Pedersen, qui ne garantissent que la quantité totale d'actifs, détectent la falsification d'autres états. En revanche, Taproot Assets, avec sa conception plus simple, ne stocke actuellement que les soldes d'actifs et ne dispose pas d'un stockage d'état étendu, ce qui rend prématurée la discussion sur les contrats intelligents. Cependant, Lightning Labs a indiqué que Taproot Assets se concentrera sur la conception de contrats intelligents l'année prochaine.

1. Hub de synchronisation

Comme le montrent les principes de base de la vérification des actifs côté client, la détention de la preuve est aussi importante que la détention de la clé privée. Mais que se passe-t-il si la preuve est perdue du côté du client de l'utilisateur ? Dans Taproot Assets, cette question peut être abordée par le biais d'un "univers". L'univers est un arbre de Merkle clair, vérifiable par le public, couvrant un ou plusieurs actifs. Contrairement aux arbres d'actifs Taproot conventionnels, l'Univers n'héberge pas d'actifs Taproot. Au lieu de cela, il s'engage sur un sous-ensemble d'un ou plusieurs historiques d'actifs. Dans RGB, ce rôle est joué par Storm, qui synchronise les données de preuve hors chaîne via P2P. Cependant, pour des raisons historiques des équipes de développement du RVB, ces formats d'épreuves sont actuellement incompatibles. DIBA, l'équipe chargée de l'écosystème de RGB, serait en train de développer le "carbonado" pour résoudre ce problème, bien que les progrès ne soient pas clairs.

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

Toutes les bibliothèques utilisées par Taproot Assets sont éprouvées, Lightning Labs ayant son propre client Bitcoin (BTCD), son propre client Lightning Network (LND), et de nombreuses implémentations de librairies de portefeuilles. En revanche, la plupart des bibliothèques utilisées dans RGB sont auto-définies et, du point de vue des normes industrielles, la mise en œuvre de RGB en est encore au stade expérimental".

Brève discussion sur l'avenir de l'expansion de la CTB

Au fil de la discussion, il devient évident que la validation côté client des protocoles d'actifs a dépassé le domaine des spécifications de protocole et s'aventure vers l'expansion informatique.

Nombreux sont ceux qui pensent que le bitcoin existera à l'avenir en tant qu'or numérique, d'autres chaînes créant l'écosystème des applications. Cependant, j'ai un avis différent. Comme on peut le voir dans de nombreuses discussions sur les forums BTC, elles tournent souvent autour de divers altcoins et de leur existence éphémère. La disparition rapide de ces altcoins transforme les capitaux et les efforts qui les entourent en bulles. Grâce à la base consensuelle solide de Bitcoin, il n'est pas nécessaire de construire une nouvelle L1 pour les protocoles d'application. Ce que nous devons faire, c'est tirer parti de l'infrastructure robuste du bitcoin pour construire un monde décentralisé à plus long terme.

Moins de calculs sur la chaîne, plus de validation sur la chaîne

Du point de vue de la conception, Bitcoin a choisi très tôt de ne pas se concentrer sur le calcul sur la chaîne, mais plutôt sur une philosophie centrée sur la validation (complétude de Turing et état pour les contrats intelligents). La blockchain est essentiellement une machine d'état répliquée. Si le consensus d'une chaîne repose sur des calculs effectués au sein de la chaîne, il est difficile de justifier la raison d'être et l'évolutivité d'une répétition de ces calculs par tous les nœuds du réseau. Si nous nous concentrons sur la validation, la validation de l'efficacité des transactions hors chaîne pourrait être la stratégie d'expansion la plus appropriée pour la BTC.

Où se fait la validation ? C'est important

Pour les développeurs de protocoles au-dessus de Bitcoin, la manière d'utiliser Bitcoin pour les validations critiques, ou même de placer les validations en dehors de la chaîne, et la manière de concevoir des schémas de sécurité, sont des questions qui relèvent des concepteurs de protocoles eux-mêmes. Ceux-ci ne devraient pas et ne doivent pas être associés à la chaîne elle-même. Par conséquent, la manière dont la validation est mise en œuvre conduira à des stratégies d'expansion différentes pour la CTB.

Dans la perspective de la mise en œuvre de la validation, nous disposons de trois axes d'expansion :

1. 1. validation en chaîne (OP-ZKP)
2. Si OP-ZKP est mis en œuvre directement dans TaprootScriptVM, cela signifie l'intégration des capacités de validation ZKP dans la BTC elle-même, associée à des conceptions Covenant pour les protocoles de règlement, créant ainsi un plan d'expansion Zk-Rollup qui hérite de la sécurité de la BTC. Cependant, contrairement au déploiement d'un contrat de validation sur Ethereum, la lenteur du processus de mise à niveau de BTC, associée à un op-code aussi spécialisé et nécessitant potentiellement une mise à niveau, rend la tâche difficile.
4. 2. la validation en chaîne (BitVM)
5. La conception de BitVM n'est pas destinée à servir une logique de transaction régulière. 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 de ces calculs de validation ne se font pas on-chain, mais plutôt off-chain. Cependant, une raison importante de concevoir autour de la Taproot de BTC est d'utiliser TapScriptVM pour la validation informatique lorsque cela est nécessaire, en héritant théoriquement de la sécurité de BTC. Ce processus génère également une chaîne de confiance de validation. Par exemple, il suffit que l'un des "n" validateurs soit honnête, comme dans le cas des rollups optimistes.
6. Les coûts de BitVM sur la chaîne sont élevés, mais peut-il utiliser les preuves de fraude ZK pour améliorer son efficacité ? La réponse est non, car la mise en œuvre des preuves de fraude ZK repose sur la capacité à effectuer la validation ZKP sur la chaîne, ce qui nous ramène au dilemme du schéma OP-ZKP.
8. 3. validation hors chaîne (validation côté client, réseau Lightning)
9. La validation s'effectuant entièrement en dehors de la chaîne, nous revenons aux protocoles d'actifs CSV et au réseau Lightning dont il a été question précédemment. Dans les discussions précédentes, il a été noté que, dans la conception des CSV, il n'est pas possible d'empêcher complètement la falsification collusoire. 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 une fourchette contrôlable, rendant ce comportement non rentable.
10. Les avantages et les inconvénients de la validation hors chaîne sont clairs. L'avantage est une utilisation minimale des ressources de la chaîne, avec un énorme potentiel d'expansion. L'inconvénient est qu'il est presque impossible d'exploiter pleinement la sécurité de la BTC, ce qui limite considérablement les types et les méthodes de transactions hors chaîne. En outre, la validation hors chaîne signifie également que les données sont conservées hors chaîne, gérées par les utilisateurs, 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 à l'expansion Évolution

Actuellement, le populaire Layer2 sur Ethereum utilise essentiellement le Layer1 pour valider l'efficacité de calcul du Layer2. En d'autres termes, les calculs d'état sont déplacés vers la couche 2, mais la validation reste sur la couche 1. À l'avenir, nous pourrons de la même manière faire descendre les calculs de validation en dehors de la chaîne, ce qui permettra d'augmenter encore 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.