Développement de jetons, NFT et solutions DeFi sur Bitcoin
Le développement de jetons, de NFT et de solutions DeFi sur Bitcoin se révèle être plus complexe qu’il n’y paraît. Sur des plateformes comme la Machine Virtuelle Ethereum (EVM) et d’autres systèmes de contrats intelligents, les contrats sont Turing-complets, ce qui permet d’ajouter de nouvelles fonctionnalités simplement en déployant un contrat personnalisé. En revanche, sur Bitcoin, les développeurs doivent faire preuve de prudence pour innover sans risquer de provoquer un hard fork, et ils ne peuvent travailler que dans les limites des fonctions protocollaires existantes.
Comme nous l’avons mentionné précédemment, l’un des éléments clés qui rendent Bitcoin unique et précieux est son attachement à l’originalité, et sa chaîne principale a subi peu de modifications au fil du temps. Malgré cela, Bitcoin a été la première blockchain à connaître une adoption massive, et de nombreuses technologies qui ont été par la suite mises en œuvre sur des blockchains plus flexibles ont vu leurs premières graines sur Bitcoin. En effet, les NFT ont d’abord émergé sur Bitcoin sous la forme de « Colored Coins » ; le concept de State Channels partage une certaine similarité avec l’architecture actuelle L1-L2 ; et les Atomic Swaps ont posé les bases des ponts inter-chaînes modernes.
Nous avons déjà présenté certains de ces développements dans l’article précédent intitulé « Partir de Bitcoin : La véritable origine du DeFi ». Pour véritablement apprécier la valeur inégalée de Bitcoin en tant qu’infrastructure pour Botanix et d’autres chaînes Bitcoin, il est essentiel d’approfondir notre compréhension de la façon dont ces premières innovations ont pavé la route vers l’écosystème actuel. Bien que Bitcoin lui-même soit relativement « simple », il s’avère être l’un des écosystèmes les plus complexes et fascinants du domaine Web3, possédant la plus riche des histoires.
Explorer la théorie fonctionnelle de Bitcoin : Les capacités de Bitcoin peuvent-elles soutenir un écosystème complexe ?
Lorsque Bitcoin a été lancé en 2009, il était doté d’un langage de script intégré qui permettait non seulement des paiements simples, mais soutenait également des opérations plus complexes, telles que les multi-signatures et les verrouillages temporels, dès le départ. Satoshi Nakamoto avait même stipulé que les transactions non confirmées utilisant nLockTime et des numéros de séquence pouvaient être mises à jour plusieurs fois entre deux parties pour des transactions à haute fréquence, et seul l’état final serait inscrit sur la chaîne. Le Bitcoin Script est un mécanisme intrigant : d’une part, il est Turing-incomplet, ce qui limite sa fonctionnalité ; d’autre part, il reste simple et sécurisé.
Par conséquent, lorsqu’il s’agit de construire des fonctions complexes sur Bitcoin, les développeurs doivent opérer dans le cadre fourni par le Script. Le script Bitcoin contient un grand nombre d’opcodes permettant de programmer diverses actions, qui seront finalement inscrites dans les données de transaction. On peut considérer le Script comme une recette, un ensemble d’étapes pour préparer un gâteau. Les opcodes sont les éléments constitutifs de ce langage ; ce sont les instructions de base que les programmeurs utilisent lorsqu’ils écrivent des scripts, tels que « mélanger » et « chauffer ».
Pour mieux comprendre la fonction du Script, examinons brièvement les types de scripts les plus courants. Une étude du NCC Group a résumé 156 modèles de scripts différents et a réalisé une analyse détaillée de ces structures. Peut-on alors envisager d’utiliser le Script pour organiser un mécanisme semblable à DeFi sur Bitcoin ? Poursuivons notre exploration.
Mécanisme de prêt
Comme mentionné précédemment, les opcodes peuvent être combinés pour construire une série de petites chaînes d’instructions afin d’atteindre des comportements plus complexes. Par exemple, les développeurs peuvent créer des scripts complexes avec des fonctions de contrat de prêt en combinant des opcodes. Cela peut être réalisé par une combinaison de verrouillages temporels et de multi-signatures, permettant ainsi de mettre en œuvre « des contrats d’entiercement bilatéraux avec des délais ». Par exemple, supposons qu’Alice fournisse des BTC comme garantie et que Bob lui prête des stablecoins hors ligne.
Ils souhaitent établir les règles suivantes par le biais du contrat : si Alice ne rembourse pas le prêt à temps, Bob obtiendra ses BTC ; si elle rembourse à temps, les BTC seront débloqués et retournés à Alice. Pour cela, ils peuvent utiliser une sortie multi-signature 2-of-2 (les deux, Alice et Bob, doivent signer pour accéder aux fonds). Ensuite, ils peuvent définir la logique du script : si le prêt n’est toujours pas remboursé après avoir atteint une certaine hauteur de bloc, seul Bob peut utiliser les fonds.
Cependant, il existe une difficulté majeure : Bitcoin lui-même ne peut pas calculer automatiquement les intérêts, ni surveiller les taux de collatéralisation, ni faire respecter les liquidations. Tous les paiements d’intérêts doivent être effectués hors chaîne ou avec des transactions pré-signées, ce qui est compliqué dans la pratique. Si le prix du BTC chute pendant la période de prêt, le script Bitcoin lui-même ne peut pas le savoir et ne peut donc pas déclencher automatiquement la liquidation. Pour réaliser cette fonction, un oracle ou un protocole hors chaîne doit être utilisé. Sans un oracle, le contrat ne peut que faire des jugements basés sur l’expiration finale. Par conséquent, il est très difficile d’implémenter directement le prêt de stablecoins garantis par le BTC sans confiance sur la couche Bitcoin.
Fonctionnalités AMM
Les mécanismes de prêt et de staking peuvent théoriquement être mis en œuvre via le Bitcoin Script, mais en pratique, ils sont moins efficaces. Cependant, nous pouvons tout de même explorer la possibilité de construire des mécanismes plus complexes tels que les teneurs de marché automatisés (AMMs) sur Bitcoin. Le Bitcoin Script contient des opcodes mathématiques comme OP_ADD, OP_SUB et OP_MUL (bien que certains d’entre eux aient été désactivés) ainsi que des opcodes de comparaison comme OP_LESSTHAN. En théorie, ces fonctions peuvent être exploitées pour intégrer une logique de calcul des prix.
Les développeurs peuvent construire un script avec un prix fixe ou un ensemble de points de prix acceptables prédéfinis, mais il est impossible d’ajuster dynamiquement le prix après chaque transaction. La raison en est que Bitcoin utilise un modèle UTXO, et chaque transaction génère un nouveau UTXO et script, donc chaque état possible doit être pré-calculé, ou un contrat doit être redéployé après chaque transaction.
Un autre facteur essentiel pour l’implémentation d’AMM est la capacité d’échanger des actifs. En théorie, Bitcoin prend en charge les échanges atomiques, qui peuvent être construits sous la forme de carnets de commandes plutôt que de pools de liquidités. Un comportement similaire à celui des AMMs peut également être simulé en construisant une série de contrats de verrouillage de temps de hachage (HTLC) ou en émettant des ordres en attente à différents prix pour former un système automatisé de création de marché statique (similaire à une courbe de rendement).
Cependant, le maintien d’un tel système est très lourd, et le script doit être mis à jour manuellement et re-UTXO après chaque transaction, ce qui engendre des coûts d’opérations on-chain extrêmement élevés. Ainsi, bien qu’il soit théoriquement possible de construire un AMM, il existe un obstacle majeur en pratique : il n’y a qu’un seul actif natif, le BTC, sur la mainnet Bitcoin.
Bien que des protocoles comme le protocole Omni fournissent un mécanisme de jetons, ces actifs existent dans les métadonnées de la transaction et ne peuvent pas être reconnus et traités par le script. Par conséquent, un échange d’actifs véritable ou le maintien d’un pool de liquidités via le Bitcoin Script est impossible. De plus, le modèle UTXO de Bitcoin ne prend pas en charge un seul contrat détenant les fonds de plusieurs parties simultanément tout en mettant à jour des soldes partiels – chaque changement d’état nécessite une nouvelle transaction et plusieurs signatures.
Fonctionnalité étendue du script
Les points ci-dessus expliquent pourquoi Bitcoin subit régulièrement des mises à jour majeures pour améliorer sa fonctionnalité. L’une des mises à jour importantes est Taproot, introduite par un soft fork, mais qui a profondément modifié la manière dont le script est conçu. Avec l’introduction de la mise à jour Taproot (BIP 342), de nombreux opcodes précédemment désactivés ou réservés ont été convertis en opcodes OP_SUCCESS dans Tapscript (c’est-à-dire des scripts SegWit v1).
OP_SUCCESS signifie que tant que l’opcode est exécuté, le script se termine immédiatement avec succès. Cette conception facilite et sécurise l’intégration de nouveaux opcodes par le biais de soft forks. Dans Tapscript, si la valeur de l’opcode se situe dans une plage spécifique (par exemple : 0x50, 0x62, 0x7E–0x81, 0x83–0x86, 0x89–0x8A, 0x8D–0x8E, 0x95–0x99, 0xBB–0xFE), il sera considéré comme OP_SUCCESSx. Dès que ces opcodes sont rencontrés, le script sera automatiquement jugé comme réussi et d’autres logiques seront ignorées.
Ce mécanisme remplace l’ancienne méthode de mise à niveau OP_NOP (aucun opcode), apportant une sécurité et une flexibilité accrues. De futures soft forks peuvent redéfinir le comportement d’un certain opcode OP_SUCCESS, et les nœuds de version ancienne le prendront toujours pour un « succès du script », évitant ainsi des transactions invalides causées par des incohérences de version.
En résumé, tous les opcodes non énumérés comme « disponibles » sont soit réservés, soit ont été convertis pour retourner toujours un OP_SUCCESS réussi dans Taproot. Un autre aspect important est que les opcodes peuvent être proposés via le processus BIP (Bitcoin Improvement Proposal), et il existe déjà des propositions prometteuses à l’étude ou rejetées. Certaines de ces propositions, si elles sont adoptées, élargiront considérablement la fonctionnalité de Bitcoin, lui permettant d’effectuer des opérations plus complexes.
Pourquoi ces opcodes n’ont-ils pas encore été approuvés ? La principale raison pourrait être que la communauté des développeurs Bitcoin est extrêmement prudente dans le but de préserver l’intégrité originale de Bitcoin. D’un côté, l’introduction de nouvelles fonctionnalités peut réellement améliorer l’utilisabilité et l’évolutivité de Bitcoin ; de l’autre, Bitcoin lui-même est un réseau conçu pour être « lent », et cette « lenteté » est également perçue comme l’une de ses caractéristiques « originales ».
Prenons, par exemple, OP_CSFS appliqué au mécanisme de liquidation : la vitesse est un facteur clé. Si le marché s’effondre et que le prix du BTC chute brusquement, un paradoxe pourrait survenir : premièrement, la charge de la blockchain augmente et la vitesse du réseau ralentit encore plus ; deuxièmement, le temps de traitement des transactions dans le réseau Bitcoin aura un retard significatif.
Il est très probable que le prix ait rebondi avant que la transaction de liquidation on-chain ne soit effectuée. Ainsi, la lenteur du fonctionnement de Bitcoin et ses frais de transaction extrêmement élevés lors des périodes de forte charge rendent les tentatives de mise en œuvre natales des mécanismes DeFi sur le mainnet fondamentalement peu sensées. Pour cette raison, les développeurs en sont arrivés progressivement à la conclusion plus raisonnable selon laquelle une couche d’extension devrait être construite sur Bitcoin. C’est en fait le prédécesseur de l’idée de Rollup, le concept de « proto-paiement channel » : en soutenant de multiples micro-transactions hors chaîne, celles-ci sont finalement condensées en une transaction de règlement on-chain.
Dès avril 2011, la première dérivation de code de Bitcoin, Namecoin, a été créée, réalisant l’enregistrement de noms de domaine décentralisé (DNS « .bit ») grâce à la technologie Bitcoin. L’exemple de Namecoin – qui stocke des paires nom-valeur sur la chaîne – a d’abord démontré que le design de Bitcoin pouvait être utilisé non seulement pour les transactions monétaires, mais aussi pour d’autres actifs, même si cela peut nécessiter une structure de blockchain distincte.
Ces concepts ont jeté les bases pour des innovations futures en matière de tokenisation des actifs, de transactions décentralisées et d’expansion hors chaîne de Bitcoin.
Stablecoins : Quelle est leur efficacité dans l’écosystème Bitcoin ?
Les stablecoins font désormais partie intégrante de tout écosystème Web3, même ceux qui ne sont pas directement liés à DeFi. Ils permettent aux utilisateurs de couvrir le risque de volatilité et de transférer de l’argent sans se soucier des fluctuations de prix des actifs. Comme mentionné précédemment, le réseau Bitcoin a toujours cherché à équilibrer la simplicité fonctionnelle avec la quantité de données pouvant être enregistrées.
Fait intéressant, la première tentative d’émission d’actifs sur Bitcoin a été faite à travers le développement de « Colored Coins », qui est quelque peu similaire aux NFT. En 2012, JR Willett a proposé l’idée d’émettre de nouveaux actifs sur Bitcoin et a avancé le concept de « colored coins ». Il a ensuite contribué à la création du protocole Mastercoin (rebaptisé plus tard Omni), jetant ainsi les bases de la tokenisation d’actifs sur Bitcoin (y compris les jetons indexés sur des devises fiat).
Étant donné qu’il n’existe pas d’opcode « jeton » direct dans le Bitcoin Script standard, les développeurs ne peuvent intégrer que des métadonnées de jeton dans les sorties de transaction à l’aide de OP_RETURN (OP_RETURN rend la sortie non dépensable et inclut des données).
Avant la normalisation de OP_RETURN, même des scripts de multi-signatures étaient utilisés comme « solution détournée » pour encoder des données. Le script Bitcoin lui-même ne peut faire respecter aucune règle de jeton – ces règles sont maintenues par un logiciel hors chaîne responsable de l’analyse des transactions Bitcoin.
Les protocoles tels que Colored Coins, Omni Layer (anciennement Mastercoin), Counterparty et Open Assets représentent des jetons en « coloriant certains satoshis ou UTXOs ». Par exemple, le protocole Open Assets utilise une sortie OP_RETURN contenant des métadonnées précisant le nombre de jetons et l’ID de l’actif.
En essence, la blockchain Bitcoin elle-même n’a aucune connaissance des « jetons » – elle se contente de traiter des données. La validité des jetons (par exemple, l’offre, la propriété) est suivie par des portefeuilles externes après l’analyse des données OP_RETURN.
Il est important de noter que OP_RETURN a une limite en terme de taille pour les données. Selon la politique standard du client Bitcoin Core, chaque sortie OP_RETURN ne peut contenir que jusqu’à 80 octets de données arbitraires. Les données dépassant 80 octets seront considérées comme une « transaction non standard » et ne seront pas transmises par défaut. Théoriquement, une transaction peut contenir plusieurs sorties OP_RETURN pour accroître la quantité de données (jusqu’à 80 octets chacune), mais pour éviter un spam transactionnel, la politique de relais standard actuelle de Bitcoin ne permet généralement qu’une sortie OP_RETURN par transaction.
Cette capacité à intégrer des métadonnées dans les transactions Bitcoin a conduit à la création du protocole Mastercoin en 2012, rebaptisé plus tard Omni. L’Omni Layer a joué un rôle clé dans le fonctionnement précoce de Tether et est devenu le protocole de transmission sous-jacent pour le premier lot de transferts USDT. Pendant une période au milieu des années 2010, l’USDT basé sur Bitcoin (Omni) a été le stablecoin le plus dominant sur le marché, utilisé particulièrement dans des échanges tels que Bitfinex. Les transactions Omni sont essentiellement des transactions Bitcoin standard enrichies de métadonnées supplémentaires. Omni a ensuite développé plusieurs catégories d’implémentations différentes, formant sa propre voie d’évolution technique.
