
À la découverte des solutions d'extension de l'écosystème BTC : quel avenir pour les inscriptions ?
TechFlow SélectionTechFlow Sélection

À la découverte des solutions d'extension de l'écosystème BTC : quel avenir pour les inscriptions ?
Explorer les principes technologiques de l'écosystème populaire des inscriptions et les problèmes de sécurité potentiels.
Rédaction : Simon shieh
Préambule
Le 6 décembre 2023, alors que les investisseurs en Bitcoin célébraient l'essor du réseau grâce aux inscriptions (Inscriptions), Luke Dashjr, développeur du client nœud Bitcoin Core, a jeté un seau d'eau froide sur la communauté. Il a qualifié les inscriptions d’attaque de type « spam » et a soumis un correctif ainsi qu’un rapport de vulnérabilité CVE (CVE-2023-50428). La communauté Bitcoin s’est alors retrouvée en ébullition, replongeant dans un débat aussi intense que celui provoqué par le fork dur de 2017.

Faut-il que Bitcoin privilégie la sécurité au détriment de certaines fonctionnalités inattendues, ou doit-il être plus tolérant envers l'innovation imprévue quitte à accepter quelques compromis sur la sécurité ?
Nous savons que le parcours du Bitcoin ne se limite pas à la spéculation et aux effets de mode, mais constitue une évolution continue de son écosystème et de son paysage sécuritaire. Cet article explore en profondeur la double narration de la croissance du Bitcoin : l’expansion constante de son utilité au sein de son écosystème et le renforcement des mesures de sécurité. Nous examinerons comment l’innovation et des protocoles sécurisés robustes interagissent pour ouvrir la voie à une nouvelle ère des actifs numériques.
1 Aperçu de l’écosystème BTC et notions fondamentales
Considéré comme la pierre angulaire de la révolution des cryptomonnaies, le Bitcoin a longtemps été perçu comme un stock de valeur similaire à l’or. Pendant que d'autres blockchains développaient activement des innovations dans le domaine DeFi, on semblait presque avoir oublié l’existence même du Bitcoin.
Pourtant, c’est précisément sur Bitcoin que les pionniers ont mené les premières expérimentations avec les stablecoins, les solutions Layer 2, voire même le DeFi. Par exemple, l’USDT, aujourd’hui monnaie courante dans le monde crypto, a été initialement émis sur le réseau Omnilayer de Bitcoin. L’image ci-dessous illustre une classification technique de base de l’écosystème Bitcoin.

Parmi ces technologies figurent les sidechains basées sur un ancrage bidirectionnel, l’analyse de texte via le script OP_RETURN, les gravures reposant sur les scripts Taproot, les sidechains pilotées par BIP300, ainsi que le réseau Lightning basé sur des canaux d’état.
Beaucoup de ces termes peuvent sembler obscurs pour l’instant. Ne vous inquiétez pas : nous allons d’abord revoir les bases, puis expliquer progressivement les principes techniques de chaque composant de cet écosystème, tout en abordant leurs problématiques de sécurité.
UTXO : unité fondamentale des transactions Bitcoin
Contrairement au modèle de solde par compte utilisé par Ethereum, Bitcoin ne possède pas de notion de « compte ». Ethereum utilise quatre arbres Merkle Patricia complexes pour stocker et vérifier l’évolution des états des comptes. En revanche, Bitcoin adopte une approche bien plus élégante et concise grâce aux UTXO (Unspent Transaction Outputs – Sorties de transaction non dépensées).

Les quatre arbres d’Ethereum

Entrées et sorties dans Bitcoin
Le terme UTXO (Sortie de transaction non dépensée) peut sembler compliqué, mais devient clair dès lors qu’on comprend les concepts d’entrée, de sortie et de transaction.
Entrées et sorties dans une transaction
Ceux familiers d’Ethereum savent que la transaction est l’unité fondamentale de communication dans un réseau blockchain. Une fois incluse dans un bloc et confirmée, elle implique un changement définitif d’état sur la chaîne. Dans Bitcoin, une transaction n’est pas une simple opération d’un compte à un autre, mais consiste plutôt en plusieurs scripts d’entrée et de sortie.

