Transfert hors chaîne : la voie d'évolution des protocoles d'actifs Bitcoin
TechFlow SélectionTechFlow Sélection
Transfert hors chaîne : la voie d'évolution des protocoles d'actifs Bitcoin
Cet article vise à explorer l'avenir du développement des protocoles d'actifs sur BTC en passant en revue les protocoles d'actifs qui sont apparus par le passé dans l'histoire du BTC.
Dédié à des analyses Web3 approfondiesIntroduction
L’émission d’actifs basée sur BTC a toujours été un sujet brûlant. Depuis les Colored Coins apparues en 2011 jusqu’au protocole Ordinal récemment très populaire, la communauté BTC parvient constamment à faire émerger de nouveaux acteurs et consensus, mais très peu survivent à long terme. Cependant, avec l’annonce audacieuse de Lightning Labs de construire une stablecoin sur Taproot Assets, et celle de Tether choisissant RGB pour frapper USDT directement sur la couche 1 de Bitcoin, une nouvelle ère semble se dessiner.
Cela signifie que OmniLayer (Mastercoin), autrefois le principal acteur dans l'écosystème BTC, n'est plus seul en tête. Les protocoles d'actifs reposant sur la validation côté client (CSV) entrent désormais dans le champ de vision général. Contrairement aux protocoles traditionnels d’actifs BTC, ceux-ci intègrent également des fonctionnalités de mise à l’échelle du réseau. Face à la multitude de protocoles d’actifs existants dans l’écosystème BTC, on s’interroge naturellement : où résident leurs différences ? Comment choisir parmi eux et identifier les opportunités ? Cet article propose de revoir les protocoles d’actifs apparus dans l’histoire de BTC, tout en explorant l’avenir de ces protocoles.
Colored Coins : Les Pièces Colorées
L'idée des Colored Coins a été initialement proposée par Yoni Assia, aujourd'hui PDG de eToro, dans un article daté du 27 mars 2012 intitulé bitcoin 2.X (aka Colored bitcoin). L'article soutient que Bitcoin, en tant que technologie de base, est parfait, tout comme HTTP l’est pour le web. Sur cette base, le protocole Colored Coins a été conçu pour réutiliser BTC.
Yoni Assia souhaitait créer une économie BTC 2.0, où toute communauté pourrait émettre plusieurs types de monnaies via ce mécanisme. Utiliser Bitcoin comme technologie sous-jacente pour le règlement des transactions et éviter les doubles dépenses était alors une idée radicale.
En tant que protocole d’émission d’actifs sur Bitcoin, Colored Coins consiste à « colorer » une certaine quantité de bitcoins afin de représenter d’autres actifs. Ces bitcoins marqués conservent leur fonctionnalité native mais symbolisent aussi une valeur ou un actif différent. Mais comment réaliser cela concrètement sur Bitcoin ?
Le 3 juillet 2014, ChromaWay a développé le protocole EPOBC (Enhanced Pay-to-Burn with Order-Based Coloring), simplifiant la création de pièces colorées pour les développeurs. Il s'agit du premier protocole utilisant la fonction OP_RETURN de Bitcoin Script.
Le résultat final ressemble à l'image ci-dessous :
Cette implémentation est élégante, mais pose plusieurs problèmes :
1. Jetons fongibles et valeur minimale attachée
Si une transaction génésique attache 1000 satoshis à une pièce colorée, l'unité minimale de division est de 1 satoshi. Ainsi, cet actif peut théoriquement être divisé en 1000 parts (bien que, pour éviter les attaques par spam, la limite pratique soit généralement fixée à 546 satoshis, voire plus avec Ordinals).
2. Problème de vérification
Pour confirmer l'authenticité et la propriété d'une pièce colorée, il faut suivre toute la chaîne de transferts depuis la transaction génésique jusqu’au UTXO actuel. Cela nécessite le développement de portefeuilles spécialisés, de nœuds complets dédiés, voire d’explorateurs de blockchain.
3. Risque potentiel de censure par les mineurs
Les transactions colorées sont facilement identifiables car elles incluent des métadonnées dans les sorties, rendant possible la censure par les mineurs.
Les Colored Coins constituent en réalité un système de suivi d’actifs, utilisant les règles de validation de Bitcoin pour tracer les transferts. Toutefois, pour prouver qu’une sortie (txout) représente un actif spécifique, il faut fournir toute la chaîne de transfert depuis son origine. Cela implique que la preuve de validité d’une transaction puisse nécessiter une longue chaîne de vérifications. Pour y remédier, une proposition appelée OP_CHECKCOLORVERIFY a été avancée afin de permettre une vérification directe des transactions Colored Coins sur BTC, mais elle n’a jamais été adoptée.
Le premier ICO de l’industrie cryptographique : Mastercoin
Le concept initial de Mastercoin a été formulé par J.R. Willett. En 2012, il publie un document intitulé "The Second Bitcoin Whitepaper", décrivant la création de nouveaux actifs ou jetons sur la blockchain Bitcoin existante — ce qui deviendra "MasterCoin", rebaptisé par la suite Omni Layer.
Le projet Mastercoin a lancé en 2013 une vente préliminaire de jetons (ce que nous appelons aujourd’hui ICO), levant plusieurs millions de dollars — considérée comme le premier ICO de l’histoire. Son application la plus célèbre est Tether (USDT), la première stablecoin adossée à une monnaie fiduciaire, initialement émise sur Omni Layer.
En réalité, l’idée de Mastercoin est antérieure à celle des Colored Coins. Elle est abordée ici en second lieu car, comparée aux Colored Coins, Mastercoin constitue une solution plus lourde. Mastercoin construit une couche complète de nœuds, offrant des fonctionnalités plus complexes (comme les contrats intelligents), tandis que Colored Coins reste simple et direct, se concentrant principalement sur le « coloriage » ou l’étiquetage des UTXOs Bitcoin pour représenter d'autres actifs.
La grande différence avec Colored Coins réside dans le fait que Mastercoin ne stocke pas les informations d’actifs sur la chaîne, mais uniquement les types de transactions. Les nœuds Mastercoin analysent les blocs Bitcoin pour maintenir une base de données hors chaîne modélisant l’état du système.
Comparé aux Colored Coins, Mastercoin permet une logique plus complexe. Et comme il n’enregistre ni n’effectue de validation sur chaîne, les transactions peuvent être non contiguës (pas besoin de « coloration continue »).
Cependant, pour exécuter la logique complexe de Mastercoin, les utilisateurs doivent faire confiance à l’état stocké dans la base de données hors chaîne, ou exécuter eux-mêmes un nœud Omni Layer pour effectuer la vérification.
Résumé
La principale différence entre Mastercoin et Colored Coins réside dans le fait que Mastercoin ne conserve pas toutes les données du protocole sur la chaîne. Il parasite le système de consensus de BTC pour publier et ordonner ses propres transactions, tout en maintenant l’état dans une base de données hors chaîne.
Selon des informations provenant d’OmniBolt : Omni Layer envisage de proposer à Tether un nouveau protocole d’actifs UBA (UTXO Based Asset), exploitant la mise à jour Taproot pour encoder les informations d’actifs dans les tapleafs, permettant ainsi des paiements conditionnels. Par ailleurs, OmniBolt travaille à intégrer Stark dans l’infrastructure du réseau Lightning d’OmniLayer.
La philosophie de la Validation Côté Client (Client-Side Validation)
Pour comprendre le concept de validation côté client, revenons à 2013, l’année suivant l’apparition de Colored Coins et Mastercoin. Peter Todd publie alors un article intitulé : Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation. Bien que le titre ne semble pas directement lié, cet article contient les premières pensées fondatrices de la validation côté client.
Peter Todd, chercheur pionnier sur Bitcoin et la cryptographie, cherchait continuellement à améliorer l’efficacité du fonctionnement de Bitcoin. S’appuyant sur le concept de timestamp, il développa une notion plus complexe de validation côté client. Il introduisit aussi le concept de « single use seal », dont il sera question plus tard.
Suivons la pensée de Peter Todd et analysons d’abord les problèmes que Bitcoin résout réellement. Selon lui, Bitcoin en résout trois :
-
Preuve de publication (Proof-of-publication)
La preuve de publication vise essentiellement à résoudre le problème des doubles dépenses. Par exemple, Alice souhaite envoyer des bitcoins à Bob. Même si elle signe une transaction, Bob ne sait pas nécessairement physiquement qu’elle existe. Nous avons donc besoin d’un espace public pour publier les transactions, accessible à tous pour consultation.
-
Ordonnancement des transactions (Order consensus)
Dans les systèmes informatiques, il n’existe pas de temps physique tel que nous le percevons. Dans les systèmes distribués, on utilise souvent des horloges distribuées (horloge de Lamport), qui ne mesurent pas le temps physique mais servent à ordonner les transactions.
-
Validation des transactions (Validation) (optionnel)
La validation sur BTC concerne les signatures et le montant transféré. Mais selon Peter Todd, cette validation n’est pas nécessaire pour construire un système de jetons sur BTC ; elle constitue plutôt une optimisation.
On comprend alors pourquoi OmniLayer, mentionné précédemment, n’a pas confié le calcul et la validation d’état à BTC, tout en réutilisant sa sécurité. Colored Coins, en revanche, délègue le suivi d’état à BTC. Leur existence montre déjà que la validation ne doit pas nécessairement avoir lieu sur chaîne.
Comment la validation côté client valide-t-elle efficacement les transactions ?
Examinons d’abord ce qui doit être validé :
-
État (validation logique de la transaction)
-
Validité des entrées TxIn (prévention des doubles dépenses)
Il est clair que pour les actifs publiés sur BTC, chaque transaction nécessite de vérifier toute l’historique associé pour garantir que l’entrée référencée n’a pas été dépensée et que l’état est correct. Ce processus est inefficace. Comment l’améliorer ?
Peter Todd propose de changer le focus de la validation. Plutôt que de vérifier qu’une sortie n’a pas été doublement dépensée, cette méthode vérifie que l’entrée a bien été publiée et qu’elle ne fait pas double emploi avec d’autres entrées. En triant les entrées dans chaque bloc et en utilisant des arbres de Merkle, cette validation devient plus efficace, car elle ne nécessite qu’une petite partie des données, et non l’historique complet de l’entrée.
La structure d’arbre d’engagement (commitment tree) proposée par Peter Todd est la suivante :
CTxIn -> CTxOut -> <chemin merkle> -> CTransaction -> <chemin merkle> -> CT= xIn
Mais comment stocker un tel arbre d’engagement sur chaîne ? C’est ici qu’intervient le concept du sceau à usage unique (single use seal).
Sceau à Usage Unique (Single Use Seal)
Le « single use seal » est l’un des concepts fondamentaux pour comprendre la validation côté client. Il s’apparente aux scellés physiques, utilisés une seule fois, pour sécuriser les conteneurs de fret. Un sceau à usage unique est un objet unique qui ne peut être fermé qu’une seule fois sur un message. En bref, il s’agit d’un mécanisme abstrait empêchant les doubles dépenses.
Pour le protocole Seal, on distingue trois éléments et deux actions.
Éléments de base :
-
l : sceau (seal)
-
m : message
-
w : témoin (witness)
Opérations de base : deux opérations principales :
-
Close(l,m) → w : fermer le sceau l sur le message m, produisant un témoin w.
-
Verify(l,w,m) → bool : vérifier si le sceau l a été fermé sur le message m.
La sécurité du « single use seal » repose sur l'impossibilité pour un attaquant de trouver deux messages différents m1 et m2 tels que la fonction Verify retourne vrai pour le même sceau.
Un « single use seal » est un concept garantissant qu’un actif ou une donnée ne peut être utilisé ou verrouillé qu’une seule fois. Dans le contexte de Bitcoin, cela signifie qu’un UTXO (sortie de transaction non dépensée) ne peut être consommé qu’une fois. Ainsi, la sortie d’une transaction Bitcoin peut être vue comme un sceau à usage unique, qui est « brisé » ou « utilisé » lorsqu’elle sert d’entrée à une autre transaction.
Pour les actifs CSV sur BTC, Bitcoin lui-même joue le rôle de « témoin » du sceau à usage unique. En effet, pour valider une transaction Bitcoin, les nœuds doivent vérifier que chaque entrée référence un UTXO valide et non encore dépensé. Si une transaction tente de doubler la dépense d’un UTXO déjà utilisé, les règles de consensus de Bitcoin et les nœuds honnêtes rejettent la transaction.
Peut-on faire plus simple ?
Single use seal, c’est utiliser n’importe quelle blockchain comme base de données, y inscrire un engagement relatif à un message, et gérer un état « consommé » ou « à consommer ».
Voilà, c’est aussi simple que ça.
En résumé, les actifs basés sur la validation côté client présentent les caractéristiques suivantes :
-
Stockage hors chaîne : l’historique des transactions, la propriété et autres données connexes sont majoritairement stockés hors chaîne. Cela réduit fortement la demande de stockage sur chaîne et améliore la confidentialité.
-
Mécanisme d’engagement : bien que les données soient stockées hors chaîne, les modifications ou transferts font l’objet d’un engagement enregistré sur chaîne. Ces engagements permettent aux transactions sur chaîne de référencer l’état hors chaîne, assurant intégrité et immuabilité des données hors chaîne.
-
Témoin sur chaîne (pas forcément BTC) : bien que la plupart des données et validations aient lieu hors chaîne, grâce aux engagements sur chaîne, les actifs CSV peuvent tirer parti de la sécurité de la chaîne sous-jacente (preuve de publication, ordonnancement des transactions).
-
Validation effectuée côté client : la majeure partie de la validation est réalisée sur l’appareil utilisateur. Ainsi, tous les nœuds du réseau n’ont pas besoin de participer à la validation de chaque transaction ; seuls les participants concernés doivent vérifier la validité.
Pour les utilisateurs d’actifs CSV, une précision importante :
Lors de transactions hors chaîne ou de validation d’actifs CSV, il ne suffit pas de présenter la clé privée prouvant la possession de l’actif, mais aussi la preuve complète du chemin Merkle correspondant.
Le précurseur de la validation côté client : RGB
Le concept de RGB a été proposé vers 2015 par Giacomo Zucco, figure reconnue de la communauté. Avec l’essor d’Ethereum et l’inflation des ICO, de nombreux projets ont tenté d’aller au-delà de Bitcoin, comme Mastercoin ou Colored Coins.
Giacomo Zucco exprimait sa déception face à ces projets, les jugeant inférieurs à Bitcoin, et estimant que les approches précédentes étaient inappropriées. Durant ce parcours, il rencontre Peter Todd et s’enthousiasme pour son idée de validation côté client (Client-Side Validation). C’est ainsi qu’il formule l’idée du protocole RGB.
Outre les caractéristiques classiques des actifs CSV, RGB introduit un moteur de contrat Turing-complet via une machine virtuelle. Pour garantir la sécurité des données contractuelles, il définit des schémas (Schema) et interfaces (Interface). Le Schema, similaire aux standards d’Ethereum, déclare le contenu et les fonctions du contrat, tandis que l’Interface implémente ces fonctions, comme dans les langages de programmation.
Ces schémas limitent les comportements imprévus lors de l’exécution dans la VM. Par exemple, RGB20 et RGB21 imposent des restrictions spécifiques aux transactions de jetons fongibles et non fongibles.
Mécanisme d’engagement de RGB : PerdersenHash
Du point de vue de l’engagement, RGB utilise le hachage de Pedersen. Son avantage est de permettre l’engagement sur une valeur sans la divulguer. Construire un arbre de Merkle avec Pedersen Hash permet de créer un arbre protégeant la vie privée, cachant les valeurs internes. Cette structure convient à certains protocoles de confidentialité, comme certaines cryptomonnaies anonymes. Toutefois, cela peut ne pas convenir aux actifs CSV, comme discuté plus tard dans la comparaison avec Taproot Assets.
Conception de la machine virtuelle RGB : Simplicity → AluVM
RGB ne vise pas seulement à être un protocole d’actifs CSV, mais aussi à étendre vers une machine virtuelle Turing-complète et la programmation contractuelle. Initialement, RGB annonçait utiliser un langage appelé Simplicity, dont les expressions produisent une preuve d’exécution et facilitent la vérification formelle (réduction des bogues). Mais le développement fut difficile, menant à un blocage total du protocole. Finalement, RGB adopte AluVM, une machine virtuelle développée par Maxim, visant à éviter tout comportement indéfini, comme Simplicity. La nouvelle AluVM utilisera probablement à l’avenir un langage appelé Contractum, remplaçant actuellement Rust.
Stratégie de mise à l’échelle L2 de RGB : Réseau Lightning ou sidechain ?
Les actifs à validation côté client ne peuvent pas effectuer de transactions continues en toute sécurité hors chaîne. Ils dépendent toujours de la couche 1 pour la publication et l’ordonnancement des transactions. Sans solution de mise à l’échelle L2, leur vitesse reste limitée par la cadence de production des blocs de la chaîne de validation. Ainsi, une transaction RGB directement sur Bitcoin nécessiterait jusqu’à dix minutes d’intervalle (temps moyen de minage d’un bloc BTC), ce qui est inacceptable dans la plupart des cas.
RGB et le réseau Lightning
Le principe du réseau Lightning repose sur la signature hors chaîne d’une série de contrats (transactions engagées) entre deux parties. En cas de fraude, la partie lésée peut soumettre le contrat à Bitcoin pour récupérer ses fonds et sanctionner l’autre. Ainsi, le réseau Lightning assure la sécurité des transactions hors chaîne via la conception de protocoles et de jeux stratégiques.
RGB pourrait concevoir ses propres règles de canal de paiement pour construire une infrastructure Lightning, mais la complexité est extrême. Développer une telle infrastructure est difficile. De plus, Lightning Labs domine largement ce domaine, avec LND possédant plus de 90 % du marché.
La sidechain Prime de RGB
LNP-BP, actuel mainteneur du protocole RGB, a vu Maxim publier en juin 2023 une proposition appelée **Prime**, une solution de mise à l’échelle pour actifs à validation côté client. Il critique les solutions existantes (sidechains, Lightning) comme étant trop complexes à développer. Maxim affirme que d’autres options comme NUCLEUS (canal Lightning multi-nœuds) ou Ark/Enigma (usines de canaux) exigent plus de deux ans de développement, alors que Prime pourrait être achevé en un an.
Prime n’est pas une blockchain classique, mais une couche modulaire de publication de preuves dédiée à la validation côté client. Elle comporte quatre composants :
-
Service de timestamp
Fournit une séquence de transactions confirmée en 10 secondes maximum. -
Preuves
Stockées sous forme PMT, produites et publiées avec les en-têtes de bloc. -
Sceau à usage unique
Protocole abstrait anti-doubles dépenses. Implémentable via un lien vers un UTXO, comme dans RGB actuel. -
Protocole de contrat intelligent
Contrat fragmenté – RGB (remplaçable)
On voit ainsi que Prime résout le problème du temps de confirmation des transactions RGB en utilisant un service de timestamp rapide, confirmant les transactions hors chaîne et les intégrant dans des blocs. Ensuite, les preuves des transactions Prime peuvent être agrégées via PMT puis ancrées sur BTC comme des points de contrôle.
Protocole d’actifs CSV basé sur Taproot : Taproot Assets
Taproot Assets est un protocole d’actifs CSV basé sur Taproot, permettant d’émettre des actifs à validation côté client sur la blockchain Bitcoin, échangeables instantanément, en grand volume et à faible coût via le réseau Lightning. Ce protocole tire parti de la sécurité et stabilité du réseau Bitcoin, combinées à la rapidité, extensibilité et faibles frais du réseau Lightning. Conçu et développé par roasbeef, CTO de Lightning Labs, qui est probablement le seul développeur à avoir personnellement dirigé un client Bitcoin (BTCD) et un client Lightning (LND), il possède une compréhension profonde de BTC.
Une transaction Taproot ne transporte que le haché racine du script d’actif, rendant difficile pour un observateur externe d’identifier si elle concerne Taproot Assets, car le haché est générique et peut représenter n’importe quelle donnée. Grâce à la mise à jour Taproot, Bitcoin acquiert des capacités de contrat intelligent (TapScript). Sur cette base, l’encodage des actifs Taproot équivaut à définir un jeton similaire à ERC20 ou ERC721. Bitcoin obtient ainsi non seulement une fonction de définition d’actifs, mais aussi une capacité d’écriture de contrats intelligents, posant les bases d’une infrastructure de jetons intelligents.
Structure d’encodage de Taproot Assets :
Image fournie par roasbeef, CTO de Lightning Labs
Comme protocole CSV, Taproot Assets présente une conception plus simple que RGB. Il exploite pleinement les avancées récentes de l’écosystème BTC, comme la mise à jour Taproot et PSBT. La principale différence d’extensibilité avec RGB réside dans la machine virtuelle d’exécution : Taproot Assets utilise TaprootScriptVM, identique au moteur natif de BTC. De nombreuses recherches récentes sur les infrastructures BTC reposent sur TapScript, mais leur application est limitée par la lenteur des mises à jour. Taproot Assets devrait devenir un terrain d’expérimentation pour ces nouvelles idées.
Quelles sont les différences entre Taproot Assets et RGB ?
1. Vérification des transactions et compatibilité avec les nœuds légers
Grâce à l’implémentation de l’arbre somme (sum tree), Taproot Assets offre une haute efficacité et sécurité de vérification (la preuve de possession suffit à valider l’état et effectuer des transactions, sans parcourir tout l’historique des entrées). En revanche, l’utilisation par RGB de l’engagement de Pedersen empêche une vérification efficace de la validité des entrées, obligeant à remonter tout l’historique transactionnel — une charge croissante au fil du temps. La conception Merkle sum permet à Taproot Assets de supporter facilement la validation par nœuds légers, une fonctionnalité inexistante dans les protocoles d’actifs BTC antérieurs.
2. Machine virtuelle d’exécution
Taproot Assets naît avec la mise à jour Taproot. Il utilise TaprootScriptVM, le moteur de scripts intégré à Bitcoin après Taproot, et une version vPSBT compatible avec le PSBT de BTC. Dès que le mécanisme de canal Lightning pour Taproot Assets sera achevé, il pourra réutiliser toute l’infrastructure existante de LND, ainsi que les produits antérieurs de Lightning Labs (LND détient plus de 90 % du marché Lightning). De plus, les propositions récentes comme BitVM reposent sur TaprootScript, et toutes ces améliorations pourront théoriquement bénéficier à Taproot Assets.
En revanche, la VM et les règles de validation (SCHEMA) de RGB forment un système autonome, créant un petit écosystème relativement fermé. Les développements autour de RGB restent confinés à son propre cercle, et leur lien avec l’écosystème Bitcoin est moins fort qu’on ne le pense. Par exemple, l’adaptation de RGB à Taproot se limite à encoder les données d’engagement dans le TapLeaf du witness.
3. Contrats intelligents
Dans l’implémentation actuelle de RGB, les contrats et la VM occupent une place centrale. Chez Taproot Assets, aucune trace de contrat intelligent n’est visible pour l’instant. Cependant, RGB n’a pas encore expliqué comment synchroniser les modifications d’état global avec les fragments de contrats indépendants (UTXO). De plus, l’engagement de Pedersen ne garantit que le total des actifs, sans clarifier comment détecter la falsification d’autres états. Quant à Taproot Assets, bien que simple, il ne stocke pour l’instant que le solde des actifs, sans support d’états supplémentaires, rendant impossible la discussion sur les contrats intelligents. Selon Lightning Labs, des efforts seront déployés en 2024 sur la conception de contrats intelligents pour Taproot Assets.
4. Centre de synchronisation
D’après les principes de base des actifs à validation côté client, détenir la preuve (Proof) est aussi important que détenir la clé privée. Mais les preuves stockées côté client risquent d’être perdues. Que faire ? Taproot Assets propose « universe », un registre public et vérifiable (MS-SMT) couvrant un ou plusieurs actifs. Contrairement à un arbre d’actifs Taproot, universe ne gère pas directement les actifs, mais s’engage sur un sous-ensemble de l’historique des actifs.
Chez RGB, ce rôle incombe à Storm, qui synchronise et stocke les preuves hors chaîne via P2P. Mais en raison de l’histoire du développement de RGB, les formats de preuve des différentes équipes sont incompatibles. L’équipe DIBA de l’écosystème RGB annonce le développement de carbonado pour résoudre ce problème, mais l’avancement reste incertain.
5. Implémentation technique
Toutes les bibliothèques utilisées par Taproot Assets sont éprouvées, car Lightning Labs dispose de son propre client Bitcoin (BTCD), client Lightning (LND), et de nombreuses implémentations de wallet lib. En revanche, les bibliothèques utilisées par RGB proviennent majoritairement de développements internes, ce qui place son implémentation, selon les standards industriels, encore au stade expérimental.
Réflexions sur l’avenir de la mise à l’échelle de BTC
À ce stade, on constate que les protocoles d’actifs à validation côté client dépassent le cadre strict du protocole, s’orientant vers la mise à l’échelle computationnelle.
Beaucoup affirment que Bitcoin deviendra à l’avenir de l’« or numérique », tandis que d’autres blockchains porteront les écosystèmes applicatifs. Je pense différemment. Comme souvent discuté sur les forums BTC, de nombreuses altcoins ont eu des vies éphémères. Leur disparition rapide a transformé en bulle spéculative les capitaux et efforts qui leur étaient consacrés. Nous disposons déjà d’un socle de consensus puissant avec Bitcoin ; inutile de construire de nouveaux L1 pour chaque protocole applicatif. Notre objectif doit être d’exploiter au mieux cette infrastructure robuste pour bâtir un monde décentralisé durable.
Moins de calcul sur chaîne, plus de validation sur chaîne
Du point de vue de la conception applicative, Bitcoin a très tôt choisi une philosophie centrée non pas sur le calcul, mais sur la validation (Turing completeness and state for smart contract). Une blockchain est fondamentalement une machine à états répliquée. Si le consensus repose sur le calcul sur chaîne, il devient difficile de justifier que tous les nœuds du réseau dupliquent ces calculs — une approche peu scalable. En revanche, en se concentrant sur la validation, notamment des transactions hors chaîne, on ouvre la voie la plus adaptée à la mise à l’échelle de BTC.
Où la validation a lieu ? C’est crucial
Pour les développeurs de protocoles sur Bitcoin, savoir comment utiliser Bitcoin pour les validations critiques, voire déplacer la validation hors chaîne, et concevoir des schémas de sécurité, relève de leur responsabilité. Ces choix ne doivent pas être liés à la chaîne elle-même. Ainsi, la manière de mettre en œuvre la validation donne naissance à différentes stratégies de mise à l’échelle de BTC.
Trois directions de mise à l’échelle émergent selon cette perspective :
-
Validation sur chaîne (OP-ZKP)
Implémenter OP-ZKP directement dans TaprootScriptVM reviendrait à doter BTC de la capacité de valider des ZKP. Associé à des designs de type Covenant, cela permettrait de créer des solutions de type Zk-Rollup héritant de la sécurité de BTC. Mais contrairement au déploiement d’un contrat de vérification sur Ethereum, les mises à jour de BTC sont lentes, et l’ajout d’un opcode spécialisé, potentiellement nécessitant des mises à jour futures, est voué à la difficulté.
-
Validation semi-sur-chaîne (BitVM)
La conception de BitVM n’est pas destinée aux logiques transactionnelles courantes. Robin Linus indique que l’avenir de BitVM est de devenir un marché libre pour les interconnexions entre sidechains. On parle de « semi-sur-chaîne » car la plupart des calculs de validation ont lieu hors chaîne. Toutefois, le design autour de Taproot de BTC permet, quand nécessaire, d’utiliser TapScriptVM pour la validation, assurant théoriquement l’héritage de la sécurité de BTC. Ce processus crée une chaîne de confiance de validation : il suffit qu’un seul des n validateurs soit honnête, comme dans les Optimistic Rollups.
Bien que BitVM entraîne des coûts élevés sur chaîne, peut-on améliorer son efficacité avec des preuves de fraude ZK ? Non, car cela suppose que la chaîne puisse vérifier des ZKP, ce qui ramène au dilemme de OP-ZKP.
-
Validation hors chaîne (Client-Side Validation, Réseau Lightning)
La validation entièrement hors chaîne correspond aux protocoles CSV et au réseau Lightning. Comme discuté, les CSV ne peuvent pas totalement empêcher la collusion malveillante, mais ils utilisent la cryptographie et la conception de protocole pour limiter les dommages à un niveau contrôlé, rendant ces comportements non rentables.
Les avantages et inconvénients de la validation hors chaîne sont évidents : avantage majeur, occupation minimale des ressources sur chaîne et potentiel de mise à l’échelle élevé. Inconvénient majeur, impossibilité de pleinement réutiliser la sécurité de BTC, ce qui limite fortement les types et méthodes de transactions hors chaîne possibles. De plus, la validation hors chaîne implique que toutes les données sont stockées hors chaîne, sous responsabilité de l’utilisateur, ce qui impose des exigences élevées sur la sécurité et la stabilité du logiciel.
Tendance de l’évolution de la mise à l’échelle
Actuellement, les Layer 2 populaires sur Ethereum reposent sur un paradigme où la couche 1 valide la validité des calculs de la couche 2 : le calcul d’état est déplacé vers la couche 2, mais la validation reste sur la couche 1. À l’avenir, nous pouvons envisager de déporter également la validation hors chaîne, libérant davantage les performances des infrastructures blockchain.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@wooooer
