La prochaine mise à niveau majeure de Bitcoin?Évaluation de OP_CAT et OP

Auteur: Gabe Parker, analyste de Galaxy;

résumé

Le bitcoin adopte une attitude conservatrice envers les mises à niveau du protocole, ce qui rend les changements de consensus rares.Mais comme le montrent les mises à niveau précédentes de SEGWIT et de tapoot, les développeurs sont toujours disposés à optimiser le langage de programmation de Bitcoin et les paramètres de réseau.
Langue de programmation Bitcoin—Script bitcoin, la transaction ne peut pas transporter l’état mondial et a la capacité de faire de manière introspective, ce qui limite sa capacité expressive.
Il y a actuellement deux propositions principales,OP_CAT (BIP 347)etOP_CTV (BIP 119), Ils sont conçus pour améliorer la programmabilité des transactions Bitcoin et faire de la sortie des transactions plus de conditions de dépenses.Ces propositions peuvent améliorer considérablement les capacités du script Bitcoin et la rendre plus flexible.
Les scénarios d’application les plus prometteurs d’OP_CAT et d’OP_CTV incluent:Établir un pont transversal sans confiance entre la première couche (L1) et la deuxième couche (L2) de BitcoinAméliorer les solutions avancées de coffreAméliorations au réseau Lightning.
Le processus de gouvernance des mises à niveau des fourchettes souples implique plusieurs parties prenantes de Bitcoin.Les influenceurs des médias et les développeurs de base ont la plus grande influence dans les premiers stades de la conception du protocole et de l’examen technique.
Galaxy Research prédit que les développeurs de noyau de Bitcoin atteindront un consensus sur OP_CAT ou OP_CTV en 2025, mais en raison du processus d’activation complexe, il peut prendre 1 à 2 ans pour l’implémenter.

1. Introduction

Les modifications du protocole Bitcoin nécessitent une discussion et une collaboration entre plusieurs parties prenantes, y compris, mais sans s’y limiter, les développeurs de protocole, les nœuds complets, les utilisateurs finaux et les mineurs.Le processus de consensus pour obtenir des mises à niveau du protocole est complexe et controversé.Par exemple,La « bataille de taille de bloc » de 2015 à 2017Que la communauté Bitcoin soit divisée, une partie veut ajuster la taille du bloc, l’autre partie s’oppose.Des années de débat ont finalement conduit à une fourche permanente de blockchain et à la naissance d’une nouvelle crypto-monnaie –Bitcoin Cash, c’est une version fourchue de Bitcoin.

Étant donné la difficulté de parvenir à un accord pour changer de consensus, une mise à niveau majeure du Bitcoin est rare.Les développeurs du protocole Bitcoin rejettent les mises à niveau controversées, et il a été une longue histoire de temps pour mettre en œuvre ceux qui sont soutenus par la communauté Bitcoin plus large.Cela met en évidence l’engagement des développeurs envers les attitudes conservatrices envers le développement du bitcoin pour favoriser la prévisibilité, la fidélité des réseaux et la compatibilité arriérée.

Bien que les changements de consensus de Bitcoin soient rares, les développeurs de Bitcoin ont montré une attitude ouverte envers les scripts Bitcoin et l’optimisation des paramètres du réseau.La mise à niveau SEGWIT, née dans la bataille de la taille du bloc, ajoute en fait des limites de taille de bloc, permettant à plus de transactions d’être incluses dans le bloc.SEGWIT optimise également le format des données de transaction en modifiant l’unité de mesure des données de transaction des octets aux octets virtuels.Cette transition, associée au déplacement des données de signature dans le champ des témoins, permet à un bloc Bitcoin de contenir des données de transaction (environ 4 Mo) dans des unités de poids jusqu’à 4 m.La dernière fourchette Soft de Bitcoin est la mise à niveau de la tapoot 2021, qui introduit une langue de script mise à jour appelée Tapscript.Cette nouvelle version du script Bitcoin comprend un nouveau schéma de signature (SCHNORN Signature), améliore l’agrégation de clés, la fusion de plusieurs clés publiques et signatures dans une clé de signature.L’agrégation clé des signatures Schnorr réduit la quantité de données de transaction qui nécessite plusieurs signatures, tout en améliorant la confidentialité des transactions sur le réseau Lightning (la plus grande couche de paiement P2P de Bitcoin, construite au-dessus de la couche de base Bitcoin).Un bref aperçu de Segwit et Taproot suggère que bien que les développeurs de Bitcoin soient prudents quant aux changements de consensus de Bitcoin, cela ne signifie pas que les caractéristiques techniques de Bitcoin ne changeront pas.

Après Segwit et Taproot, les développeurs Bitcoin explorent désormais l’amélioration de la programmabilité des transactions de Bitcoin pour ajouter une logique de contrat intelligente supplémentaire à la transaction.Les contrats intelligents Bitcoin impliquent l’utilisation de conditions de dépenses, c’est-à-dire la possibilité de limiter et de contrôler la façon dont les résultats de transaction (UTXO) seront dépensés à l’avenir.Cet article examinera d’abord le script Bitcoin et comment il fonctionne avec le modèle de comptabilité UTXO de Bitcoin.Nous analyserons ensuite les deux OPCodes en attente OP_CTV et OP_CAT pour souligner comment ces OPCodes ont le potentiel d’améliorer le script Bitcoin pour inclure des fonctionnalités puissantes pour permettre une programmabilité des transactions efficace.Enfin, cet article met en évidence l’importance de la programmabilité des transactions à l’infrastructure bitcoin telle que le pontage et la garde et attend avec impatience la possibilité de consensus entre OP_CAT et OP_CTV et le chemin d’implémentation de ces opcodes dans la prochaine mise à niveau de la fourche douce.

2. Script Bitcoin et modèle UTXO

Bitcoin utilise un langage de script natif pour créer des transactions appelées « Bitcoin Scripts ».Le script se compose d’un ensemble d’instructions qui définit comment le destinataire de la transaction passe le bitcoin envoyé, également connu sous le nom de «condition de dépense».Le script Bitcoin se compose de 186 opcodes qui s’exécutent en fonctions de commande.Ces opcodes sont utilisés pour créer des règles officielles sur la façon dont les actifs Bitcoin sont dépensés et transférés sur le réseau.Par exemple, une transaction de hachage de paiement de paiement contient 4 opcodes qui appliquent les conditions de dépenses sur les transactions Bitcoin, où le bitcoin est dépensé sur une clé publique de hachage et ne peut être dépensé qu’en utilisant les clés publiques et privées correctes associées au consommateur.

