Guide des projets existants et de leurs solutions pour l'émission d'actifs sur Bitcoin
TechFlow SélectionTechFlow Sélection
Guide des projets existants et de leurs solutions pour l'émission d'actifs sur Bitcoin
Et si Ethereum venait à tomber ? Qui pourrait reprendre le flambeau de la DeFi ?
Dédié à des analyses Web3 approfondiesAuteur de l'article :Yunwen Liu 1, Institut de recherche Nervos
Je sais que dès qu’on aborde ce sujet, les puristes du Bitcoin pourraient penser : pourquoi le Bitcoin ne resterait-il pas tranquillement une « monnaie d’or numérique » ? Pourquoi devrait-il forcément avoir des jetons ? Pourquoi faut-il absolument du USDT ? Toutefois, si vous accordez une grande importance à la sécurité de vos actifs, vous devez vous poser la question : et si Ethereum venait à s’effondrer ? Qui pourrait alors reprendre le flambeau du DeFi ? Par ailleurs, les solutions par jetons sont compatibles avec le protocole Bitcoin lui-même et n’en compromettent pas les fonctionnalités initiales. Si un utilisateur n’aime pas cela, il peut simplement ne pas télécharger le client prenant en charge les jetons, sans subir d’impact majeur.
Émettre des jetons sur Bitcoin : pourquoi pas ?
L'idée d'émettre des jetons sur Bitcoin afin de transférer les transactions d'actifs du monde réel vers la blockchain remonte environ à 2010 dans la communauté Bitcoin. Les premières discussions envisageaient de déplacer des actifs du monde réel — tels que l'immobilier, les actions ou les monnaies fiduciaires — sur la blockchain Bitcoin afin d'en permettre un échange décentralisé. Cependant, pour des raisons légales, il est difficile de transférer ce type d'actif. Même si vous transférez numériquement le jeton représentant votre maison à une autre personne, le gouvernement risque de ne pas le reconnaître ni automatiquement mettre à jour le titre foncier dans le monde réel, et des taxes diverses pourraient toujours être dues. En outre, sous surveillance réglementaire, ces actifs ne peuvent pas être librement échangés sur une chaîne publique.
C’est pourquoi une approche plus attrayante consiste à émettre des jetons indexés sur les monnaies fiduciaires, c’est-à-dire des stablecoins. Contrairement aux NFT, les stablecoins restent des jetons fongibles (fungible), simplement différenciés des bitcoins originels. Lorsqu'ils apparaissent comme des jetons, leur valeur dépend du prix de l'actif réel qu'ils représentent, et non plus du cours initial de la cryptomonnaie (si le prix de la cryptomonnaie augmente considérablement par rapport à celui de l'actif sous-jacent, on peut même choisir d'abandonner cet actif). C'est pourquoi les jetons sur Bitcoin sont généralement exprimés en satoshis (sats).
Pour utiliser une cryptomonnaie comme support d’un actif tokenisé, deux problèmes principaux doivent être résolus :
-
Comment représenter un actif du monde réel à l’aide du Bitcoin ;
-
Comment définir des règles complexes de transaction et des contrats au sein du langage de script très limité de Bitcoin.
Le contenu suivant se concentre sur ces deux points, présente un aperçu des principales solutions actuelles d’émission d’actifs sur Bitcoin, puis les compare selon plusieurs critères tels que la disponibilité des données, le support d’actifs, l’expressivité et l’extensibilité.
Le premier jeton sur Bitcoin : les Colored Coins
Impossible de savoir précisément qui a eu le premier l’idée d’un protocole de jetons sur Bitcoin, probablement lors de discussions sur les forums ou communautés Bitcoin. Le projet Colored Coin a été lancé en 2012 par Yoni Assia, qui a coécrit avec Vitalik Buterin, Lior Hakim, Meni Rosenfeld et Rotem Lev le « Whitepaper des Colored Coins ». Le projet a été opérationnel à partir de 2013.
Le principe des Colored Coins consiste à marquer un satoshi comme une unité monétaire spéciale, en y inscrivant des informations relatives à l’actif — ce processus s’appelle « coloration ». Un satoshi peut être coloré différemment, porteur de différentes balises (tags), mais les pièces d’une même couleur restent indistinguables entre elles : par exemple, un groupe de satoshis colorés en dollars reste fongible. Les premiers protocoles utilisaient le champ nSequence, ajoutant une marque dans le champ nSequence du premier UTXO d’entrée d’une transaction. Cependant, la capacité de stockage de nSequence étant limitée à 4 octets, les conceptions ultérieures ont majoritairement adopté le champ OP_RETURN, capable de stocker davantage de métadonnées.
Les Colored Coins sont aujourd’hui surtout mentionnés car ils constituent le premier projet de jetons sur Bitcoin. Mais en raison d’un développement peu concluant et d’une adoption à grande échelle quasi inexistante, le projet a progressivement été oublié. Les Colored Coins rencontraient alors un problème fondamental : les fonctionnalités de Bitcoin n’étaient pas encore suffisantes pour supporter cette idée novatrice, dont la mise en œuvre efficace et stable était extrêmement difficile. C’est peut-être aussi pourquoi Vitalik, après ce projet, s’est tourné contre Bitcoin et s’est passionné pour les contrats intelligents.
Comme les Colored Coins existent sous forme de satoshis, leur validation exige, tout comme celle d’un UTXO classique, de télécharger toute la chaîne. Ce problème sera par la suite résolu grâce à la validation côté client (client-side validation).
Émettre des jetons via OP_RETURN : Counterparty & Omni Layer
À la différence des Colored Coins, Counterparty et Omni Layer (le protocole derrière USDT) n’appliquent pas directement de « coloration » sur les satoshis. Ils créent plutôt un UTXO ayant une valeur nulle dans la transaction, et stockent les métadonnées dans le champ OP_RETURN de cet UTXO. OP_RETURN peut contenir jusqu’à 80 octets. Un UTXO marqué par OP_RETURN ne peut pas être dépensé. Le véritable jeton correspond au i-ème output enregistré dans OP_RETURN. Cette valeur est généralement fixée à 0,00000546 BTC — la valeur minimale autorisée pour un envoi — et comme la valeur du jeton n’est pas liée au BTC, il n’est pas nécessaire d’envoyer plus que cette somme.
La validation de ces projets s’effectue entièrement sur la chaîne, les métadonnées étant stockées sur la blockchain.
Omni Layer a longtemps opéré sur la chaîne Ethereum avant de revenir récemment vers l’écosystème Bitcoin, préparant le lancement du BTC-USDT. Counterparty a misé une partie de ses bitcoins et possède son propre jeton XCP. Selon leur compte Twitter, ils travaillent récemment sur des NFT.
Pour en savoir plus sur OP_RETURN, consultez :
Ancrage du Bitcoin via sidechain : Rootstock & Liquid Network
Les projets Rootstock et Liquid Network sont apparus vers 2017 environ. Il s’agit tous deux de solutions de sidechains — utilisant un ancrage bidirectionnel (two-way peg) pour échanger des bitcoins vers une sidechain, où sont ensuite utilisés divers DeFi et dApps compatibles EVM. Ils disposent de jetons similaires à WBTC (RSK a RBTC, Liquid a L-BTC), destinés principalement aux utilisateurs souhaitant intégrer le BTC dans l’écosystème Ethereum.
L’émission de jetons sur Rootstock suit exactement le même processus que sur Ethereum. On peut même dire que cette sidechain, bien qu’elle partage le minage avec Bitcoin, adapte toutes ses autres fonctionnalités à l’écosystème Ethereum — notamment l’écriture des contrats intelligents en Solidity. Ainsi, les jetons y sont émis sur la base de RBTC, sans lien direct avec BTC.
Étant donné que cet article se concentre sur les blockchains publiques, et que Liquid Network est une blockchain consortium, nous n’entrerons pas ici dans les détails.
Pour en savoir plus sur RSK, consultez :
Les projets mentionnés précédemment incluent certains qui ont disparu (comme les Colored Coins), d’autres qui utilisent le nom de Bitcoin tout en proposant en réalité un écosystème similaire à Ethereum. La raison principale est que, depuis qu’Ethereum a su attirer les capitaux, ses DeFi et dApps dominent largement le marché, rendant difficile pour tout projet DeFi concurrent de gagner en avantage. Sur Ethereum, les jetons sont émis et échangés via des contrats conformes aux standards comme ERC-20. L’écosystème Bitcoin commence seulement depuis deux ans à débloquer certaines fonctionnalités contractuelles, telles que BitVM, et voit apparaître des standards de jetons comme BRC-20.
Mettre en œuvre des contrats intelligents sur Bitcoin : RGB
RGB (Really Good for Bitcoin), né en 2016, a été initialement conçu comme concurrent des Colored Coins. Face à des défis similaires, il s’est orienté vers l’activation de contrats intelligents sur Bitcoin. Bien que son objectif principal soit l’exécution de contrats intelligents plutôt que l’émission de jetons, ses capacités contractuelles complètes restent limitées à ce jour (2024), en raison des restrictions imposées par sa machine virtuelle AluVM.
L’approche de RGB consiste à externaliser autant que possible les données et codes de contrat hors chaîne, en utilisant un Merkle root pour fournir un engagement (commitment) relatif à la validation des transactions et à l’émission de jetons. La chaîne Bitcoin sert uniquement à vérifier cet engagement et à assurer la finalité, prouvant ainsi qu’aucun double dépense n’a eu lieu.
Un point remarquable de RGB est son utilisation combinée de la validation côté client (client-side validation) et de la technique du sceau à usage unique (single-use seal). Contrairement aux méthodes marquant directement les UTXO, RGB n’utilise pas de marquage sur les UTXO pour représenter les jetons. Ces deux concepts ont été initialement proposés par Peter Todd en 2013, puis développés par Giacomo Zucco et Maxim Orlovsky pour concevoir le protocole RGB.
La validation côté client (Client-side validation) permet de garder les données et codes utilisés dans les transactions hors chaîne, sans diffusion publique. Certaines données peuvent même être échangées uniquement entre les parties concernées, restant totalement invisibles aux autres. L’état hors chaîne est sécurisé grâce à Bitcoin, la blockchain servant de tampon horaire pour prouver l’ordre chronologique des états.
Le sceau à usage unique (single-use seal) — souvent associé à la validation côté client — est une version numérique d’un sceau physique à usage unique. Il exploite le fait qu’un UTXO ne peut être dépensé qu’une seule fois, en y inscrivant des informations relatives à un état hors chaîne. Ainsi, lorsque cet UTXO est dépensé, on sait que l’état a été mis à jour, et les nouvelles informations d’état sont écrites dans un nouvel UTXO généré. Ces informations hors chaîne peuvent représenter la propriété d’un jeton USDT, ou le solde d’un contrat en nombre de jetons.
Par exemple, si Alice souhaite transférer un USDT à Bob, ce jeton n’existe pas directement sur la chaîne Bitcoin, mais ses informations sont maintenues hors chaîne, tout en étant lié à un UTXO contrôlé par Alice. Ces informations sont stockées dans le champ OP_RETURN d’un UTXO de valeur nulle, inclus dans la transaction ayant créé cet UTXO. Ainsi, seul Alice peut dépenser ce USDT, et Bob peut suivre via la chaîne les UTXO successifs ayant porté ce jeton, vérifier leur validité et la légalité des transactions. Lorsque Alice lance une transaction transférant l’engagement du jeton vers un UTXO contrôlé par Bob, Bob peut alors confirmer qu’il en est désormais propriétaire.
RGB peut également fonctionner sur le réseau Lightning, car son état est hors chaîne, nécessitant uniquement que l’engagement soit publié sur la chaîne ou sur Lightning. Après la mise à niveau Taproot, RGB peut intégrer ses engagements dans une transaction Taproot, offrant ainsi une flexibilité accrue pour ancrer les engagements sur la chaîne Bitcoin.
Pour en savoir plus sur RGB, consultez :
Jeton uniquement, pas de contrat intelligent : Taproot Assets
Taproot Assets est un projet développé par l’équipe du Lightning Network Daemon (LND). Son principe est similaire à RGB, mais il ne prend pas en charge les contrats intelligents complexes, se limitant aux jetons (voir à ce sujet l’explication du terme Taproot).
Pour approfondir Client-side validation, RGB et Taproot, consultez :
Rendre chaque satoshi unique : Ordinals & Inscriptions
Casey Rodarmor a publié début 2023 le protocole Ordinal. Ce projet repose initialement sur l’idée suivante : comment numéroter les satoshis afin que chacun ait un identifiant unique et puisse être ordonné ? Cette idée existe depuis l’époque des Colored Coins, mais n’a été relancée qu’au cours de l’année dernière. Grâce aux ajouts de SegWit et de Taproot, sa mise en œuvre est devenue beaucoup plus accessible. Ordinal rend chaque satoshi différent des autres, permettant ainsi l’émission directe de NFT sur la chaîne Bitcoin.
Inscriptions est justement un projet NFT basé sur ce principe. Les données des NFT sont stockées dans les données witness des transactions, et non plus dans le champ OP_RETURN utilisé par les projets précédents, permettant ainsi de stocker jusqu’à 4 Mo de métadonnées. Contrairement aux NFT sur Ethereum, les Inscriptions stockent les métadonnées et images directement sur la chaîne.
Pour en savoir plus sur les ordinaux, consultez :
Liaison isomorphe reliant toute paire d’UTXO : RGB++
RGB++ est apparu initialement comme protocole de liaison isomorphe (isomorphic binding protocol) entre BTC et CKB (Nervos Network), mais son champ d’application s’est élargi : il n’est plus limité à BTC et CKB, et peut théoriquement lier deux chaînes UTXO quelconques.
RGB++ pousse plus loin les concepts de Client-Side Validation et de Single-Use-Seals issus de RGB. Comme mentionné précédemment, le principal défaut du protocole RGB est que les données sont conservées localement par chaque utilisateur. Si un utilisateur perd accidentellement ses données, il n’y a ni sauvegarde ni récupération possible. De plus, comme chaque utilisateur ne conserve que les données liées à ses propres jetons, la vérification d’autres données devient difficile. La solution de couche de liaison isomorphe consiste à ne pas seulement lier le jeton au champ OP_RETURN d’un UTXO Bitcoin, mais aussi à ancrer les informations de transaction Bitcoin correspondantes dans une transaction sur la chaîne CKB (via un script de verrouillage spécial, IB-lock-script, dans les Cell de CKB). Lors de la vérification de la légalité d’une transaction sur CKB, le Lock Script utilise les données d’un light client BTC sur CKB pour vérifier si l’UTXO correspondant a été dépensé, et si le nouvel UTXO généré est bien lié aux informations de la transaction de jeton courante (sans signature).
Caractéristiques notables de RGB++ :
-
Résout le problème de disponibilité des données via liaison bidirectionnelle :
-
La Cell CKB s’engage à être liée au champ OP_RETURN d’un UTXO
-
Les informations UTXO sont liées à la Cell output d’une transaction CKB
-
-
Compatible avec le réseau Lightning et Fiber Network (réseau Lightning basé sur CKB)
-
Prend en charge les actifs multiples
-
Peut être lié à n’importe quelle chaîne UTXO
Pour en savoir plus sur RGB++, consultez :
Pour mieux comprendre les forces et limites de chaque projet, comparons-les dans le tableau ci-dessous. Les indicateurs clés à prendre en compte sont :
-
Disponibilité des données (Data availability) : les chaînes isomorphes et les sidechains sont comparables, tandis que la disponibilité des données hors chaîne est inférieure aux autres solutions. Classement du plus fort au plus faible : sur chaîne ≥ chaîne isomorphe ≥ sidechain > hors chaîne ;
-
Support d’actifs (Asset carrier) : les solutions de jetons directement liées au BTC sont supérieures à celles indirectement liées ;
-
Fongibilité (Fungibility) : concerne ici si les jetons natifs du projet sont interchangeables entre eux, et non si le projet supporte les NFT (ceci pouvant être ajouté par protocole supplémentaire) ;
-
Expressivité (Expressiveness) : capacité à gérer des contrats intelligents complexes.
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