L’image ci-dessus montre une transaction typique 2 vers 2 dans Bitcoin. Théoriquement, la somme des entrées doit égaler celle des sorties. En pratique, la différence entre les deux correspond aux frais de transaction, qui sont perçus par le mineur ayant extrait le bloc — un concept équivalent aux frais de gaz (Gas Fee) sur Ethereum.
On observe que les deux adresses d’entrée doivent fournir une preuve dans le script d’entrée afin de justifier leur droit à dépenser ces entrées (c’est-à-dire des UTXO issus de transactions précédentes). Le script de sortie, quant à lui, précise les conditions requises pour dépenser ces sorties futures. Autrement dit, lorsqu’une sortie non dépensée sera utilisée comme entrée dans une prochaine transaction, quelles conditions devront être remplies (en général, une signature de l’adresse destinataire ; par exemple, P2wPKH exige une signature d’adresse Taproot, tandis que P2PKH demande une signature de clé privée d’adresse classique).
Structurellement, une transaction Bitcoin se présente comme suit :

Une transaction Bitcoin repose sur deux composants essentiels : les entrées et les sorties. Les entrées identifient l’initiateur de la transaction, tandis que les sorties indiquent le destinataire et éventuellement la monnaie rendue. Les frais de transaction correspondent à la différence entre le total des entrées et celui des sorties. Étant donné que chaque entrée correspond à la sortie d’une transaction antérieure, ces sorties constituent l’élément central de la structure transactionnelle.
Cette structure forme une chaîne. Sur le réseau Bitcoin, toute transaction valide peut être tracée jusqu’à une ou plusieurs sorties antérieures. Ces chaînes débutent par les récompenses de minage et se terminent par les sorties non encore dépensées. L’ensemble des UTXO existants dans le réseau constitue ce qu’on appelle la base globale des UTXO.
Sur le réseau Bitcoin, chaque entrée d’une nouvelle transaction doit provenir d’un UTXO. En outre, chaque entrée nécessite une signature générée avec la clé privée associée à la sortie précédente. Chaque nœud du réseau conserve une copie complète des UTXO actuels pour valider la légitimité des nouvelles transactions. Grâce au mécanisme UTXO et à la vérification par signature, les nœuds peuvent valider une transaction sans avoir à remonter toute l’historique — simplifiant ainsi le fonctionnement et la maintenance du réseau.
La structure unique des transactions Bitcoin respecte le design décrit dans le livre blanc original : « Bitcoin : Un système de cash électronique peer-to-peer ». Bitcoin est un système de monnaie électronique dont la structure transactionnelle imite les transactions en espèces : le montant disponible sur une adresse dépend de la somme des espèces reçues auparavant. Chaque transaction implique de dépenser intégralement le solde disponible, avec généralement deux sorties : l’une pour le destinataire, l’autre pour la monnaie rendue — comme lors d’un paiement en liquide en supermarché.
Les scripts
Les scripts jouent un rôle crucial dans le réseau Bitcoin. En réalité, chaque sortie d’une transaction Bitcoin pointe vers un script, et non vers une adresse spécifique. Ces scripts définissent les règles selon lesquelles le destinataire peut utiliser les fonds verrouillés.
La validation d’une transaction repose sur deux types de scripts : le script de verrouillage (locking script) et le script de déverrouillage (unlocking script). Le premier est inclus dans la sortie de la transaction et fixe les conditions à remplir pour dépenser les fonds. Le second, fourni dans l’entrée, doit satisfaire ces conditions afin de libérer les UTXO. Ce langage de script, bien que limité, permet diverses combinaisons de conditions, illustrant le caractère partiellement programmable du Bitcoin.
Chaque nœud du réseau Bitcoin exécute un interpréteur de pile qui traite ces scripts selon la règle « premier entré, dernier sorti » (FILO).
Les deux types de scripts les plus courants sont P2PKH (Pay-to-Public-Key-Hash) et P2SH (Pay-to-Script-Hash). P2PKH est simple : le destinataire doit signer avec sa clé privée pour accéder aux fonds. P2SH est plus complexe, permettant par exemple des signatures multiples (multisig), où plusieurs clés privées sont nécessaires pour autoriser une dépense.
Ces scripts et leurs mécanismes de vérification forment le cœur du fonctionnement du réseau Bitcoin, assurant à la fois sécurité et souplesse.
Par exemple, le script de sortie P2PKH dans Bitcoin suit cette règle :
Script public : OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
L’entrée doit fournir une signature :
Script de signature : sig
Pour P2SH, le script de sortie est :
Script public : OP_HASH160 OP_EQUAL
L’entrée doit fournir une liste de signatures :
Script de signature : [sig] [sig...]
Dans ces deux cas, le « script public » représente le script de verrouillage, et le « script de signature » le script de déverrouillage. Les commandes préfixées par OP_ sont des instructions interprétables par les nœuds. Ces règles varient selon le type de script public, déterminant ainsi les exigences du script de déverrouillage.
Le système de scripts de Bitcoin est relativement simple : il s’agit d’un moteur basé sur une pile, capable d’interpréter un nombre limité d’instructions OP_, ne permettant pas de logique très complexe. Toutefois, il a posé les bases de la programmabilité blockchain, inspirant de nombreux projets ultérieurs. Avec les mises à jour SegWit et Taproot, le nombre d’opcodes disponibles a augmenté, tout comme la taille maximale des scripts par transaction, entraînant une croissance explosive de l’écosystème Bitcoin.
2 Principes techniques des inscriptions et problèmes de sécurité
L’essor des inscriptions repose largement sur les mises à jour SegWit et Taproot de Bitcoin.
Techniquement, plus un réseau blockchain est décentralisé, moins il est efficace. Dans le cas du Bitcoin, la taille de chaque bloc reste figée à 1 Mo, exactement comme le premier bloc extrait par Satoshi Nakamoto. Face à la question de la scalabilité, la communauté Bitcoin n’a pas choisi d’augmenter brutalement la taille des blocs. Elle a plutôt opté pour une solution appelée « Segregated Witness » (SegWit), une mise à niveau sans fork dur visant à optimiser la structure des données dans les blocs pour améliorer la capacité et l’efficacité du réseau.
Segregated Witness (SegWit)
Dans une transaction Bitcoin, les données se divisent en deux parties principales : les données fondamentales de la transaction et les données de témoignage (witness). Les premières incluent des informations financières critiques telles que les soldes, tandis que les secondes servent à authentifier l’identité de l’utilisateur. Pour l’utilisateur, seul l’aspect financier directement lié aux actifs importe vraiment — l’authentification n’a pas besoin d’occuper autant d’espace. En d’autres termes, le destinataire s’intéresse surtout à la disponibilité des fonds, pas aux détails du transfert.
Or, dans la structure actuelle, les données de témoignage (notamment les signatures) occupent une grande place, réduisant l’efficacité des transferts et augmentant les coûts de traitement. SegWit résout ce problème en séparant les données de témoignage des données principales de transaction, les stockant séparément. Cette séparation optimise l’utilisation de l’espace, améliore l’efficacité des transactions et réduit les coûts.