Les scripts Bitcoin sont conçus pour la sortie de transaction non suivant de Bitcoin (modèle UTXO) qui utilisent l’entrée et la sortie.Chaque transaction Bitcoin comprend au moins 1 entrée et 1 sortie, bien que la plupart des transactions simples incluent au moins 1 entrée et 2 sorties (une partie de BTC à l’entrée est utilisée pour financer les transactions, dont une partie est envoyée au récepteur, et le reste est renvoyé au consommateur à la sortie).UTXO est un Bitcoin qui n’a pas encore été dépensé et peut être envoyé dans de futures transactions.Une fois que les UTXO sont utilisés comme entrées pour les transactions, ce ne sont plus des sorties.Par conséquent, lorsque les utilisateurs dépensent Bitcoin, les UTXO sont constamment créés et détruits.Voici un exemple de modèle UTXO simplifié:

* Si Alice avait un UTXO d’une valeur de 1 BTC dans son portefeuille et qu’elle a envoyé 0,5 BTC à Bob, l’entrée d’Alice serait de 1 BTC.* Sa sortie sera de 0,49 BTC (retournée à Alice) et 0,5 BTC (envoyée à Bob).La différence de 0,01 BTC représente le BTC payé aux frais de transaction (ces frais de transaction varieront en fonction de la congestion du réseau).* À la fin de cet accord, Alice aura un nouvel ensemble UTXO représentant ses 0,49 BTC restants.À l’étape 1, Alice détruit l’UTXO en utilisant sa valeur de 1 BTC d’UTXO comme première entrée de la transaction.À l’étape 2, Alice crée deux nouveaux Utxos d’une valeur de 0,5 BTC et 0,49 BTC, l’un lui est retourné comme son changement et l’autre payé à Bob.À l’étape 3, Alice a maintenant un nouvel UTXO d’une valeur de 0,49 BTC.Il convient de noter que si Alice doit payer Bob 0,5 BTC, Alice peut également utiliser plusieurs UTXOS à l’étape 1, avec un total de 0,5 BTC;Le modèle UTXO est une caractéristique clé du réseau Bitcoin et joue un rôle crucial dans le traitement et la vérification des transactions.

L’exemple UTXO ci-dessus est entièrement construit à l’aide de scripts Bitcoin.Chaque UTXO contient un script de verrouillage qui comprend un ensemble de conditions que l’UTXO est dépensée.Lorsque l’utilisateur prouve la propriété de l’entrée (dépenses UTXO) en fournissant la signature de clé privée correcte associée à la clé publique correspondante, le script de verrouillage UTXO est déverrouillé.Ces informations sont appelées «signature de script», et lorsque l’entrée contient la signature de script correcte, les conditions de dépenses sont remplies et le bitcoin peut être dépensé.Pour en revenir à l’exemple UTXO d’Alice et Bob, à l’étape 1, Alice doit fournir sa signature de clé privée dans sa contribution pour dépenser son UTXO.Bob a ensuite dû fournir les mêmes informations avant de dépenser son 0,5 BTC nouvellement reçu.

Le langage de script de Bitcoin peut inclure des conditions de dépenses plus complexes, telles que nécessiter plusieurs signatures ou déverrouiller Bitcoin à une hauteur de bloc spécifique.Cependant, les scripts Bitcoin ne sont pas universels et n’ont pas le pouvoir expressif de la solidité du langage de programmation natif d’Ethereum.Par conséquent, il est extrêmement difficile de programmer une logique de contrat intelligente pour les solutions de pontage et d’hébergement à l’aide de scripts Bitcoin.

3. Obstacles face aux scripts Bitcoin à partir de 2025

Bien que les scripts Bitcoin aient prouvé leur utilité aux utilisateurs et leur résilience aux attaques à double dépenses au cours des 16 dernières années, le langage de script manque de fonctionnalités communes telles que l’expressivité et la capacité de stocker l’état mondial.Les scripts Bitcoin ne sont pas expressifs car ils sont un langage de programmation basé sur la pile qui ne peut pas se multiplier et les opérations arithmétiques sur de grands nombres.Les scripts Bitcoin ne peuvent effectuer des calculs non triviaux que sur des valeurs de taille 32 bits.Par conséquent, le script Bitcoin isole des éléments de pile supérieurs à 32 bits les uns des autres.Cette restriction 32 bits isole des commandes à forte intensité de calcul utilisant des fonctions de chiffrement, une multiplication et une division qui nécessitent une taille de script plus grande que l’ensemble actuel d’Opcodes.Bien que l’arithmétique et la multiplication puissent être simulés à l’aide de plusieurs opcodes, cela nécessite de nombreux éléments de pile, tandis que la taille de la pile d’un script Bitcoin est limitée à 1000 éléments.Par conséquent, il est difficile de créer des conditions de dépenses complexes sur la sortie de transaction qui dépasse l’opération actuelle.

La plus grande limitation des scripts Bitcoin est que la langue ne peut pas lire / écrire et stocker les données de transaction car elle ne peut lire que les entrées fournies par le consommateur.Si le langage de programmation ne peut pas stocker l’état global, le script ne peut pas vérifier indépendamment le solde du compte sur l’application ou le pont.La logique de script Bitcoin ne peut pas accéder à l’état global car aucune donnée d’état doit convenir à une seule transaction.Par conséquent, il est presque impossible de développer des fonctions communes ou de créer des ponts sans confiance entre le réseau L2 et la couche de base de Bitcoin.

Des mesures pour surmonter les restrictions de script Bitcoin sont en cours depuis 2020.Au fil des ans, il semble que la seule façon d’améliorer l’expressivité des scripts Bitcoin est d’effectuer des mises à niveau de la fourche souple, de mettre en œuvre de nouveaux opcodes pour mettre en œuvre des alliances.Bien qu’une partie de la communauté Bitcoin pense que ces mises à niveau présentent un risque pour le réseau Bitcoin, une autre pense que Bitcoin a besoin de plus de fonctionnalités de programmabilité pour évoluer le cas d’utilisation du Bitcoin.Bien que des progrès substantiels n’aient pas été réalisés sur lesquels OPCode convient le mieux pour améliorer la programmabilité des transactions Bitcoin, les défenseurs des alliances conviennent désormais principalement que OP_CTV et OP_CAT sont les principales propositions d’amélioration du Bitcoin (BIP) qui améliorent la programmabilité des transactions Bitcoin.Nous avons appris qu’il existe plus de deux solutions pour mettre en œuvre des alliances sur Bitcoin, mais cet article décrit uniquement les deux propositions les plus importantes, OP_CTV et OP_CAT.

