Auteur de l'article : Yunwen Liu 1, Institut de recherche de Biyuan
Je sais que, dès que ce sujet est abordé, les puristes de Bitcoin peuvent penser : n'est-il pas mieux que Bitcoin reste tranquillement de l'or numérique ? Pourquoi avoir besoin de jetons ? Pourquoi avoir besoin d'USDT ? Cependant, si vous êtes particulièrement soucieux de la sécurité des actifs, vous devez penser : que se passera-t-il si Ethereum échoue ? Qui pourra soutenir DeFi ? De plus, les solutions de jetons sont compatibles avec le protocole Bitcoin et ne détruisent pas les fonctionnalités d'origine, si vous ne les aimez pas, vous pouvez ne pas télécharger le client de jetons, vous ne serez pas trop affecté.
Émettre des jetons sur Bitcoin : Pourquoi pas ?
Émettre des jetons sur Bitcoin pour transférer les transactions d'actifs du monde réel sur la chaîne, cette idée est apparue dans la communauté Bitcoin vers 2010. Les premières discussions dans la communauté imaginaient transférer des actifs du monde réel - tels que des biens immobiliers, des actions, des devises - sur Bitcoin pour effectuer des transactions décentralisées. Cependant, en raison de facteurs juridiques, il n'est pas si facile de transférer des actifs tels que des biens immobiliers et des actions. Même si vous transférez votre actif numérique de propriété à une autre personne, le gouvernement peut ne pas le reconnaître, ou le certificat de propriété du monde réel peut ne pas être automatiquement mis à jour, et il peut également y avoir divers impôts à payer. De plus, vous ne pouvez pas effectuer librement des transactions sur la chaîne sous réglementation.
Par conséquent, une approche plus attrayante consiste à émettre des jetons liés à des stablecoins. Les stablecoins diffèrent des NFT, car ils restent des jetons fongibles, mais sont distincts du Bitcoin d'origine. Lorsqu'ils apparaissent sous forme de jetons, leur valeur est déterminée par le prix des actifs du monde réel qu'ils représentent, sans tenir compte du prix d'origine des monnaies numériques (si le prix de la monnaie numérique augmente beaucoup par rapport au prix de l'actif, il n'est pas impossible d'abandonner l'actif). C'est pourquoi les jetons sur Bitcoin sont généralement exprimés en satoshis.
Pour utiliser la monnaie numérique comme actif de jeton, deux problèmes majeurs doivent être résolus :
Comment représenter des actifs du monde réel avec Bitcoin ;
Comment établir des règles et des contrats de transaction complexes dans le langage de script très limité de Bitcoin.
Le contenu ci-dessous se concentre sur ces deux points, résumant plusieurs des principales solutions d'émission d'actifs Bitcoin existantes, en les comparant sur des aspects tels que la disponibilité des données, le support d'actifs, l'expressivité, l'évolutivité, etc.
Le premier jeton sur Bitcoin : les jetons colorés
Les premières personnes à concevoir un protocole de jetons sur Bitcoin sont inconnues, l'idée pourrait provenir de discussions sur les forums ou dans la communauté Bitcoin. Le projet de jetons colorés a été lancé par Yoni Assia en 2012, lorsque lui et Vitalik Buterin, Lior Hakim, Meni Rosenfeld, Rotem Lev ont rédigé le livre blanc des jetons colorés, le projet a commencé à fonctionner en 2013.
Le fonctionnement des jetons colorés consiste à marquer un satoshi comme une pièce spéciale, en écrivant des informations pertinentes sur cet actif dans ce satoshi - ce processus est appelé coloration. Vous pouvez colorer un satoshi dans différentes couleurs, en lui attribuant différents tags, mais les pièces de la même couleur ne peuvent toujours pas être distinguées, par exemple, un groupe de satoshis colorés en dollars reste fongible. Des protocoles plus anciens utilisaient le champ nSequence, ajoutant un tag dans nSequence du premier UTXO d'entrée de la transaction. Cependant, la limite de stockage de nSequence est de 4 octets, donc les conceptions de jetons ultérieures ont essentiellement changé pour utiliser le champ OP_RETURN, qui peut stocker plus de métadonnées.
Les jetons colorés sont principalement mentionnés parce qu'ils sont le premier projet de jetons sur Bitcoin. En raison du développement du projet qui n'a pas été idéal et de son absence d'application à grande échelle, le projet lui-même a progressivement été oublié. Le problème auquel les jetons colorés étaient confrontés à l'époque était que les fonctionnalités de Bitcoin ne pouvaient pas encore soutenir cette idée assez avancée, et sa mise en œuvre, stable et efficace, était très difficile. Cela pourrait aussi expliquer pourquoi Vitalik s'est tourné vers le côté opposé de Bitcoin après le projet de jetons colorés, devenant si passionné par les contrats intelligents.
Étant donné que les jetons colorés existent sous forme de satoshis, leur validation nécessite de télécharger l'ensemble de la chaîne, tout comme la validation d'un UTXO. Ce problème sera résolu plus tard par la validation côté client.
Envoyer des jetons avec OP_RETURN : Counterparty & Omni Layer
Contrairement aux jetons colorés, Counterparty et Omni Layer (le protocole derrière USDT) ne colorent pas directement les satoshis, mais définissent un UTXO avec une valeur de 0 dans la transaction, où les métadonnées sont stockées dans l'OP_RETURN de cet UTXO. L'OP_RETURN peut contenir 80 octets, indiquant que l'UTXO d'OP_RETURN ne peut pas être dépensé, le véritable jeton étant la i-ème sortie enregistrée dans l'OP_RETURN. La valeur de cette sortie est généralement de 0.00000546 BTC—la valeur minimale autorisée pour l'envoi, et comme la valeur des jetons n'est pas liée au BTC, il n'est pas nécessaire d'émettre plus que 0.00000546 BTC.
La validation de ces projets doit se faire sur la chaîne, les métadonnées sont stockées sur la chaîne.
Omni Layer a été un acteur sur la chaîne Ethereum pendant longtemps, jusqu'à récemment, il est revenu dans l'écosystème Bitcoin, prêt à émettre BTC-USDT. Counterparty a mis en jeu une partie de Bitcoin et a son propre jeton XCP. D'après Twitter, il semble qu'ils travaillent actuellement sur des NFT.
Pour en savoir plus sur OP_RETURN, consultez :
Une analyse des métadonnées Bitcoin OP RETURN
Construire manuellement OP_RETURN pour envoyer USDT 1
Ancrage de Bitcoin avec des chaînes latérales : Rootstock & Liquid Network
Les projets Rootstock et Liquid Network sont apparus vers 2017, tous deux étant des solutions de chaînes latérales - utilisant un ancrage bidirectionnel pour échanger des Bitcoins vers des chaînes latérales et utiliser divers Defi et dApps sur des chaînes compatibles avec EVM. Ils ont des jetons similaires à WBTC (RSK a RBTC, Liquid a L-BTC), principalement destinés aux personnes souhaitant utiliser BTC pour construire dans l'écosystème Ethereum.
Émettre des jetons sur Rootstock fonctionne de la même manière que sur Ethereum, ou l'on peut dire que cette chaîne latérale, à part le minage qui se fait avec la chaîne Bitcoin, a été conçue pour s'adapter à l'écosystème Ethereum, par exemple le code des contrats intelligents est également écrit en Solidity. Ainsi, les jetons ici sont émis sur la base de RBTC et n'ont pas de lien direct avec le BTC.
Étant donné que cet article se concentre principalement sur les chaînes publiques, et que le Liquid Network est une chaîne de consortium, nous n'entrerons pas dans les détails ici.
Pour en savoir plus sur RSK, consultez
RSK : une chaîne latérale Bitcoin avec des contrats intelligents avec état (document RSK)
Monnaie RSK
FAQs
Certains des projets mentionnés précédemment ont disparu (comme les jetons colorés), d'autres utilisent Bitcoin comme façade tout en vendant des solutions basées sur l'écosystème Ethereum. Cela est principalement dû au fait qu'Ethereum, après avoir embrassé le capital, a dominé le marché avec DeFi et dApps, rendant difficile pour les projets DeFi qui ne jouent pas avec lui de gagner un avantage. Les jetons sur Ethereum sont émis et échangés via des contrats, suivant des normes telles que ERC-20. L'écosystème Bitcoin a également commencé à déverrouiller des fonctionnalités de contrat au cours des deux dernières années, comme BitVM, et un standard de jetons BRC-20 est également apparu.
Mettre en œuvre des contrats intelligents sur Bitcoin : RGB
RGB (Really Good for Bitcoin), né en 2016, a été initialement conçu comme un concurrent des jetons colorés. Mais face à des défis similaires, il s'est tourné vers l'activation des contrats intelligents sur Bitcoin. Bien qu'il se concentre principalement sur l'exécution des contrats intelligents et non sur l'émission de jetons, ses fonctionnalités de contrat complet restent limitées jusqu'en 2024 en raison des restrictions de sa machine virtuelle AluVM.
L'idée de RGB est de placer les données hors chaîne et le code des contrats intelligents en dehors de Bitcoin, en utilisant la racine Merkle pour fournir des engagements de vérification des transactions et d'émission de jetons, la chaîne Bitcoin se contentant de vérifier les engagements de transaction et la finalité, prouvant qu'il n'y a pas eu de double dépense.
Ce qui mérite d'être mentionné à propos de RGB, c'est qu'il utilise à la fois la validation côté client et la technique des sceaux à usage unique, de sorte qu'il ne marque pas l'UTXO pour indiquer le jeton. Ces deux concepts ont été proposés pour la première fois par Peter Todd en 2013, et Giacomo Zucco et Maxim Orlovsky ont conçu le protocole RGB sur cette base.
La validation côté client permet de conserver les données et le code utilisés dans les transactions hors chaîne, ne les rendant pas publics. Certaines données peuvent être échangées uniquement entre les deux parties de la transaction, tandis que d'autres personnes non liées à la transaction peuvent ne rien savoir. L'état hors chaîne est maintenu par Bitcoin, et la blockchain joue le rôle de marqueur temporel, prouvant l'ordre des états.
Le sceau à usage unique - il s'agit également de la forme la plus courante de validation côté client - est une version numérique d'un sceau à usage unique. Il utilise la nature du fait que chaque UTXO ne peut être dépensé qu'une seule fois pour écrire des informations d'état hors chaîne dans un UTXO. Ainsi, si à un moment donné cet UTXO est dépensé, nous savons que l'état a été mis à jour, les informations d'état mises à jour sont écrites dans le nouvel UTXO généré. Ces informations d'état hors chaîne peuvent être la propriété du jeton USDT ou le nombre de jetons dans un contrat.
Par exemple, si Alice veut transférer un USDT à Bob, cet USDT n'existe pas sur la chaîne Bitcoin, ses informations sont maintenues hors chaîne, mais il sera lié à un UTXO contrôlé par Alice. Ses informations sont sauvegardées dans la transaction qui a généré cet UTXO, dans le champ OP_RETURN de l'UTXO dont la valeur est nulle. Ainsi, seul Alice peut dépenser cet USDT, et Bob peut tracer cet USDT dans les transactions passées sur la chaîne, vérifiant les UTXO où il a été conservé, s'ils sont valides et si la transaction est légale. Ainsi, lorsque Alice initie une transaction, transférant les informations d'engagement de cet USDT à un UTXO contrôlé par Bob, Bob peut être sûr qu'il a reçu cet USDT.
RGB peut également fonctionner sur le réseau Lightning, car son état est hors chaîne, nécessitant simplement de placer l'engagement sur la chaîne ou sur le réseau Lightning. Après la mise à niveau Taproot, RGB peut incorporer l'engagement dans une transaction Taproot, permettant une intégration plus flexible de l'engagement dans la chaîne Bitcoin.
Pour en savoir plus sur RGB, consultez :
RGB Blueprint 1
Supporte uniquement les jetons, ne supporte pas les contrats intelligents : Actifs Taproot
L'actif Taproot est un projet développé par l'équipe Lightning Network Daemon (LND). Son principe est similaire à RGB, mais ne prend pas en charge les contrats intelligents complexes, ne prenant en charge que les jetons.
Pour en savoir plus sur la validation côté client, RGB et Taproot, consultez
Validation côté client
Transactions hors chaîne : l'évolution des protocoles d'actifs Bitcoin
Counterparty vs RGB vs TARO
Rendre chaque satoshi unique : Ordinals & Inscriptions
Casey Rodarmor a publié le protocole Ordinal au début de 2023. Ce projet est né de l'idée suivante : comment numéroter les satoshis pour qu'ils aient tous un numéro de série unique afin d'être classés. Cette idée a été proposée à la même époque que les jetons colorés, mais a été redéveloppée l'année dernière. Avec l'ajout des fonctionnalités SegWit et Taproot, sa mise en œuvre est devenue beaucoup plus facile. Ordinals rend chaque satoshi unique, permettant ainsi aux NFT d'être émis directement sur la chaîne Bitcoin.
Les Inscriptions sont un projet NFT de ce type. Les données NFT sont stockées dans les données witness de la transaction, et non pas dans le champ OP_RETURN utilisé précédemment, ce qui permet de stocker des métadonnées d'une taille inférieure à 4 Mo. Contrairement aux NFT sur Ethereum, l'Inscription est stockée sur la chaîne, incluant les métadonnées et les images.
Pour en savoir plus sur les ordinals, consultez :
Ordinals : un terrain d'entente commun pour les maximalistes d'Ethereum et de Bitcoin ?
Le guide ultime des Ordinals et Inscriptions Bitcoin
Liaison bidirectionnelle de n'importe quelle chaîne UTXO : liaison isomorphe RGB++
RGB++ a été initialement présenté comme un protocole de liaison isomorphe entre BTC et CKB (la base de Nervos Network), mais maintenant son champ d'application est vaste, il n'est pas limité à la liaison entre CKB et BTC, tant que ce sont deux chaînes UTXO, ce protocole peut théoriquement être utilisé pour les lier.
RGB++ a poussé plus loin les idées de validation côté client et de sceaux à usage unique. Comme mentionné précédemment, le principal problème du protocole RGB est que les données sont conservées localement par l'utilisateur. Si un utilisateur perd accidentellement ses données, il n'y a pas de sauvegarde et il est impossible de les récupérer. De plus, comme l'utilisateur ne conserve que les données liées à ses propres jetons, il est plus difficile de valider d'autres données. La solution de la couche de liaison isomorphe consiste non seulement à lier les jetons au champ OP_RETURN de l'UTXO Bitcoin, mais aussi à lier les informations de transaction Bitcoin correspondantes à une transaction sur la chaîne CKB (en utilisant un script de verrouillage spécial dans le script de verrouillage de la cellule CKB). Lorsque l'on juge si une transaction sur la chaîne CKB est légale, le script de verrouillage utilisera les données du client léger BTC sur CKB, vérifiant si l'UTXO correspondant a été dépensé et si le nouvel UTXO généré est lié aux informations de transaction de ce jeton.
Caractéristiques intéressantes de RGB++ :
Résoudre le problème de disponibilité des données par une liaison bidirectionnelle :
L'engagement de la cellule CKB lié au champ OP_RETURN de l'UTXO
Les informations UTXO liées à la cellule de sortie de la transaction CKB
Compatible avec le réseau Lightning et le réseau Fiber (réseau Lightning basé sur CKB)
Supporte plusieurs actifs
Peut être lié à n'importe quelle chaîne UTXO
Pour en savoir plus sur RGB++, consultez :
Document léger du protocole RGB++
Le guide ultime de RGB, RGB++ et de la validation côté client
Pour mieux comprendre les avantages et les limites de chaque projet, nous avons comparé les projets ci-dessus dans le tableau ci-dessous. Parmi les indicateurs à surveiller, on trouve :
Disponibilité des données : la chaîne isomorphe et la chaîne latérale se ressemblent, tandis que la disponibilité des données hors chaîne est inférieure à celle des autres solutions. Le classement de fort à faible est : chaîne principale ≥ chaîne isomorphe ≥ chaîne latérale > hors chaîne ;
Support d'actifs : Les projets de jetons directement liés au BTC sont meilleurs que ceux qui ne sont pas directement liés ;
Fongibilité : Cela fait référence à la possibilité d'échanger les jetons natifs du projet entre eux, ce n'est pas parce que le projet ne prend pas en charge l'émission de NFT, qui peut être réalisée par des protocoles supplémentaires ;
Expressivité : fait référence à la capacité de traiter des contrats intelligents complexes.