Ainsi, sans modifier la limite de 1 Mo par bloc, chaque bloc peut contenir davantage de transactions. Les données de témoignage (signatures, etc.) peuvent occuper jusqu’à 3 Mo supplémentaires, posant les bases du développement de scripts Taproot plus riches.
Taproot
Taproot est une mise à niveau importante par soft fork du réseau Bitcoin, conçue pour améliorer la confidentialité, l’efficacité et les capacités contractuelles intelligentes. Considérée comme le progrès majeur depuis SegWit en 2017, cette mise à jour regroupe trois propositions d’amélioration (BIP) : Taproot (arbre abstrait de syntaxe de Merkle, MAST), Tapscript, et un nouveau schéma de signature numérique compatible avec les multisignatures, nommé « signature Schnorr ».
Taproot offre plusieurs avantages aux utilisateurs : meilleure confidentialité, réduction des frais, et capacité accrue à exécuter des transactions complexes, élargissant ainsi les cas d’usage du Bitcoin.
La mise à jour Taproot impacte directement trois domaines de l’écosystème : le protocole Ordinals, qui exploite les scripts de chemin Taproot pour y ajouter des données ; l’évolution du réseau Lightning vers Taproot Assets, passant de simples paiements BTC point-à-point à un système multi-bénéficiaire permettant l’émission de nouveaux actifs ; et enfin BitVM, une proposition récente utilisant les opcodes op_booland et op_not pour « graver » des circuits booléens dans les scripts Taproot, réalisant ainsi une machine virtuelle de contrats intelligents.
Ordinals
Ordinals est un protocole inventé en décembre 2022 par Casey Rodarmor. Il attribue un numéro de série unique à chaque satoshi (sat) et permet de suivre leur mouvement. N’importe qui peut utiliser Ordinals pour attacher des données supplémentaires — textes, images, vidéos — dans le script Taproot d’un UTXO.
Les initiés connaissent le fait suivant : la quantité totale de Bitcoin est limitée à 21 millions, chaque BTC contenant 10⁸ satoshis. Il existe donc théoriquement 21 × 10¹⁵ sats. Le protocole Ordinals permettrait de distinguer chacun de ces sats par un identifiant unique. Cela est théoriquement possible, mais pratiquement irréalisable.
En effet, pour se prémunir contre les attaques par « poussière » (dust attacks), le réseau impose un minimum de transfert : 546 sats (ou 294 sats sous SegWit). Il est donc impossible de transférer un satoshi à la fois. Selon la logique FIFO (premier entré, premier sorti) d’Ordinals, les sats 1 à 294 de chaque bloc restent indivisibles.
Ainsi, une inscription n’est pas gravée sur un satoshi isolé, mais dans le script d’une transaction comportant au moins 294 sats. Des services centralisés d’indexation (comme Unisat) suivent ensuite le mouvement de ces groupes de 294 ou 546 sats.
Méthode de codage des inscriptions dans les transactions
Théoriquement, une dépense de script Taproot ne peut être effectuée qu’à partir d’une sortie Taproot existante. Les inscriptions devraient donc suivre un processus en deux étapes : engagement (commit) puis révélation (reveal). D’abord, une transaction d’engagement crée une entrée Taproot basée sur un chemin de script, spécifiant les conditions de dépense/révélation. Ensuite, une transaction de révélation dépense cette sortie, exposant ainsi le contenu de l’inscription.
Toutefois, dans la pratique, les indexeurs ignorent souvent la phase de révélation et lisent directement dans le script d’entrée un fragment de code structuré autour de OP_FALSE OP_IF ... OP_ENDIF, extrayant ainsi le contenu de l’inscription.
Comme la combinaison OP_FALSE OP_IF empêche l’exécution du script, on peut y stocker n’importe quel contenu sans affecter la logique transactionnelle.
Voici comment une inscription texte contenant « Hello, world! » est sérialisée :
OP_FALSE OP_IF OP_PUSH "ord" OP_1 OP_PUSH "text/plain;charset=utf-8" OP_0 OP_PUSH "Hello, world!" OP_ENDIF
Le protocole Ordinals consiste essentiellement à sérialiser ce code dans un script Taproot.
Analysons une transaction réelle pour mieux comprendre le principe :
https://explorer.btc.com/btc/transaction/885d037ed114012864c031ed5ed8bbf5f95b95e1ef6469a808e9c08c4808e3ae
Examinons le champ witness à partir de 0063 (OP_FALSE OP_IF) :