4. Bip 119 (OP_CTV)

La proposition d’amélioration de Bitcoin 119 (BIP 119), également connue sous le nom de vérification du modèle de contrôle (CTV), est une proposition proposée en janvier 2020 par le développeur de Bitcoin Core Jeremy Rubin.La proposition introduit un nouvel OPCode OP_CTV qui met en œuvre des conditions de dépenses générales, c’est-à-dire des alliances, sur la sortie des transactions Bitcoin.Donnons une introduction simple à fond ci-dessous.La pièce de modèle dans « Check_template_verify » fait référence au format de transaction qui doit être suivi lors de l’écriture de scripts Bitcoin.Check-Template-Verify est une nouvelle fonctionnalité qui permet à la sortie du script de verrouillage par la transaction de s’engager dans les conditions de dépenses stockées dans le script de verrouillage en tant que hachage, également connu sous le nom de hachage de promesse.Par conséquent, la sortie de la transaction ne peut être déverrouillée que si les conditions détaillées dans le hachage de promesse sont remplies.Une fois diffusé en chaîne, le hachage de promesse associé à la transaction est immuable.L’avantage de OP_CTV est que l’expéditeur de transaction peut imposer des conditions de dépense au récepteur, ce qui est une modification majeure des règles actuelles du script Bitcoin, et les règles actuelles ne peuvent construire que les conditions de dépense de l’expéditeur.

Il existe deux principaux types de contrats d’alliances.Un contrat général peut être copié et appliqué à plusieurs UTXO.Les alliances n’expireront pas une fois UTXO dépensé.D’un autre côté, les contrats précalculés peuvent également être copiés, mais ne peuvent être utilisés que dans un nombre prédéfini et prédéfini de fois.La logique du contrat pré-calculé doit être spécifiée à l’avance par l’expéditeur, et la différence par rapport au contrat général est que les conditions de dépense ne peuvent pas être copiées à l’infini.Les contrats généraux, également appelés contrats récursifs, peuvent présenter des risques à la substituabilité d’UTXO, c’est pourquoi les défenseurs du BIP 119 se concentrent généralement uniquement sur les cas d’utilisation OP_CTV qui utilisent des contrats pré-rémunérés, et pourquoi le BIP 119 ne soutient pas les contrats généraux.Par exemple, si un contrat général est activé, l’échange de gardien ou de bitcoin peut être en mesure de gérer les retraits avec des conditions de dépenses permanentes, ce qui peut ne jamais se débarrasser de la possibilité d’être examinée par le gouvernement ou une autre autorité.

5. Déployer des clauses restrictives en utilisant BIP 119

Prenant le plan du coffre

Alice espère dépenser 0,8 BTC de son 1 BTC UTXO à Bob et Charlie (0,4 BTC par personne) au cours des 10 prochaines années.Alice espère également envoyer son changement d’environ 0,2 BTC à un nouveau coffre-fort qui verrouille le BTC pendant encore 10 ans.

Étape 1:Alice a passé son 1 BTC Utxo à Bob et Charlie, et a détaillé dans le script de verrouillage que Bob et Charlie peuvent passer BTC après 525k blocs, qui est environ 10 ans plus tard.Alice comprend également des instructions détaillant sa sortie de changement d’environ 0,2 BTC sera envoyée à l’adresse du coffre-fort qu’elle possède, qui verra ses blocs UTXO 525K, c’est-à-dire environ 10 ans plus tard.

Étape 2:Bob et Charlie ont passé leur UTXO respectif d’une valeur de 0,4 BTC après 525k blocs.Le script de verrouillage entre Alice vérifiera le hachage de promesse en fonction de la hauteur du bloc actuel, et Bob et Charlie peuvent dépenser leur nouvel UTXO si les critères sont remplis.

À l’étape 2, après que Bob et Charlie ont passé leur UTXO, une partie du script Bitcoin, également connu sous le nom de « Script Lock », vérifiera l’accomplissement des conditions de dépenses, en veillant à ce que toutes les conditions soient remplies avant la sortie de BTC.Cette opération est souvent appelée « déverrouillage » la sortie Bitcoin avec la signature de script correcte.Si la condition n’est pas remplie, le script de verrouillage ne lancera pas le transfert de BTC.

Étape 3:Après que Charlie et Bob ont satisfait le hachage de promesse dans le script de verrouillage, l’UTXO est retourné à Alice car le changement (environ 0,2 BTC) est utilisé comme entrée pour avoir l’adresse de la clé publique de script Vault spécifié.La clé publique du script de coffre-fort comprend un hachage qui permet à Alice de déverrouiller le coffre-fort après 525k blocs de dépenser son UTXO d’une valeur d’environ 0,2 BTC.L’avantage de l’utilisation du schéma de coffre-fort est qu’Alice peut ajouter des mesures de sécurité détaillées dans le hachage, comme une adresse de récupération secrète, au cas où quelqu’un vole sa clé privée et essaie de déverrouiller l’UTXO avant le verrouillage du temps de bloc 525K.

Sans alliances, dans l’exemple précédent, Alice doit créer une transaction pré-signée pour appliquer de futures conditions de dépenses sur la BTC qu’elle a dépensée pour Bob et Charlie.Une transaction pré-signée peut être une transaction unique ou multiple, signée à l’avance par la clé privée de l’expéditeur, mais n’est pas réellement diffusée au réseau pour confirmation et exécution.Les transactions pré-signatées ne sont pas évolutives car elles obligent les utilisateurs à stocker des données pour plusieurs transactions jusqu’à ce qu’ils soient exécutés sur la chaîne.De plus, les transactions pré-signature nécessitent une interaction entre toutes les parties signataires lorsque les fonds peuvent être dépensés.Cependant, la mise en œuvre des clauses restrictives utilisant Promise Hash via OP_CTV réduit la nécessité pour les utilisateurs de stocker des données de transaction pré-signées et de s’appuyer sur l’interaction entre toutes les parties associées à la transaction.

D’une manière générale, cette fonctionnalité peut être utilisée pour créer un hébergement complexe, hautement sécurisé et résilient et une conception sécurisée qui aide à améliorer l’auto-hébergement ou l’hébergement, à créer de nouveaux quorums ou paramètres de compte commercial innovants, ou créer des solutions d’exécution plus autonomes avec une plus grande transparence et une plus grande fiabilité.

