De l'inscription aux contrats intelligents : analyse complète de l'évolution technologique de l'écosystème Bitcoin
TechFlow SélectionTechFlow Sélection
De l'inscription aux contrats intelligents : analyse complète de l'évolution technologique de l'écosystème Bitcoin
Pourquoi ne pas passer à Ethereum, et pourquoi refaire les choses une fois de plus sur Bitcoin ? Parce que c'est Bitcoin.
Dédié à des analyses Web3 approfondiesAuteur : Cynic, CGV Research
Le bitcoin, première monnaie numérique décentralisée ayant connu le succès, reste depuis son apparition en 2009 au cœur de l'univers des cryptomonnaies. En tant qu'innovation dans les moyens de paiement et de stockage de valeur, il a suscité un intérêt mondial pour les technologies blockchain et les cryptoactifs. Toutefois, à mesure que l'écosystème du bitcoin mûrit et s'étend, il fait face à divers défis, notamment en matière de vitesse de transaction, d'évolutivité, de sécurité et de réglementation.
Récemment, l'écosystème des inscriptions, mené par BRC20, a déclenché une flambée sur le marché, plusieurs jetons connaissant des hausses supérieures à 100 fois. Les transactions sur la chaîne Bitcoin sont devenues gravement congestionnées, avec un prix moyen du gaz dépassant 300 sat/vB. Parallèlement, le programme d'airdrop des Nostr Assets attire davantage l'attention, tandis que des protocoles comme BitVM et BitStream publient leurs livres blancs. L'écosystème du bitcoin est encore naissant mais recèle un fort potentiel d'expansion.
L'équipe de recherche CGV, après avoir passé en revue l'état actuel de l'écosystème Bitcoin — incluant les avancées technologiques, dynamiques du marché et cadre réglementaire — procède à une analyse approfondie de la technologie Bitcoin, examine les tendances du marché, afin d'offrir une perspective panoramique sur son évolution. Cet article commence par rappeler les principes fondamentaux et l'historique du Bitcoin, puis explore en détail les innovations techniques du réseau Bitcoin telles que le réseau Lightning et SegWit, avant d'envisager ses perspectives futures.
Émission d'actifs : retour aux colored coins
Le phénomène des inscriptions repose essentiellement sur leur capacité à offrir à tous une émission d'actifs accessible, simple, équitable et pratique. Bien que les protocoles d'inscription sur Bitcoin soient apparus en 2023, dès 2012 existait déjà l'idée d'utiliser Bitcoin pour émettre des actifs, sous le nom de « colored coins » (pièces colorées).
Les colored coins : une première tentative
Les colored coins désignent un ensemble de techniques utilisant le système Bitcoin pour enregistrer la création, la propriété et le transfert d'actifs autres que le Bitcoin lui-même. Elles permettent de suivre des actifs numériques ou physiques détenus par des tiers, et d'en échanger la propriété via ces pièces colorées. Le « coloriage » consiste à ajouter des informations spécifiques à un UTXO Bitcoin, le différenciant ainsi des autres UTXO, introduisant une hétérogénéité entre des unités initialement homogènes. Grâce à cette technologie, les actifs émis bénéficient des mêmes caractéristiques que Bitcoin : protection contre les doubles dépenses, confidentialité, sécurité, transparence et résistance à la censure, garantissant la fiabilité des transactions.
Il convient de noter que les protocoles de colored coins ne sont pas implémentés dans les logiciels Bitcoin standards. Un logiciel spécifique est donc nécessaire pour reconnaître ces transactions. De toute évidence, les colored coins n'ont de valeur que dans une communauté qui accepte ce protocole ; autrement, elles perdent leur attribut de « couleur » et retournent à l'état pur de satoshis. D’un côté, une petite communauté peut tirer parti des nombreux avantages de Bitcoin pour émettre et échanger des actifs ; de l’autre, il est quasi impossible que le protocole des colored coins soit intégré via un soft fork au logiciel principal Bitcoin Core, faute d’un consensus large.
Open Assets
Fin 2013, Flavien Charlon propose le protocole Open Assets, une implémentation des colored coins. L’émetteur utilise la cryptographie asymétrique pour calculer un identifiant d’actif, garantissant que seul le détenteur de la clé privée associée puisse créer le même actif. Les métadonnées de l’actif sont stockées dans le script via l’opcode OP_RETURN, appelé « marker output », permettant d’enregistrer l’information de coloriage sans polluer l’UTXO. Grâce à l’utilisation de la cryptographie à clé publique/bitcoin, l’émission peut être réalisée via une multisignature.
EPOBC
En 2014, ChromaWay propose le protocole EPOBC (enhanced, padded, order-based coloring), qui comporte deux types d'opérations : genesis (émission) et transfer (transfert). Le type d'actif n'est pas codé explicitement ; chaque transaction genesis crée un nouvel actif dont la quantité totale est fixée à l'émission. Un actif EPOBC doit obligatoirement être transféré via une opération transfer. S’il est utilisé comme entrée dans une transaction non-transfer, l’actif est perdu.
Les informations supplémentaires liées à un actif EPOBC sont stockées dans le champ nSequence d'une transaction Bitcoin. Ce champ, composé de 32 bits, utilise ses six bits de poids faible pour définir le type de transaction, et les bits 6 à 12 pour le padding (remplissage destiné à prévenir les attaques par spam de microtransactions). Le stockage via nSequence présente l'avantage de ne pas nécessiter d'espace supplémentaire. N'ayant pas d'identifiant d'actif, chaque transaction EPOBC doit remonter jusqu'à sa transaction genesis pour vérifier sa catégorie et sa légitimité.
Mastercoin/Omni Layer
Comparé aux protocoles précédents, Mastercoin connaît un meilleur succès commercial. En 2013, Mastercoin réalise le premier ICO de l'histoire, levant 5000 BTC, inaugurant ainsi une nouvelle ère. L’USDT, bien connu aujourd’hui, a été initialement émis sur Bitcoin via Omni Layer.
Mastercoin dépend moins directement de Bitcoin, choisissant plutôt de maintenir l’état hors chaîne tout en conservant uniquement des informations minimales sur chaîne. On peut considérer que Mastercoin utilise Bitcoin comme un système de journalisation décentralisé, publiant via des transactions Bitcoin arbitraires les modifications d’actifs. La validation de la validité des transactions se fait en analysant continuellement les blocs Bitcoin pour maintenir une base de données hors chaîne des actifs, qui conserve les correspondances entre adresses et actifs, en réutilisant le système d’adresses Bitcoin.
Les premiers colored coins utilisaient principalement l'opcode OP_RETURN du script pour stocker les métadonnées des actifs. Après les mises à jour SegWit et Taproot, de nouveaux protocoles dérivés disposent désormais de davantage d'options.
SegWit, contraction de Segregated Witness, consiste à séparer le « Witness » (le script d'entrée de la transaction) du corps principal de la transaction. Cette séparation vise principalement à empêcher les attaques par modification du script d'entrée, mais offre également un effet secondaire utile : elle augmente indirectement la capacité des blocs, permettant de stocker davantage de données witness.
Une caractéristique importante de Taproot est MAST, qui permet aux développeurs d’inclure dans les sorties des métadonnées arbitraires via un arbre de Merkle, d’améliorer l’efficacité et l’évolutivité grâce aux signatures Schnorr, et d’effectuer des transactions multi-sauts via le réseau Lightning.
Ordinals & BRC20 et imitations : une vaste expérience sociale
Du point de vue large, Ordinals comprend quatre composantes :
-
Un BIP, pour ordonner les satoshis
-
Un indexeur, utilisant un nœud Bitcoin Core pour suivre la position (l’ordre) de chaque satoshi
-
Un portefeuille, pour effectuer des transactions liées aux ordinaux
-
Un explorateur de blocs, capable d’identifier les transactions ordinales
Bien entendu, le cœur reste le BIP / protocole.
Ordinals attribue un numéro d’ordre à chaque satoshi, la plus petite unité de Bitcoin, selon l’ordre dans lequel ils ont été minés (à partir de zéro). Cela confère aux satoshis, initialement homogènes, une qualité hétérogène, créant ainsi une forme de rareté.
On peut réutiliser l'infrastructure BTC existante : signatures simples, multisignatures, verrous temporels, verrous de hauteur, etc., sans création explicite de numéros ordinaux, offrant une bonne anonymisation et aucune trace visible sur chaîne. Mais les inconvénients sont aussi manifestes : un grand nombre de petits UTXO inutilisés augmentent la taille de l'ensemble UTXO, ce qui peut être considéré comme une attaque par spam (« dust attack »). De plus, l'indexation prend beaucoup de place, et chaque dépense d'un satoshi spécifique exige :
-
L’en-tête du bloc blockchain
-
Le chemin Merkle vers la transaction coinbase ayant créé ce satoshi
-
La transaction coinbase elle-même
afin de prouver que ce satoshi particulier est inclus dans une sortie spécifique.
Les inscriptions consistent à graver n’importe quel contenu sur des satoshis, en plaçant ce contenu dans les scripts de dépense du chemin Taproot, entièrement sur chaîne. Le contenu est sérialisé selon le format de réponse HTTP, puis poussé via OP_PUSH dans un script de dépense non exécutable, appelé « enveloppes ». Plus précisément, on ajoute OP_FALSE devant une condition, et on insère le contenu d’inscription au format JSON dans une branche de condition inaccessible. La taille du contenu est limitée par le script Taproot, ne pouvant excéder 520 octets.
Comme les scripts de paiement Taproot exigent une sortie Taproot existante, les inscriptions nécessitent deux étapes : commit & reveal. Premièrement, on crée une sortie Taproot contenant un engagement au contenu. Deuxièmement, on dépense cette sortie en utilisant le contenu d’inscription et le chemin Merkle correspondant, révélant ainsi le contenu sur chaîne.
À l’origine, les inscriptions visaient à introduire des jetons non fongibles (NFT) sur BTC. Mais de nouveaux développeurs, s’inspirant d’ERC-20, ont créé BRC20, ajoutant ainsi au protocole Ordinals la capacité d’émettre des actifs fongibles. BRC20 dispose d’opérations Deploy, Mint et Transfer, chacune nécessitant deux étapes (commit & reveal), rendant le processus plus complexe et coûteux.
Exemple avec données réelles :
La partie sélectionnée représente le contenu inscrit. Après désérialisation, le résultat est le suivant :
Le protocole ARC20, dérivé d’Atomicals, réduit la complexité des transactions en liant chaque unité de jeton ARC20 à un satoshi, réutilisant ainsi le système de transaction de Bitcoin. Après l’émission en deux étapes (commit & reveal), le transfert des jetons ARC20 peut s’effectuer directement par transfert du satoshi correspondant. La conception d’ARC20 correspond peut-être mieux à la définition littérale de « colored coin » : ajouter une information à un jeton existant pour en faire un nouveau, dont la valeur ne peut être inférieure à celle du jeton initial, à l’instar des bijoux en or ou en argent.
Validation client-side et protocoles d’actifs de nouvelle génération
La validation côté client (client-side validation, CSV) est un concept proposé par Peter Todd en 2017, accompagné de celui du « scellant à usage unique » (single-use-seal). En résumé, le mécanisme CSV repose sur le stockage hors chaîne, l’engagement sur chaîne et la validation par le client. Cette idée apparaît déjà partiellement dans les protocoles d’actifs antérieurs. Aujourd’hui, les protocoles d’actifs basés sur CSV incluent RGB et Taproot Assets (Taro).
RGB
Outre la validation client-side, RGB utilise le hachage de Pedersen comme mécanisme d’engagement, et prend en charge l’aveuglement des sorties : lorsqu’une demande de paiement est envoyée, il n’est pas nécessaire de révéler publiquement l’UTXO destinataire, mais seulement une valeur de hachage, renforçant ainsi la confidentialité et la résistance à la censure. Toutefois, lorsque le jeton est dépensé, la clé aveugle doit être communiquée au destinataire afin qu’il puisse vérifier l’historique de la transaction.
De plus, RGB intègre AluVM pour une programmabilité accrue. Lorsqu’un utilisateur effectue une validation client-side, outre la vérification des informations de paiement reçues, il doit obtenir de l’émetteur tout l’historique des transactions de ce jeton, jusqu’à la transaction de création initiale (genesis), pour garantir la finalité de la transaction. Seule la vérification complète de cet historique assure la validité de l’actif reçu.
Taproot Assets
Taproot Assets est un nouveau projet développé par Lightning Labs, l’équipe derrière le réseau Lightning. Les actifs émis peuvent y être transférés instantanément, en grand volume et à faible coût via le réseau Lightning. Conçu entièrement autour du protocole Taproot, il améliore confidentialité et extensibilité.
Les données witness sont stockées hors chaîne et validées sur chaîne. Le stockage hors chaîne peut être local ou dans un référentiel d’informations (appelé « Universes », similaire à un dépôt Git). La validation du witness nécessite toutes les données historiques depuis l’émission de l’actif, diffusées via la couche gossip de Taproot Assets. Les clients peuvent effectuer une vérification croisée via une copie locale de la blockchain.
Taproot Assets utilise un Sparse Merkle Sum Tree pour stocker l’état global des actifs. Bien que cela entraîne un coût de stockage élevé, cela permet une efficacité élevée en vérification : grâce aux preuves d’appartenance/non-appartenance, on peut valider les transactions sans remonter à tout l’historique.
L’évolutivité : le défi éternel du Bitcoin
Malgré sa capitalisation, sa sécurité et sa stabilité inégalées, Bitcoin s’éloigne de plus en plus de sa vision initiale : « un système de cash électronique pair-à-pair ». En raison de la limite de taille des blocs, le TPS, les frais et les délais de confirmation rendent Bitcoin incapable de traiter un grand volume de transactions fréquentes. Depuis plus de dix ans, divers protocoles tentent de résoudre ce problème.
Canal de paiement et réseau Lightning : la solution fondamentaliste Bitcoin
Le réseau Lightning fonctionne en établissant des canaux de paiement. Deux utilisateurs peuvent ouvrir un canal entre eux, et ces canaux peuvent se connecter entre eux, formant un réseau interconnecté. Deux utilisateurs sans canal direct peuvent effectuer des paiements via plusieurs sauts.
Par exemple, si Alice et Bob souhaitent effectuer plusieurs transactions sans enregistrer chacune sur la blockchain Bitcoin, ils peuvent ouvrir un canal de paiement. Ils peuvent alors effectuer un nombre illimité de transactions à l’intérieur de ce canal, n’enregistrant sur la blockchain que deux fois : une fois à l’ouverture, une fois à la fermeture. Cela réduit considérablement le temps d’attente de confirmation et allège la charge de la blockchain.
Actuellement, le réseau Lightning compte plus de 14 000 nœuds, plus de 60 000 canaux, et une capacité totale dépassant 5000 BTC.
Sidechains : la voie Ethereum appliquée à Bitcoin
Stacks
Stacks se présente comme la couche de contrats intelligents de Bitcoin, utilisant son propre jeton comme gaz. Il adopte un mécanisme de micro-blocs : Bitcoin et Stacks évoluent de manière synchronisée, leurs blocs étant confirmés simultanément. Dans Stacks, cela s’appelle un « bloc ancré ». Chaque bloc Stacks correspond à une seule transaction Bitcoin, permettant un débit transactionnel plus élevé. Comme les blocs sont produits simultanément, Bitcoin agit comme limiteur de cadence pour Stacks, protégeant ainsi son réseau pair-à-pair contre les attaques par déni de service.
Stacks atteint un consensus via un double mécanisme PoX : les mineurs envoient des BTC aux détenteurs de STX pour concourir à la création de blocs. Le mineur gagnant reçoit une récompense en STX. Les détenteurs de STX reçoivent proportionnellement les BTC envoyés par les mineurs. Stacks espère inciter les mineurs à maintenir le registre historique via un jeton natif, bien que cela puisse être réalisé sans jeton natif (cf. RSK).
Pour les données de transaction Stacks, le hachage des données est sauvegardé dans un script Bitcoin via l’opcode OP_RETURN. Les nœuds Stacks peuvent lire ces hachages via des fonctions intégrées à Clarity.
Stacks est presque une chaîne de niveau 2 de Bitcoin, mais les transferts d’actifs restent imparfaits. Après la mise à jour Nakamoto, Stacks permet d’envoyer une transaction Bitcoin pour retirer des actifs, mais la complexité des transactions empêche une validation sur chaîne Bitcoin, obligeant à recourir à un comité multisignature pour valider les retraits.
RSK
RSK utilise l’algorithme de minage fusionné (Merge-Mine), permettant aux mineurs Bitcoin d’aider RSK à produire des blocs presque sans coût, en obtenant une récompense supplémentaire. RSK n’a pas de jeton natif, utilisant toujours le BTC (RBTC) comme gaz. Il possède son propre moteur d’exécution, compatible avec la machine virtuelle Ethereum (EVM).
Liquid
Liquid est une sidechain consortium de Bitcoin, à accès contrôlé, où quinze membres sont chargés de produire les blocs. Les actifs utilisent un modèle lock & mint : en envoyant des actifs vers une adresse multisig de Liquid sur Bitcoin, on les transfère vers la sidechain ; pour les retirer, on envoie L-BTC vers une adresse multisig sur la chaîne Liquid. La sécurité de cette adresse est de 11 sur 15.
Liquid se concentre sur les applications financières, offrant aux développeurs des SDK dédiés aux services financiers. Actuellement, la TVL du réseau Liquid est d’environ 3000 BTC.
Nostr Assets : centralisation accrue
Initialement appelé NostrSwap, Nostr Assets était une plateforme d’échange BRC20. Le 3 août 2023, il est mis à jour en protocole Nostr Assets, supportant le transfert de tous les actifs de l’écosystème Nostr. Le règlement et la sécurité des actifs sont gérés par le réseau Lightning.
Nostr Assets permet aux utilisateurs Nostr d’envoyer et recevoir des actifs Lightning via leurs clés publiques/privées Nostr. À l’exception des dépôts et retraits, les transactions sur le protocole Nostr Assets sont gratuites (0 gas) et chiffrées. Les détails des transactions sont stockés sur les relais du protocole Nostr, accessibles rapidement et efficacement via IPFS, avec prise en charge des interactions en langage naturel, sans interface complexe.
Nostr Assets offre une méthode simple et pratique pour transférer et échanger des actifs. Associé à l’effet réseau de Nostr, il pourrait avoir de vastes cas d’usage. Cependant, en réalité, il s’agit simplement d’une méthode permettant aux messages Nostr de contrôler (héberger) un portefeuille. Lorsqu’un utilisateur dépose des actifs dans un relais Nostr Assets via un transfert Lightning, il les dépose en réalité dans un exchange centralisé. Quand deux utilisateurs veulent échanger des actifs via Nostr Assets, ils envoient un message signé par leurs clés Nostr au serveur, qui, après vérification, met simplement à jour son livre comptable interne, sans exécuter de transaction réelle sur Lightning ou sur la chaîne principale, permettant ainsi un TPS élevé et des frais nuls.
BitVM : programmabilité et évolutivité infinie
« Toute fonction calculable peut être vérifiée sur Bitcoin »
— Robin Linus, créateur de BitVM
Proposé par Robin Linus, fondateur de ZeroSync, BitVM utilise les opcodes existants de Bitcoin (OP_BOOLEAN, OP_NOT) pour former des circuits NAND, décompose tout programme en combinaisons de portes NAND, et place la racine du spend script complexe dans une transaction Taproot, avec un faible coût de stockage sur chaîne. Selon la théorie du calcul, toute logique peut être construite avec des portes NAND, donc en théorie BitVM peut rendre Bitcoin Turing-complet. Mais en pratique, de nombreuses limitations subsistent.
BitVM conserve un mode de fonctionnement P2P, s’inspirant des OP Rollups, avec deux rôles : le prover (prouveur) et le verifier (vérificateur). À chaque interaction, ils construisent conjointement une transaction, déposent une caution. Le prover fournit un résultat ; si le verifier obtient un résultat différent, il soumet une preuve de fraude sur chaîne pour confisquer la caution du prover.
« L’application véritablement disruptive, c’est l’évolutivité de Bitcoin. [Robin Linus] n’est pas fan des contrats intelligents. Il ne cherche pas à enrichir l’expressivité de Bitcoin. Son vrai objectif est de permettre à Bitcoin de traiter des millions de transactions par seconde. »
— Super Testnet, développeur BitVM
BitVM améliore la programmabilité, mais comment cela se relie-t-il à l’évolutivité ? En réalité, BitVM a été conçu dès le départ pour l’évolutivité par calcul hors chaîne et vérification sur chaîne, comme le suggèrent les rôles de prover et verifier.
Le meilleur cas d’usage de BitVM serait en réalité les ponts à confiance minimale et l’évolutivité ZKP (ZK Rollup). La proposition de BitVM est en quelque sorte une solution de repli : obtenir le soutien de la communauté Bitcoin en proposant de nouveaux opcodes est trop difficile, donc on utilise les opcodes existants pour créer de nouvelles fonctionnalités.
BitVM propose un nouveau paradigme d’évolutivité, mais fait face à de nombreux défis pratiques :
• Trop précoce : EVM dispose d’une architecture complète de machine virtuelle, alors que BitVM n’a pour l’instant qu’une fonction vérifiant si une chaîne est 0 ou 1.
• Surcoût de stockage : construire un programme avec des portes NAND peut nécessiter des centaines de mégaoctets de données, voire des milliards de feuilles taptree.
• Mode P2P : actuellement limité à deux parties, l’architecture prover-challenger pose des problèmes d’incitation. Des extensions vers 1-N ou N-N sont envisagées, comme dans les OP Rollup idéaux (hypothèse d’un seul honnête).
Conclusion
L’analyse globale montre clairement que, face aux limites de traitement et de calcul de la chaîne principale, Bitcoin doit déporter le calcul hors chaîne pour développer un écosystème plus riche et diversifié.
D’un côté, les solutions de validation client-side, combinant calcul et vérification hors chaîne, utilisent certains champs des transactions Bitcoin pour stocker des informations critiques, considérant la chaîne principale comme un système de journaux distribué. Elles exploitent sa résistance à la censure et sa fiabilité pour garantir la disponibilité des données clés. D’un certain point de vue, cela ressemble à des rollups souverains. Ces solutions n’exigent pas de modification du protocole Bitcoin, permettent une liberté de conception, et sont plus réalisables à court terme, mais n’héritent pas pleinement de la sécurité de Bitcoin.
D’un autre côté, certains travaillent à la vérification sur chaîne, tentant d’utiliser les outils existants pour réaliser des calculs arbitraires sur Bitcoin, puis d’appliquer des preuves à connaissance nulle (ZKP) pour une évolutivité efficace. Mais ces solutions sont encore très expérimentales, avec un coût de calcul excessivement élevé, et ne seront probablement pas opérationnelles à court terme.
Certains pourraient demander : pourquoi refaire tout cela sur Bitcoin, alors que des blockchains comme Ethereum offrent déjà une puissance de calcul élevée ?
Because It's Bitcoin.
Parce que c’est Bitcoin.
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
@CGVFOF