En décodant cette partie du script témoin, on peut retrouver le contenu de l’inscription. Ici, il s’agit de texte brut, mais le même principe s’applique à d’autres formats (HTML, images, vidéos, etc.).
Vous pouvez également définir votre propre format d’encodage, voire utiliser un contenu chiffré connu uniquement de vous, même si cela ne sera pas affiché par les explorateurs Ordinals.
BRC20
Le 9 mars 2023, un utilisateur anonyme de Twitter nommé domo a publié une idée : créer un standard de jeton fongible sur le protocole Ordinals, baptisé BRC20. L’idée consiste à graver des chaînes JSON dans les scripts Taproot afin de déployer, frapper et transférer des jetons BRC-20.

Figure 1 : Début modeste du jeton BRC-20 (premier post de domo sur le sujet)
Source : Twitter (@domodata)

Figure 2 : Trois opérations initiales possibles pour un jeton BRC-20 (p = protocole, op = opération, tick = symbole / identifiant, max = offre maximale, lim = limite de frappe, amt = quantité)
Source : https://domo-2.gitbook.io/brc-20-experiment/, Binance Research
L’émetteur du jeton lance (deploy) le jeton BRC20 sur la chaîne. Les participants peuvent ensuite le frapper (mint) presque gratuitement (seuls les frais de minage s’appliquent). Une fois que le volume total frappé atteint « max », toute nouvelle tentative de mint est considérée comme invalide par les indexeurs. Ensuite, les détenteurs peuvent transférer (transfer) leurs jetons via des inscriptions.
À noter : Casey Rodarmor, créateur d’Ordinals, critique sévèrement l’usage massif de BRC20. Il a publiquement déclaré que BRC20 apporte du « spam » à son protocole. Son équipe a même demandé à Binance de retirer toute référence à « Ordinals » dans la description du jeton ORDI, refusant tout lien entre son protocole et ce jeton.
Protocoles étendus
BRC20 swap
Actuellement, Unisat, principal marché, indexeur et fournisseur de portefeuilles pour les inscriptions, propose un protocole BRC20 swap, déjà accessible en phase expérimentale.
Jusqu’alors, les transactions d’inscriptions ne pouvaient se faire qu’en utilisant des PSBT (Partialy Signed Bitcoin Transactions), un peu comme les signatures hors chaîne d’OpenSea, avec un service centralisé pour « matcher » acheteurs et vendeurs. Cela obligeait les actifs BRC20 à être échangés comme des NFT, avec faible liquidité et efficacité.
Le protocole BRC20 swap introduit un mécanisme de « modules » dans les chaînes JSON BRC20, permettant d’y déployer des scripts similaires à des contrats intelligents. Par exemple, avec un module swap, un utilisateur peut « verrouiller » ses BRC20 en les transférant à lui-même via une transaction dont l’inscription est piégée dans le module. Après avoir finalisé l’échange ou retiré sa liquidité, il peut lancer une nouvelle transaction pour récupérer ses jetons.
Actuellement, BRC20 swap fonctionne en mode « module noir », pour des raisons de sécurité : tant qu’un consensus et une vérification formelle ne sont pas établis, le montant que chaque utilisateur peut retirer est limité au total des fonds verrouillés dans le module — aucun utilisateur ne peut retirer plus que ce qui a été déposé.