6. BIP 347 (OP_CAT)

Le BIP 347 est une autre proposition d’amélioration du bitcoin rédigé par Ethan Heilman et Armin Sabouri en octobre 2023, qui peut également mettre en œuvre des conditions de dépenses pré-calculées sur la sortie des transactions Bitcoin.La proposition suggère d’ajouter l’opcode OP_CAT au langage de script de Bitcoin, une fonctionnalité qui permet aux développeurs Bitcoin de « connecter » deux points de données ensemble dans la pile et de placer ces valeurs en haut de la pile.Jetons un coup d’œil à une brève introduction d’arrière-plan.La concaténation est le processus de combinaison de deux chaînes de code ou plus dans un octet ou une chaîne de données plus grand.Les scripts Bitcoin sont des langages de programmation basés sur des piles qui calculent chaque chaîne de code dans l’ordre.Pour une pile composée de 5 lignes de code, le script Bitcoin calculera d’abord la ligne 1 et finira par calculer la ligne 5.Malheureusement, le langage de script de Bitcoin ne contient pas d’opcodes qui permettent aux développeurs de fusionner plusieurs chaînes de code dans toute la pile.Actuellement, les scripts Bitcoin manquent de capacités arithmétiques et de multiplication, supprimant la capacité de compresser les scripts Bitcoin, ce qui limite l’interaction de grands scripts (supérieur à 32 bits) et de petits scripts (supérieurs à 32 bits) dans une seule pile.Les conditions de dépenses complexes pour la sortie de la transaction ne sont pas possibles sans la possibilité de compresser les scripts via « Connexion » et permettent aux grands scripts de communiquer avec de petits scripts.

Surtout, les éléments concaténés du script Bitcoin en haut de la pile peuvent simuler des fonctions arithmétiques et de multiplication, permettant des scripts complexes sans avoir besoin d’écrire des scripts à forte intensité de données plus longs qui sont plus sujets aux erreurs.De plus, la fonction de connectivité d’OP_CAT permet aux développeurs de générer des conditions de dépenses en utilisant l’arbre Merkle et d’autres structures de données de hachage dans TAPScript, un langage de script natif utilisé pour activer de nouveaux types de transactions dans le cadre de la mise à niveau de la rafale de tapoot activée en novembre 2021.

Il convient de noter que Satoshi Nakamoto désactive OP_CAT et d’autres opcodes qui permettent aux scripts Bitcoin d’effectuer des opérations mathématiques complexes directement dans le script.Satoshi Nakamoto lui-même a supprimé OP_CAT parce que l’OPCode était limité à 2000 octets lorsque le script Bitcoin était limité à OP_DUP, des scripts à forte intensité de données pouvaient être construits en combinaison avec OP_DUP.Les scripts de cette échelle peuvent augmenter le fardeau des ressources informatiques sur les nœuds Bitcoin et les surcharger.Cependant, la mise à niveau de la racine de tapoot a introduit une limite de taille (520 octets) pour les scripts de tapoot en 2021, de sorte que OP_CAT n’introduit plus les frais généraux de calcul excessifs pour les opérateurs de nœuds.

7. Déployer des clauses restrictives à l’aide de BIP 347 (OP_CAT)

La mise à niveau de la racine de 2021 introduit des signatures Schnorr dans le langage de script Bitcoin.La signature Schnorr prend en charge l’agrégation de clés publique et privée, permettant à plusieurs parties de signer une transaction ensemble via une seule signature.La combinaison de l’OPCode de vérification contenu dans la signature Schnorr avec OP_CAT peut créer un contrat non rérécise qui génère un hachage de transaction.Grâce à OP_CAT, les utilisateurs peuvent contraindre certaines parties d’une transaction, tels que l’envoi d’adresse ou l’envoi du montant, comme exigence pour le script de déverrouillage, et le hachage de transaction sert de clé de déverrouillage.

Prenant l’exemple du schéma du coffreLes détails techniques de cet exemple dépassent le cadre de cet article.

Alice veut créer un coffre-fort qui déverrouille son UTXO après 100 blocs:

* Étape 1:Alice passe son UTXO à une adresse de coffre-fort et contient des détails sur l’état de dépenses du script de déverrouillage du coffre-fort dans le champ des témoins, y compris la hauteur du bloc.

* Étape 2:Pendant la transaction d’Alice, OP_CAT relie les instructions de déverrouillage du coffre-fort dans le champ des témoins et les hachent deux fois pour obtenir le soughash / txhash.

* Étape 3:Une fois que 100 blocs ont été confirmés, Alice initie le processus de dépense de son bitcoin de coffre-fort en diffusant les transactions de dépenses d’UTXO.Pour vérifier qu’Alice remplit toutes les conditions de dépense, son portefeuille exécute l’opcode Checkssig en arrière-plan.Cette opération effectue deux validations clés: vérifiez que le hachage de transaction dans la transaction d’installation initiale (étape 1) et comparez-le avec la transaction de dépenses actuelle (étape 3).La fonction CheckSig reconstruit les composants qui mettent en place la transaction et vérifient la signature de la clé publique de la transaction actuelle pour garantir que toutes les conditions de dépenses de voûte sont remplies.

* Étape 4:Une fois que la clé publique de la transaction Alice a été vérifiée par Checksig (Checksig reconstruit les conditions de dépenses stockées dans le champ des témoins), Alice est libre de dépenser son UTXO.

L’exemple ci-dessus montre que OP_CAT lui-même ne peut pas implémenter des conditions de dépenses sur les transactions, mais que OP_CAT combinée à d’autres OPCodes dans les scripts Bitcoin peut simplifier les scripts et ainsi implémenter des alliances.La seule fonction d’OP_CAT est de connecter deux éléments en haut de la pile.

