Les actifs émis sur BTC : projets existants et leurs guides respectifs

Source: Bytecoin CKB

Je sais que, dès qu’il s’agit de ce problème, les puristes de Bitcoin pourraient penser : est-ce que Bitcoin ne pourrait pas simplement être l’or numérique tranquille ? Pourquoi avoir des Jetons ? Pourquoi avoir USDT ? Cependant, si vous vous souciez particulièrement de la sécurité des actifs, vous ne pouvez pas vous empêcher de penser : que se passerait-il si Ethereum venait à s’effondrer ? Qui prendrait en charge DeFi ? De plus, le protocole Jeton est compatible avec le protocole Bitcoin et ne perturbera pas ses fonctionnalités d’origine. Si vous n’aimez pas, vous n’êtes pas obligé de télécharger le client Jeton et cela n’aura pas beaucoup d’impact sur vous.

émission de Jeton sur Bitcoin : pourquoi est-ce impossible ?

Sur Bitcoin, l’émission de Jeton est utilisée pour transférer les transactions d’actifs du monde réel hors de la chaîne. Cette idée est apparue dans la communauté Bitcoin vers 2010. Les premières discussions de la communauté envisageaient de déplacer des actifs du monde réel tels que l’immobilier, les actions, les Monnaies Fiat, etc. vers Bitcoin pour des transactions décentralisées. Cependant, en raison de facteurs juridiques, le transfert d’actifs tels que l’immobilier et les actions n’est pas aussi facile. Même si vous payez un Jeton d’actif numérique pour votre maison à une autre personne, le gouvernement peut ne pas reconnaître cela et peut automatiquement changer le titre de propriété du monde réel, et il peut également être soumis à divers impôts. De plus, les transactions hors chaîne ne peuvent pas être effectuées librement sous la réglementation.

Par conséquent, la méthode la plus attrayante consiste à émettre des Jetons liés à la Monnaie Fiat, c’est-à-dire des stablecoins. Les stablecoins sont différents des jetons non fongibles, ils restent des jetons fongibles, mais ils sont distincts des BTC d’origine. Lorsqu’ils sont émis en tant que jetons, leur valeur est déterminée par le prix des actifs du monde réel qu’ils représentent, et non plus par le prix d’origine de la monnaie numérique (si le prix de la monnaie numérique augmente beaucoup plus que le prix de l’actif, il est également possible d’abandonner l’actif). C’est pourquoi les jetons sur BTC sont généralement émis en unités de Satoshi (Satoshi).

Pour utiliser Monnaie numérique comme Jeton d’actif, il est nécessaire de résoudre deux problèmes principaux :

1. Comment représenter des actifs du monde réel en BTC ;
2. Comment définir des règles de transaction et des contrats complexes dans le langage de script très limité de Bitcoin (BTC).

Le contenu ci-dessous se concentre sur ces deux points et résume les principaux schémas d’émission d’actifs BTC existants en termes de disponibilité des données, de support d’actifs, de performance et de scalabilité.

Le premier Jeton sur BTC: Jeton coloré

La personne qui a initialement conçu le protocole Jeton sur BTC est inconnue, et l’idée pourrait être née de discussions sur les forums ou les communautés BTC. Le projet Colored Coin a été lancé par Yoni Assia en 2012, et à l’époque, il a co-écrit le Livre blanc de Colored Coins avec Vitalik Buterin, Lior Hakim, Meni Rosenfeld et Rotem Lev.[1], Le projet a commencé en 2013.

Le fonctionnement du jeton de couleur consiste à marquer un Satoshi comme une monnaie spéciale et à écrire les informations associées à l’actif dans ce Satoshi - ce processus est appelé coloration. Vous pouvez colorer un Satoshi avec différentes couleurs et y apposer différentes étiquettes (tags), mais les pièces de monnaie de la même couleur ne peuvent toujours pas être distinguées, par exemple un tas de Satoshi colorés en dollars reste homogène. Les protocoles plus anciens utilisaient le champ nSequence, en ajoutant une étiquette dans le premier nSequence de l’input UTXO d’une transaction. Cependant, la limite de stockage de nSequence n’est que de 4 octets, donc la plupart des jetons conçus ultérieurement ont été remplacés par le champ OP_RETURN, qui peut stocker plus de métadonnées.