Quand le comportement du module noir est bien compris, exécuté de manière fiable et accepté par davantage d’indexeurs, il passe progressivement au statut de « module blanc », marquant une mise à niveau par consensus. À ce stade, les dépôts et retraits deviennent pleinement libres.

De plus, étant donné que le protocole BRC20 et l’écosystème Ordinals en général en sont encore à leurs balbutiements, et qu’Unisat détient une influence et une réputation dominantes, il présente un risque de centralisation. L’architecture modulaire permet à d’autres prestataires de participer, favorisant ainsi une indexation plus décentralisée.
BRC420
Le protocole BRC420, développé par RCSV, étend les inscriptions par un mécanisme d’indexation récursive. Il permet de définir des formats d’actifs plus complexes, et établit une relation entre droits d’usage et royalties. Lorsqu’un utilisateur frappe un actif, il doit payer une redevance au créateur. Posséder une inscription permet aussi d’en céder l’usage moyennant un prix, stimulant ainsi l’innovation dans l’écosystème Ordinals.
BRC420 ouvre de vastes perspectives : au-delà de métavers plus complexes construits par références récursives, il permet aussi de concevoir un écosystème de contrats intelligents via des inscriptions de code elles-mêmes récursives.
ARC20
Le standard ARC20 est proposé par le protocole Atomicals. Ici, l’« atome » est l’unité de base, construit sur le satoshi, l’unité minimale de Bitcoin. Chaque jeton ARC20 est donc toujours adossé à 1 sat. De plus, ARC20 est le premier protocole à permettre la création d’inscriptions ou de NFT via une preuve de travail (PoW), similaire au minage de Bitcoin.
Associer 1 jeton ARC20 à 1 sat offre plusieurs avantages :
1. La valeur d’un jeton ARC20 ne peut jamais descendre en dessous de 1 sat, faisant du Bitcoin une sorte d’« ancre dorée numérique ».
2. La validation des transactions se fait simplement en consultant l’UTXO associé au sat, contrairement à BRC20 qui nécessite un registre hors chaîne et un ordonnanceur tiers.
3. Toutes les opérations ARC20 peuvent être effectuées directement via le réseau Bitcoin, sans étape supplémentaire.
4. Enfin, grâce à la composable des UTXO, un échange direct entre jetons ARC20 et BTC devient théoriquement possible, ouvrant des perspectives de liquidité futures.
Le protocole Atomicals intègre
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