Bien que OP_CAT puisse être utilisé avec Checkssig pour créer des alliances, l’ajout d’OP_CAT seul n’apporte pas de fonctionnalité de type solidité aux scripts Bitcoin.Cette limitation s’applique également à l’ajout d’OP_CTV uniquement.Même avec OP_CAT, les transactions Bitcoin ne peuvent effectuer qu’une introspection minimale, ce qui signifie que les transactions ne peuvent pas accéder pleinement aux éléments ou aux états des transactions précédentes.Par conséquent, OP_CAT ne peut prendre en charge que les clauses d’alliances à grain fin de la sortie de la transaction de tapoot.OP_CAT ne peut pas fixer la sortie des nœuds de feuille par tapoot ou vérifier les touches internes utilisées.Un nœud de feuille de tapoot est une condition de dépense unique ou un script soumis à la sortie de la tapoot.Ils peuvent être considérés comme différents «chemins» ou des moyens de dépenser le bitcoin – chaque nœud de feuille représente un moyen possible de dépenser.La clé interne dans une transaction de tapoot Bitcoin est la principale clé publique utilisée pour le chemin de dépenses le plus efficace.Lorsque vous dépensez UTXO avec une clé interne, il vous suffit de fournir la signature sur la chaîne sans révéler de scripts ou de chemins de merkle.

Il convient de noter que ces limitations peuvent être résolues par d’autres propositions OPCODE telles que OP_TWEAK_VERIFY et OP_INTERNALKEY.Dans l’ensemble, OP_CAT peut être considéré comme le principal bloc de construction qui génère des conditions de dépenses complexes sur les sorties de transaction, cependant, d’autres blocs de construction, y compris Checksig, sont cruciaux pour faire progresser la programmabilité des transactions Bitcoin.

8. Caractéristiques clés que les alliances peuvent apporter au bitcoin

(1) pont sans confiance et sortie unilatérale

Starkware (créateur de StarkNet ZK-Rollup sur Ethereum) a publié un rapport mettant en évidence comment OP_CAT prend en charge la création de validateurs Stark et de validateurs Merkle pour le pontage Bitcoin sans confiance.Le pontage sans confiance est construit avec un système contractuel récursif qui maintient l’état de pontage en enregistrant une chaîne de transactions dans l’arbre Merkle.Le noyau de ce mécanisme est l’état de persistance du pont stocké dans la sortie OP_return non dépensée, qui contient le hachage racine de l’arbre Merkle représentant le solde du compte.OP_CAT Alliance exige que chaque nouvelle transaction de dépôt ou de retrait contient une transition d’état valide qui reflète l’état ponté actuel.Les utilisateurs interagissent avec les ponts grâce à des clauses dédiées à dépôt et à des clauses de retrait qui utilisent l’arbre Merkle pour agréger plusieurs transactions en lots pour une vérification efficace.Les racines de l’arbre Merkle sont ensuite fusionnées dans le contrat de pont principal, qui vérifie et traite chaque dépôt ou retrait.Pendant le retrait, l’acte vérifie la propriété en s’assurant que l’adresse de retrait correspond à l’adresse saisie dans la première entrée dans la transaction Leaf.La conception utilise la preuve Merkle pour des mises à jour d’état efficaces dans les scripts Bitcoin pour créer un système sans confiance où l’état et les règles du pont sont entièrement appliqués par la logique contractuelle sur chaîne créée par OP_CAT sans avoir besoin d’une confiance tierce.Surtout, pour le pontage bitcoin sans confiance des transitions d’état du système côté vérification, le script bitcoin a besoin d’une preuve de vérification.OP_CAT permet au script UTXO Lock pour vérifier les transitions de l’état du système ZK (Zero Knowledge Proof) en connectant les données de hachage ensemble.

L’équipe d’assistant de tapoot a innové un nouveau cadre de pontage sans confiance qui combine OP_CAT avec BitVM.Bitvm atteint les capacités d’expression complètes de Turing en permettant la segmentation et l’exécution de l’informatique arbitraire sur Bitcoin.Bitvm divise l’exécution des calculs arbitraires en plusieurs transactions sur Bitcoin en utilisant l’exécution de l’informatique arbitraire du script Bitcoin.Sans alliances, les ponts Bitvm qui verrouillent le bitcoin nécessitent des transactions pré-signées pour configurer le pont.La capacité d’OP_CAT à transporter des données des transactions précédentes permet à Bitvm Bridge de verrouiller et de débloquer Bitcoin sans transactions pré-signées.OP_CAT peut transporter des données des transactions précédentes via une technique appelée « Cat sur la pile ».Cette astuce consiste à concaténer les données hachées sur la pile pour construire une racine d’arbre Merkle, que OP_CAT peut vérifier.Par conséquent, le pont Catvm garantit que les données de transaction spécifiques des transactions, dépôts et retraits précédents doivent être inclus dans la prochaine transaction pour garantir que la racine de Merkle se poursuivait après un retrait réussi.Le chat sur les pointes de pile garantit également qu’après le retrait d’un utilisateur, les bitcoins pontés restants peuvent être retirés par n’importe quel utilisateur éligible.

(2) Advanced Vault Trust

Bitcoin Vault est une nouvelle solution de garde qui inclut des fonctionnalités de sécurité telles que des chemins de récupération qui permettent aux utilisateurs de retirer leurs Bitcoins à une adresse secrète en cas de fuites de clés privées.BIP 345, officiellement nommé OP_VAULT, est une proposition d’amélioration de Bitcoin en attente qui utilise OP_CTV pour améliorer les paramètres de sécurité de la garde de Bitcoin.Il convient de noter que OP_CAT peut également être utilisé pour créer un coffre-fort Bitcoin pour les conditions de dépenses sans transactions pré-signature.Le développeur de Core Bitcoin James O’Beirne a proposé OP_VAULT en janvier 2023 pour réduire la portée des cas d’utilisation d’OP_CTV.OP_VAULT s’appuie sur OP_CTV pour créer des conditions de dépenses pour Vault Bitcoin sans que le dépôt de signature de plusieurs transactions à l’avance.Les alliances permettent aux coffrets de voûte d’avoir des délais, et lorsque quelqu’un essaie de passer des bitcoins de coffre

(3) contrat de non-équivoque

Le contrat de non-équivoque a été introduit dans le réseau Bitcoin en 2015 et est la sortie des transactions Bitcoin.En pratique, les utilisateurs verrouillent le bitcoin natif comme un dépôt qui peut être confisqué.Cette marge permet à l’utilisateur d’exécuter 0 transactions de confirmation sur la couche de base, qui sont plus tard déterminées dans le bloc.0 Les transactions de confirmation sont des transactions Bitcoin instantanées vérifiées et protégées par les règles de consensus Bitcoin.Si l’expéditeur du 0 confirme que la transaction dépense les entrées avant l’extraction de la transaction, la contrepartie peut confisquer sa marge Bitcoin à partir de la clé de signature divulguée.

(4) Amélioration du réseau Lightning