Le jeton de couleur est actuellement principalement mentionné parce qu’il est le premier projet Jeton sur Bitcoin. En raison du développement du projet qui n’est pas vraiment idéal et n’a pas été largement appliqué, le projet lui-même a été progressivement oublié. Le problème auquel le jeton de couleur était confronté à l’époque était que la fonction de Bitcoin ne pouvait pas encore prendre en charge cette idée assez avant-gardiste, et il était très difficile de concrétiser cette idée et de la faire fonctionner de manière efficace et stable. C’est peut-être pourquoi Vitalik, après le projet de jeton de couleur, s’est tourné vers l’opposé de Bitcoin et est si passionné par les smart contracts.

Parce que la monnaie colorée existe sous forme de connaissance, sa validation est similaire à la validation de la validité d’un UTXO, ce qui nécessite le téléchargement de l’ensemble de la chaîne. Ce problème sera résolu ultérieurement par une validation côté client (client-side validation).

Utilisation de OP_RETURN pour émettre des jetons : Counterparty & Omni Layer

Contrairement aux jetons colorés, Counterparty[2][3]Et Omni LayerLe protocole derrière USDT n’est pas directement coloré sur la blockchain, mais un UTXO avec une valeur de 0 est défini lors des transactions, et les métadonnées sont stockées dans OP_RETURN de ce UTXO. OP_RETURN peut stocker 80 octets, marquant que le UTXO de OP_RETURN ne peut pas être dépensé, et le vrai jeton est enregistré dans le i-ème output de OP_RETURN. La valeur de cet output est généralement de 0,00000546 BTC, la valeur la plus basse autorisée par le système à envoyer. Comme la valeur du jeton n’est pas liée au BTC, il n’est pas nécessaire d’envoyer une valeur supérieure à 0,00000546 BTC.

La validation de ces projets doit être effectuée hors chaîne, les métadonnées sont stockées hors chaîne.

Omni Layer a été un joueur sur la chaîne ETH pendant longtemps, jusqu’à récemment, quand il est revenu à l’écosystème BTC pour émettre des BTC-USDT. Counterparty a misé une partie de ses BTC et possède son propre Jeton XCP. De Twitter[4]Je pense que dernièrement ils se concentrent sur les NFT.

Pour en savoir plus sur OP_RETURN, veuillez consulter :

1. Une analyse des métadonnées OP RETURN de Bitcoin[5]
2. Construisez manuellement l’envoi de USDT avec OP_RETURN[6]

Ancrez BTC avec Sidechain: Rootstock & Liquid Network

Rootstock[7][8]Et le réseau Liquid[9]Ces deux projets sont apparus vers 2017, tous deux sont des solutions de chaînes latérales - échangeant des bitcoins sur des chaînes latérales de manière bidirectionnelle (Two-way peg), et utilisant divers DeFi et dApps sur des chaînes latérales compatibles avec l’EVM. Ils sont similaires au WBTC.Le jeton (RSK a RBTC, Liquid a L-BTC) vise principalement les personnes qui souhaitent construire sur l’écosystème Ethereum avec du BTC.

Émettre des jetons sur Rootstock est similaire à l’émission sur l’ETH, ou l’on peut dire que ce sidechain Rootstock, à l’exception de Mining qui se fait avec la chaîne Bitcoin, est conçu pour s’adapter à l’écosystème de l’ETH, par exemple, le code de contrat intelligent est également écrit en Solidity. Ainsi, les jetons ici sont émis sur la base de RBTC et n’ont aucun lien direct avec BTC.

由于本文主要suivre公链，而 Liquid Network 是一个联盟链，这里不深入讨论。

Pour en savoir plus sur RSK, consultez :

• RSK : une sidechain Bitcoin avec des contrats intelligents à état (document RSK)[10]
• RSK money[11]
• FAQs[12]

Les projets mentionnés précédemment, certains d’entre eux ont disparu (comme les pièces teintées), d’autres vendent sous le couvert de BTC mais en réalité, ils appartiennent à l’écosystème d’Éther. Cela est principalement dû au fait qu’après avoir accueilli le capital, Ethereum a acquis un avantage absolu sur le marché de la Finance décentralisée et des dApps, donc il est plus difficile pour les projets de la Finance décentralisée qui ne jouent pas avec lui d’obtenir un avantage. Les Jetons sur Ethereum sont émis et échangés via des contrats, conformément à des standards de jetons tels que ERC-20. L’écosystème BTC a également commencé à débloquer des fonctionnalités de contrat au cours des deux dernières années, telles que BitVM, et des Jetons conformes au standard BRC-20 ont également fait leur apparition.