OP_CAT peut activer Channel Factory, permettant aux utilisateurs d’ouvrir un canal Lightning sans d’abord d’ouverture des transactions sur la couche de base BTC.Par exemple, si Alice veut créer 2 canaux de foudre (l’un avec Bob et l’autre avec Charlie), Alice diffusera les transactions ouvertes de la chaîne avec Bob et Charlie (2 transactions).La transaction d’ouverture du canal nécessite que les deux parties déposent le bitcoin en 2/2 de l’adresse multi-signature.Grâce à l’usine de canaux, Bob et Charlie peuvent s’ouvrir des canaux séparés les uns aux autres sans diffuser de nouvelles chaînes pour ouvrir des transactions.Par conséquent, tous les participants à la transaction ouverte du canal d’origine peuvent créer des canaux indépendants les uns des autres.

OP_CTV peut créer UTXOS partagé, où un UTXO représente plusieurs utilisateurs.UTXO partagé à l’aide de CTV permet à plusieurs utilisateurs d’ouvrir plusieurs canaux de foudre via une transaction sur chaîne.En règle générale, chaque canal Lightning nécessite une transaction sur chaîne.Par conséquent, si de nombreux utilisateurs activent le canal Lightning, cela peut remplir le pool de mémoire avec les transactions en attente et augmenter les frais de transaction.Bien que ce ne soit pas un problème pour le moment, l’ouverture du canal doit être élargie pour prendre en charge le réseau Lightning pour attirer des millions d’utilisateurs actifs.

9. Risques liés à OP_CAT et OP_CTV

Toutes les fourches souples Bitcoin contiennent des risques techniques, tels que des erreurs dans de nouveaux opcodes ou des cas d’utilisation imprévus.Bien que le premier soit rare, le second est exposé dans la création d’inscriptions.L’inscription consiste à saisir des données arbitraires dans le domaine des témoins de la transaction, qui a été utilisée pour créer de nouveaux jetons et collections NFT sur Bitcoin.Les mises à niveau SegWit et Taproot permettent conjointement aux utilisateurs de saisir des données d’image et de texte en tant que données de chaîne dans le champ des témoins.Bien que l’art numérique et la création de jetons alternatifs ne soient pas au centre de l’activation de SegWit ou Taproot, des années plus tard, les développeurs intelligents ont découvert comment ces mises à niveau peuvent être utilisées à d’autres fins.Galaxy Research a mis en évidence ce point dans notre rapport ordinaire, notant que les inscriptions créées de façon inattendue via Segwit et Taproot pourraient avoir un impact négatif sur les futures mises à niveau de Bitcoin, car la surprise de la communauté dans ces nouveaux cas d’utilisation pourrait le rendre encore plus hésitant à soutenir de nouvelles fourches douces.

Malgré l’existence d’un sentiment baissier sur la capacité de Bitcoin à mettre à niveau, OP_CAT et OP_CTV ont été testés et étudiés de manière approfondie.La critique initiale des clauses restrictives était que le gouvernement pourrait forcer les demandes à appliquer des conditions de dépenses qui ne permettraient qu’un seul ensemble d’adresses approuvées pour dépenser le bitcoin.Cette critique n’est pas valide car les conditions de dépenses sont déterminées par les utilisateurs qui possèdent les fonds.Les utilisateurs peuvent créer des transactions qui limitent les dépenses futures à une adresse spécifique, mais ces restrictions ne peuvent pas être appliquées à l’extérieur par des tiers et ne peuvent pas être étendues en permanence après que les fonds verrouillés sont dépensés.Par conséquent, le gouvernement ne peut pas appliquer les applications de voûte auto-CUTOLIAL ou comment Bridge dépense de l’argent.Bien que les gardiens et les échanges de bitcoins puissent toujours limiter la façon dont les utilisateurs dépensent de l’argent, ils ne peuvent pas ajouter de conditions de dépenses permanentes pour retirer des fonds sans la possibilité d’exécuter le contrat général, et OP_CTV n’autorise pas les contrats généraux.

Dans l’ensemble, OP_CAT et OP_CTV sont des opcodes simples, chacun exécutant bien une fonction.OP_CAT rejoint deux éléments en haut de la pile, tandis que OP_CTV peut hacher les conditions de dépense dans le script de verrouillage.Certains cas d’utilisation de ces opcodes (tels que le développement du pontage sans confiance) nécessitent toujours des recherches supplémentaires et des tests pratiques, car les ponts sont extrêmement vulnérables aux bogues et aux attaques de piratage.

10. Le chemin de déploiement des clôtures de mise à niveau à fourche douce suivante

La détermination du consensus des parties prenantes de Bitcoin sur les futures mises à niveau du protocole est un processus complexe qui évolue avec le cycle de vie de la proposition – également connue sous le nom de processus BIP (proposition d’amélioration du Bitcoin).Le rapport BCAP sur l’histoire de la mise à niveau Bitcoin décrit les rôles de ces parties prenantes en détail comme suit:

* Node économique:Échanges, gardiens, marchands, fournisseurs de paiement

*investisseur:Baleine géante, microstrategy, fournisseur ETF, galaxie

* Célébrité des médias:Coindesk, magazine Bitcoin, x célébrités, podcasts

* Minder:Bitmain, microb, émeute, marathon, grands mineurs privés

* Développeur de protocole:Bitcoin Core Developer

* Développeur d’application:Projet L2

Tout au long du cycle de vie de la proposition d’amélioration du Bitcoin (BIP), les différentes parties prenantes exercent divers degrés d’influence et leurs changements d’influence relative lors de la mise en œuvre de la construction consensuelle des fourches mous.Voici les divisions détaillées de chaque niveau d’influence des parties prenantes, se classant par 1-10.En mars 2024, OP_CAT et OP_CTV sont à l’étape de conception du protocole.Les personnalités des médias sont à l’étape la plus influente car elles peuvent influencer l’opinion publique et créer des récits.Par exemple, Taproot Wizards est une équipe de célébrités de Bitcoin bien connues qui utilisent leur énorme base de fans de médias sociaux pour promouvoir les avantages de l’OP_CAT pour la communauté Bitcoin.L’équipe de Taproot Wizards a produit du contenu éducatif et des recherches sur OP_CAT pour conduire un récit où les scripts Bitcoin nécessitent de nouveaux opcodes pour améliorer la programmabilité des transactions.En conséquence, Taproot Wizards a développé un grand nombre de supporters pour OP_CAT, qui poussent les développeurs de base pour examiner le projet BIP OP_CAT.

Au cours de la phase de conception du protocole, les développeurs de noyau de Bitcoin se sont classés deuxième dans l’influence parce que les éditeurs du BIP étaient responsables de l’examen du projet du BIP en attente et, surtout, ils étaient les seules entités qui pourraient fusionner les BIP dans le référentiel Github Bitcoin Core.Sans le soutien des développeurs de noyau Bitcoin, BIP sera inévitablement suspendu et finalement rejeté.Les développeurs Bitcoin Core sont également chargés de maintenir la base de code Bitcoin et de s’assurer qu’il ne contient aucune erreur.Un consensus parmi les développeurs de noyaux Bitcoin est un processus difficile, car les perspectives idéologiques peuvent varier selon les développeurs de base, et l’influence de chaque développeur de base dans le processus décisionnel varie par contribution et contexte.

OP_CAT et OP_CTV BIP est au stade où les célébrités des médias, les utilisateurs et les développeurs d’applications utilisent leur influence pour convaincre les développeurs de noyau Bitcoin que ces changements de consensus amélioreront la programmabilité des transactions Bitcoin.La prochaine phase du parcours consensuel nécessitera des recherches spécifiques par les célébrités technologiques, les développeurs d’applications et les développeurs de base, détaillant tous les risques potentiels d’OP_CAT et OP_CTV.Sans recherche spécifique et dialogue ouvert avec les développeurs de base, il n’y aura pas de communauté de développeurs de base plus large qui a formé une vue collective de OP_CAT et OP_CTV.

Une fois qu’un consensus est atteint parmi les développeurs de base, OP_CAT et OP_CTV devront désigner un mainteneur principal pour faciliter la dernière étape d’implémentation du BIP vers le référentiel de noyau Bitcoin.Une fois que le BIP d’OP_CAT et OP_CTV a fusionné dans le référentiel de noyau Bitcoin, il est nécessaire de décider de la méthode d’activation.Une fois la méthode d’activation sélectionnée, la période de signal commence et les mineurs, les investisseurs et les nœuds économiques ont la plus grande influence.En mars 2024, les grands investisseurs tels que les mineurs, la microstrategy et les nœuds économiques tels que Coinbase n’ont pas encore exprimé des opinions publiques sur OP_CAT et OP_CTV.Avant la mise en œuvre du BIP, ces parties prenantes doivent mieux comprendre les risques et les avantages de OP_CAT et OP_CTV.

11. Méthode d’activation du BIP

Si les développeurs Bitcoin Core acceptent d’inclure OP_CAT ou OP_CTV dans la prochaine mise à niveau de la fourche souple, la communauté doit convenir de la façon d’activer le BIP.La méthode d’activation permet aux mineurs de signaler leur préparation à la mise à niveau.

D’une manière générale, il existe deux façons d’effectuer des changements de code sur Bitcoin.Tout d’abord, vous pouvezFourchetteEffectuer des modifications de code.Les fourches souples sont des mises à niveau compatibles en arrière qui permettent aux opérateurs de nœuds Bitcoin de s’exécuter en toute sécurité sur le réseau Bitcoin même sans mettre à niveau leur logiciel client.Un autre avantage de la compatibilité vers l’arrière des fourches souples est que quiconque n’est pas d’accord avec la direction du noyau Bitcoin (le principal client Bitcoin) peut choisir d’exécuter une ancienne version du logiciel client qui exclut les nouvelles activations BIP, mais peut toujours se connecter à la blockchain canonique Bitcoin.Les fourches souples ajoutent des fonctionnalités en créant de nouvelles conditions plus limitées que les ensembles de règles existants, donc s’adaptent aux règles existantes.

Lorsqu’une fourche souple est activée par un utilisateur (pas un mineur), elle est appelée fourche souple activée par l’utilisateur (UASF).L’exemple UASF le plus célèbre sur Bitcoin s’est produit presque pendant la « bataille de la taille du bloc » le 1er août 2017 pour aider à accélérer l’adoption de la mise à niveau de Segwit.Au cours de la bataille de la taille des blocs, les utilisateurs de Bitcoin ont mis à niveau leurs nœuds pour prendre en charge les mises à niveau SEGWIT et ont ensuite menacé de rejeter les blocs des nœuds non recommandés.Ce faisant, les mineurs qui n’ont pas mis à niveau leur logiciel client Bitcoin sont encouragés à adopter Segwit pour que leurs blocs se répandent plus largement et augmentent leurs chances de recevoir des récompenses de blocs.Bien que l’UASF n’ait jamais eu lieu pendant la guerre de taille de bloc, la menace de potentiel UASF a affecté l’adoption par les mineurs de segwit par les mineurs.

La deuxième façon d’implémenter les modifications de code est à traversFourchette, Il s’agit d’une mise à niveau incompatible en arrière qui divisera en permanence le consensus entre les nœuds améliorés et non dépassés.Les développeurs de noyau Bitcoin n’ont jamais implémenté une fourche dure car la communauté valorise la solidification et la compatibilité arrière du code de protocole.Si un petit nombre d’utilisateurs effectuent des mises à niveau de fourche dure (comme la modification de la taille du bloc), une fraction de chaîne peut se produire dans Bitcoin.C’est ainsi que Bitcoin Cash a été créé en 2017, lorsque une partie de la communauté Bitcoin n’était pas d’accord avec la mise à niveau de Segwit, dans l’espoir d’augmenter simplement la taille du bloc en activant les changements de code incompatibles en arrière à Fork hors du protocole Bitcoin.

En plus de la différence entre l’activation de la fourche dure et de la fourche douce, il existe différentes façons de mesurer le sentiment de la communauté concernant l’escalade avant que la fourche ne se produise.Voici un aperçu de divers types de processus BIPS proposés par la communauté Bitcoin pour mieux soutenir l’activation des mises à niveau de la fourche souple:

* Bip 9:Bip 9 fournit un cadre pour que les mineurs signalent leur prise en charge des mises à niveau de la fourche souple en modifiant la version Bitfield dans l’en-tête Bitcoin Block.Une fois la période de signal terminée, la communauté Bitcoin peut évaluer le pourcentage de mineurs soutenant les mises à niveau et voté par la puissance de calcul des mineurs.Si un certain seuil de support est dépassé, la mise à niveau peut continuer à être activée le « jour du drapeau », qui n’est qu’une hauteur de bloc spécifiée pour l’activation de mise à niveau.