Réalisation de Smart Contracts sur BTC : RGB

Créé en 2016, RGB (Really Good for Bitcoin)[13]Initialement conçu pour rivaliser avec les pièces colorées. Cependant, face à des défis similaires, il s’est tourné vers l’activation de contrats intelligents sur Bitcoin. Bien qu’il se concentre principalement sur l’exécution de contrats intelligents plutôt que sur la création de jetons, les fonctionnalités de contrat complet restent limitées jusqu’en 2024 en raison des limitations de leur machine virtuelle AluVM.

L’idée de RGB est de placer les données hors chaîne et le code de contrat intelligent en dehors de Bitcoin, en utilisant la racine de Merkle pour fournir des engagements de vérification des transactions et d’émission de jetons, la chaîne Bitcoin ne faisant que la vérification des engagements de transaction et la finalité, prouvant l’absence de double dépense.

Un aspect intéressant de la valeur RGB est l’utilisation simultanée de la validation côté client et de la technologie de scellage unique, de sorte qu’elle ne marque pas les jetons sur l’UTXO. Ces deux concepts ont été introduits pour la première fois par Peter Todd en 2013.[14]Proposé, Giacomo Zucco et Maxim Orlovsky ont conçu le protocole RGB sur cette base.

La validation côté client (Client-side validation) permet aux données et au code utilisés pour la transaction d’être stockés en dehors de la chaîne, sans être diffusés publiquement. Certaines données peuvent n’être échangées que de manière privée entre les deux parties à la transaction, sans que d’autres personnes non impliquées dans la transaction en soient informées. L’état off-chain est maintenu par BTC, la blockchain agit comme un horodatage et peut prouver la séquence chronologique de l’état.

Et un sceau à usage unique (single-use seal) - c’est aussi ce à quoi ressemble le plus souvent la vérification côté client - est une version numérique d’un sceau à usage unique. Il utilise la propriété selon laquelle chaque UTXO ne peut être dépensé qu’une seule fois pour écrire les informations de l’é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, et les informations d’état mises à jour sont écrites dans un nouveau UTXO généré. Ces informations d’état hors chaîne peuvent être la propriété de Jeton USDT ou le nombre de Jeton dans un contrat spécifique.

Par exemple, Alice souhaite transférer un USDT à Bob. Ce USDT n’existe pas off-chain en BTC, ses informations sont stockées off-chain, mais il est lié à une UTXO contrôlée par Alice. Ses informations sont stockées dans le champ OP_RETURN de la transaction qui a généré cette UTXO avec une valeur de zéro. De cette manière, seul Alice peut dépenser ce USDT, et Bob peut suivre les transactions off-chain pour savoir dans quelles UTXO ce USDT a été stocké, si ces UTXO sont valides et si la transaction est légale. Ainsi, lorsque Alice initie une transaction pour transférer ces informations d’engagement USDT à une UTXO contrôlée par Bob, Bob peut être sûr qu’il a reçu ce USDT.

RGB peut également fonctionner sur le réseau Lightning, car son état est hors chaîne, il suffit de placer l’engagement hors chaîne ou sur le réseau Lightning. Après la mise à niveau de Taproot, RGB peut intégrer l’engagement dans une transaction Taproot, ce qui permet à RGB d’intégrer l’engagement dans BTC hors chaîne de manière plus flexible.

Pour en savoir plus sur RGB, consultez : le plan RGB[15]

Prise en charge uniquement des Jetons, pas des contrats intelligents : Actif Taproot

Taproot Asset est Lightning Network Daemon (LND)[16][17]Projet développé par l’équipe. Son principe est similaire à celui de RGB, mais ne prend pas en charge les contrats intelligents complexes, uniquement les jetons (voir l’entrée TAPROOT icil’explication).

Pour en savoir plus sur la validation côté client, RGB et Taproot, veuillez consulter :

1. Validation côté client[18]
2. Transactions hors chaîne : l’évolution des protocoles d’actifs Bitcoin[19]
3. Contrepartie vs RGB vs TARO[20]

Rendre chaque Satoshi unique : Ordinaux & Inions

Casey Rodarmor a lancé l’Ordinal Protocol début 2023[21]Ce projet est né d’une idée : comment donner un numéro à chaque satoshi afin qu’il ait un numéro de séquence unique pour être classé. Cette idée est apparue en même temps que les jetons colorés, mais n’a été proposée que l’année dernière. De plus, grâce à l’ajout des fonctionnalités SegWit et Taproot, sa mise en œuvre est devenue moins difficile. L’ordinal rend chaque satoshi unique, ce qui permet aux NFT d’être directement émis sur la chaîne Bitcoin.