* Bip 8:Le développeur à long terme de Bitcoin Core Luke Dashjr (qui travaille dans le développement de Bitcoin depuis 2011) a proposé Bip 8 comme successeur du BIP 9 en février 2017.Le BIP 8 recommande d’utiliser la hauteur du bloc plutôt que de calculer la puissance pour déterminer la durée de la période de signal pour une proposition d’approbation.BIP 8 introduit également un nouveau paramètre de fourche souple d’activation sur chaîne appelée « lot ».Si ce paramètre est défini sur « Vrai », un signal doit être émis au cours de la dernière période pour s’assurer que la fourche souple est verrouillée à la hauteur du délai d’attente.De là, les mises à niveau dans les jours de drapeau prédéfinis sont activés par les nœuds, que les signaux de mineur ou non.Le BIP 8 tente de réduire l’interférence des mineurs sur l’activation de la proposition souhaitée de la communauté et oblige les mineurs à considérer les conséquences de la perte de revenus en raison de ne pas recevoir de blocs des nœuds améliorés avec le paramètre de lot amélioré défini sur True.

* Essai rapide:Bitcoin Core Developers AJ Townes et Andrew Chow ont présenté une version de Bip 8 appelée The Speedy Trial en avril 2021.L’essai rapide tente d’accélérer le calendrier du mineur pour publier des signaux de préparation d’activation.Cette approche signifie que la proposition sera activée une fois que la majorité des blocs minières envoient un signal préparé dans une période spécifiée.Speedy Trial Caractéristiques similaires aux déploiements d’activation du BIP 9, mais avec une fenêtre d’activation plus courte.Récemment, la mise à niveau de la racine de tapoot a été activée sur Bitcoin via Speedy Trial.L’essai nécessite 90% des blocs minières pour envoyer un signal préparé dans les deux semaines avant que la tapoot ne puisse être activée sur le réseau.Le procès s’est terminé le 12 juin 2021.Après avoir atteint le seuil de support de mineur à 90%, le réseau entre ensuite une période d’attente de cinq mois pour laisser les mineurs et les nœuds de temps pour mettre à niveau leur logiciel.La tapoot a ensuite été officiellement activée sur Bitcoin le 15 novembre 2021.

* Activation moderne de la fourche douce:Il s’agit d’une méthode de mise à niveau de l’activation qui combine différents attributs de BIP 9 et BIP 8.Il a été proposé en janvier 2020 par Matt Corallo, l’un des contributeurs les plus prolifiques de Bitcoin Core.La méthode comprend trois étapes.La première étape est la fourche souple de l’activation du mineur décrite dans BIP 9.Si les mineurs ne parviennent pas à activer la mise à niveau, le processus d’activation moderne de la fourche souple décrit par Corallo sera par défaut à la deuxième étape, la période d’attente de six mois pour les développeurs et la communauté Bitcoin plus large pour reconsidérer les changements de code.Six mois plus tard, si les développeurs et les utilisateurs souhaitent continuer à mettre à niveau, ils peuvent démarrer l’étape 3, ce qui est essentiellement équivalent au BIP 8 avec le paramètre de lot défini sur true.

12. Conclusion

Bien que OP_CAT (BIP 347) et OP_CTV (BIP 119) aient reçu le support de nombreux développeurs Bitcoin bien connus, ces propositions nécessitent toujours un processus de diligence raisonnable long avant la mise en œuvre.En effet, OP_CAT et OP_CTV nécessitent des modifications de la couche consensus de Bitcoin, et le processus de gouvernance BIP pour de tels changements est très étendu.Bien que le calendrier d’activation des BIP 119 et du BIP 347 ne soit pas clair et imprévisible, la longue période d’examen peut bénéficier à la proposition car elle fournit à la communauté beaucoup de temps pour comprendre les avantages et les impacts de OP_CTV et OP_CAT.De plus, les contributeurs BIP auront plus de temps pour souligner le test OP_CTV et OP_CAT, ainsi que leur impact potentiel sur les futurs bogues dans les scripts Bitcoin.

Bien que le plein potentiel d’OP_CAT et d’OP_CTV soit toujours en cours d’expression, leur impact le plus direct est la mise en œuvre du pontage sans confiance et des voûtes bitcoin de sécurité avancées pour Bitcoin L2.L’importance du pontage sans confiance pour le Bitcoin L2 compatible EVM est évidente, en particulier dans le contexte de l’environnement croissant de Bitcoin Defi.Ces solutions sans confiance représentent des avancées importantes sur des alternatives actuelles telles que WBTC et CBBTC, qui repose sur des intermédiaires de confiance et affaiblir la nature sans autorisation de la technologie de la blockchain.Alors que les voûtes Bitcoin auto-CUSTODIAL peuvent offrir la valeur la plus pratique dans les solutions de garde, le potentiel des ponts L2 sans confiance démontre les possibilités plus larges que la programmabilité des transactions améliorée apporte à Bitcoin.

La communauté des développeurs a fait des progrès significatifs dans la promotion de ces propositions en 2024, et cette bonne dynamique pourrait se poursuivre en 2025.Étant donné que l’activité de trading Bitcoin a tendance à diminuer et aux frais de transaction aussi faibles que 1 SAT / VB, l’accent est mis sur la façon de restaurer l’activité de transaction sur le réseau Bitcoin.Bien que notre rapport de prévision Galaxy Research 2025 estime que les développeurs de noyau Bitcoin atteindront un consensus entre OP_CAT ou OP_CTV, le processus final de mise en œuvre et d’activation peut prendre 1 à 2 ans.Néanmoins, l’adoption finale de ces propositions sera une étape importante dans l’évolution des scripts Bitcoin, jetant les bases d’applications Bitcoin plus complexes et sécurisées à l’avenir.

En améliorant la programmabilité des transactions, Bitcoin sera en mesure de prendre en charge des cas d’utilisation plus innovants tels que le pontage transversal sans confiance et les solutions de garde avancées, ce qui stimule davantage l’écosystème Bitcoin.L’introduction de ces technologies améliorera non seulement la fonctionnalité du Bitcoin, mais fournira également aux développeurs et aux utilisateurs avec plus d’outils pour créer des applications décentralisées plus sûres et plus efficaces.Bien que la réalisation de ces objectifs nécessite du temps et des efforts communautaires, son impact potentiel injectera sans aucun doute une nouvelle vitalité dans l’avenir du Bitcoin.