Inions[22]C’est juste un projet NFT comme ça. Les données NFT sont stockées dans les données témoins de la transaction, plutôt que dans le champ OP_RETURN utilisé précédemment par le projet, ce qui permet de stocker des métadonnées d’une taille inférieure ou égale à 4 Mo. Contrairement aux NFT sur Ethereum, Inion est un stockage sur chaîne, comprenant des métadonnées et des images.

Pour en savoir plus sur les ordinaux, consultez :

1. Ordinaux : un terrain commun pour les maximalistes d’Ethereum et de Bitcoin ?[23]
2. Le Guide Ultime des Ordinaux et Inions Bitcoin[24]

Liaison bidirectionnelle de n’importe quelle chaîne UTXO : Liaison isomorphe RGB++

RGB++[25][26]Au début, il s’agissait de BTC et de CKB (Nervos NetworkLe protocole de liaison isomorphique (isomorphic binding protocol) entre les deux chaînes UTXO a été introduit pour la première fois dans le contexte de la compatibilité entre CKB et BTC. Maintenant, ce protocole peut être utilisé pour lier théoriquement n’importe quelles deux chaînes UTXO ensemble.

RGB++ va encore plus loin dans l’exploitation des idées de validation côté client et de sceaux à usage unique de RGB. Comme mentionné précédemment, le plus gros problème du protocole RGB est que les données sont stockées localement par l’utilisateur. Si l’utilisateur perd accidentellement les données sans les sauvegarder, il ne pourra pas les récupérer. De plus, étant donné que l’utilisateur ne stocke que les données liées à son Jeton, il est plus difficile de vérifier d’autres données. La solution de la couche de liaison homomorphe consiste non seulement à lier le Jeton au champ OP_RETURN de la transaction BTC UTXO, mais aussi à lier les informations de transaction BTC correspondantes aux transactions off-chain de CKB (en ajoutant des CKB Cell)[27]Dans le verrouillage, utilisez un IB-lock spécial pour le réaliser. Lorsqu’il s’agit de déterminer si une transaction CKB hors chaîne est légale, le verrouillage utilisera les données du client léger BTC sur CKB pour voir si l’UTXO correspondant a été dépensé, et si le nouveau UTXO généré après la dépense est lié aux informations de transaction Jeton actuelles (en tant qu’informations non signées).

Les caractéristiques de RGB++ à suivre:

• Résoudre le problème de disponibilité des données par liaison bidirectionnelle : la cellule CKB s’engage à lier le champ OP_RETURN de l’UTXO ; les informations de l’UTXO sont liées à la cellule de sortie de la transaction CKB.
• Compatible avec Lightning Network et Fiber Network (basé sur CKB de Lightning Network)
• Soutien à plusieurs actifs
• Peut être lié à n’importe quelle chaîne UTXO

Pour en savoir plus sur RGB++, veuillez consulter :

1. Document de présentation de RGB++ Protocol[28]
2. Le Guide Ultime de RGB, RGB++ et de la Validation Côté Client[29]

Pour mieux comprendre les avantages et les limites de chaque projet, nous avons comparé les projets ci-dessus dans le tableau ci-dessous. Les indicateurs à suivre sont notamment :

• Disponibilité des données : Les chaînes isomorphes (isomorphic-chain) et les sidechains sont presque identiques, tandis que la disponibilité des données hors chaîne est plus faible que les autres solutions. L’ordre de résistance de la disponibilité des données est le suivant : hors chaîne ≥ chaînes isomorphes ≥ sidechains > hors chaîne ;
• Porteur d’actifs (Asset carrier) : Le schéma Jeton directement lié à BTC est préférable aux schémas non directement liés ;
• Fungibilité：Il s’agit ici de savoir si le Jeton natif du projet est interchangeable, et non pas si le projet ne prend pas en charge les Jetons non fongibles, ces derniers pouvant être mis en œuvre en ajoutant un protocole supplémentaire；
• Expressivité : fait référence à la capacité de traiter des contrats intelligents complexes.

Les liens mentionnés dans le texte :[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

base de connaissances/ultime_guide_vers_rgb_rgbpp_et_validation_côté_client[29]