L’article « Résurrection » a été supprimé par le Satoshi Nakamoto Operation Code ?, lire OP_CATSoft Fork

Article original par Jaleel, BlockBeats

Dans la base de code Bitcoin, un code d’opération « OP _CAT » qui a été supprimé par Satoshi Nakamoto et qui a été scellé par l’histoire pendant longtemps peut être « ressuscité ».

Autour du code d’opération OP_CAT, le projet de jetons non fongibles Bitcoin Taproot Wizards a lancé une nouvelle série de jetons non fongibles Quantum Cats. Bien que le terme OP_CAT ne fasse pas référence au « chat » familier, Taproot Wizard a utilisé l’image d’un chat pour lancer un nouveau jeton non fongible appelé Quantum Cats, en utilisant la culture des mèmes pour aider OP_CAT à créer un élan. À lire aussi : « Bitcoin « Quantum Cat » : sans contrat intelligent, comment réaliser un changement dynamique des inscriptions ? »

OP_CAT, le code d’opération qui a été supprimé par Satoshi Nakamoto du langage de script Bitcoin, a maintenant été ramené à la table des discussions, et certains développeurs de Bitcoin veulent « ressusciter » ce code d’opération et ouvrir la voie à Bitcoin pour implémenter Smart Contract via un soft fork de 13 lignes de code. Sous l’impulsion des développeurs de Bitcoin et créé un élan à l’image d’un mème de chat, la chaleur et la discussion sur OP_CAT ont atteint de nouveaux sommets.

Le code d’opération de « Resurrection » supprimé par Satoshi Nakamoto

Les codes d’opération, également connus sous le nom d’instructions ou de fonctions, sont les éléments de base du langage de script Bitcoin. Historiquement, certains codes d’opération ont été supprimés des versions antérieures de Bitcoin en raison de préoccupations concernant d’éventuelles vulnérabilités dans les implémentations du client, OP_CAT code d’opération étant l’une d’entre elles.

OP_CAT faisait à l’origine partie de l’ensemble de commandes officiel de Bitcoin, permettant la jonction de chaînes, l’épissage de deux éléments en un seul. Cependant, étant donné qu’une vulnérabilité critique trouvée dans le code d’opération telle que OP_LSHIFT pourrait provoquer le plantage de n’importe quel BitcoinNode, on craint que OP_ CAT code d’opération n’entraîne une croissance exponentielle des éléments de la pile, ce qui peut entraîner une augmentation exponentielle de l’utilisation de la mémoire et de la taille du script.

Par conséquent, par excès de prudence, Satoshi Nakamoto a supprimé le OP_CAT le 15 août 2010. Ces codes d’opération supprimés sont souvent appelés « désactivés », mais ce n’est pas exact, car ils sont complètement supprimés du protocole, ce qui rend le code d’opération indisponible pour toute personne utilisant le Bitcoin.

En octobre 2023, Ethan Heilman, développeur de Bitcoin Core, et Armin Sabouri, ingénieur logiciel principal de Botanix Labs, ont publié conjointement un projet de proposition d’amélioration de Bitcoin (BIP) intitulé « OP_CAT » qui a porté cette discussion à un nouveau niveau.

Ce brouillon, composé de seulement 13 lignes de code, a une nature fonctionnelle claire et intuitive, définissant un nouveau code d’opération tap qui permet de concaténer deux valeurs sur la pile. Cette implémentation de code a clairement été inspirée par le OP_CAT original supprimé.

Les conditions de la « résurrection » sont réunies

Quant à savoir pourquoi un code d’opération qui a été supprimé par Satoshi Nakamoto est maintenant restauré par les développeurs, la section de motivation de ce brouillon BIP l’explique en détail : cela est principalement basé sur des considérations d’utilisation de la mémoire, et OP_CAT fait augmenter l’utilisation de la mémoire des constructions de script de manière exponentielle par rapport à la taille du script lui-même. Plus précisément, un script simple qui pousse simplement une valeur de 1 octet dans la pile, puis la réplique avec OP_DUP code d’opération et la concatène 40 fois avec OP_CAT code d’opération peut entraîner le gonflement de la valeur de la pile à une taille massive de plus de 1 To.

Néanmoins, avec l’avancée du temps et le développement de la technologie, cette question n’est plus un obstacle. Dans l’architecture de TAP, il existe une règle claire selon laquelle la taille maximale des éléments de pile est strictement limitée à 520 octets. Ce changement résout efficacement les problèmes d’utilisation de la mémoire qui peuvent être causés par OP_CAT, offrant la possibilité de sa « résurrection » et de son intégration.

Il s’ensuit que OP_CAT est une fois de plus mis en discussion et envisagé pour être réutilisé, principalement en raison de sa valeur potentielle dans la construction de scripts plus complexes et plus puissants. En outre, un certain nombre de raisons et de changements ont rempli les conditions de la « résurrection », notamment :

1. Demande de contrats et de protocoles intelligents avancés : Au fur et à mesure que l’écosystème Bitcoin s’est développé, la demande de contrats et de protocoles intelligents plus avancés et plus complexes a augmenté. OP_CAT augmente l’expressivité et la fonctionnalité des robinets en permettant de combiner des objets sur la pile. Par exemple, il peut être utilisé pour créer et évaluer l’arbre de Merkle et d’autres structures de données de hachage, prenant en charge les signatures d’arbre, les signatures Lamport post-quantiques, les contrats de non-répudiation, les coffres-forts, etc.

2. Autres réussites on-chain : Certains forks de Bitcoin, tels que Bitcoin Cash et Sidechain Liquid, ont réactivé OP_CAT et l’ont utilisé pour mettre en œuvre la création et la gestion de jetons, les canaux de paiement et les moyens d’intégrer et de récupérer des données sur la blockchain. Cela indique que le OP_CAT peut être utilisé de manière sûre et efficace dans l’environnement et les restrictions appropriés.

3. Exploration de la sécurité quantique : Certaines études ont proposé que si des opérations telles que OP_CAT peuvent être utilisées, combinées à des technologies telles que les signatures Lamport, des transactions et des protocoles Bitcoin sécurisés quantiquement peuvent être construits. Cette exploration a une valeur potentielle pour améliorer la sécurité future du système Bitcoin.

4. Développement de la communauté et de la technologie : Le développement continu de la communauté et de la technologie Bitcoin a incité les gens à reconsidérer et à évaluer les décisions précédentes. Au fur et à mesure qu’une meilleure compréhension du protocole Bitcoin et des nouvelles technologies émergent, des fonctionnalités qui étaient auparavant considérées comme problématiques ou inapplicables peuvent trouver des cas d’utilisation sûrs et utiles dans de nouveaux contextes.

Soft fork, facile à parler

Sur le plan technique, peu d’autres propositions Bitcoin sont aussi faciles à interpréter et à comprendre que OP_CAT. Mais OP_CAT code d’opération sera activé en redéfinissant le Soft Fork du code d’opération OP_SUCCESS 126, ce qui n’est évidemment pas une tâche facile.

Rappelons que le dernier Soft Fork de Bitcoin a eu lieu il y a trois ans lorsque Taproot a été activé, contribuant ainsi à ouvrir la voie à la naissance des Ordinaux.

Le consensus et la transparence sont très appréciés par la communauté Bitcoin, et tout changement de code significatif est largement discuté et examiné au sein de la communauté, y compris les soft forks. Pour qu’un morceau de code soit fusionné dans la base de code de Bitcoin, il doit passer par un processus rigoureux et détaillé qui garantit la qualité de la proposition et le consensus de la communauté. Voici les principales étapes de ce processus :

1. Rédigez la proposition et le code : Tout d’abord, le développeur doit rédiger un document de proposition détaillé. Ce document doit décrire clairement la motivation, les détails techniques, l’évaluation d’impact et tout problème ou défi potentiel de la proposition.

2. Discussion de la communauté : Une fois qu’une proposition de code est soumise à la communauté Bitcoin, elle est discutée et examinée par les membres de la communauté (y compris les développeurs, les mineurs, les investisseurs et les utilisateurs). Cette étape est essentielle pour s’assurer de la faisabilité de la proposition et recueillir des commentaires.

3. Modifications et améliorations : Sur la base des commentaires de la communauté, les auteurs du code peuvent avoir besoin d’apporter des modifications et des améliorations à la proposition.

4. Votez, parvenez à un consensus : Certaines améliorations importantes (en particulier celles concernant le protocole Bitcoin lui-même) nécessitent un certain niveau de consensus entre les membres de la communauté. Cela implique généralement le soutien de Miner, qui doit montrer son soutien à la proposition en incluant un signal spécifique dans le bloc qu’il mine.

5. Mise en œuvre du code : Une fois qu’un consensus est atteint, le code sera examiné par l’équipe de développeurs de Bitcoin Core. Cette étape nécessite de s’assurer de la qualité et de la sécurité du code.

6. Fusionner dans la base de code : Après approbation, le code sera fusionné dans la base de code officielle de Bitcoin.

7. Déploiement et activation : Enfin, le nouveau code doit être déployé dans leurs systèmes par les mineurs et les opérateurs de nœuds. Pour les modifications au niveau du protocole, il existe généralement un seuil d’activation qui ne prend effet que lorsqu’un nombre suffisant de participants au réseau effectuent une mise à niveau vers la nouvelle version.

De toute évidence, la mise en œuvre du OP_ CAT Soft Fork n’en est encore qu’à ses débuts, moins de quatre mois après la rédaction du projet de BIP, le numéro de BIP n’a pas encore été déterminé, et il en est encore à la première phase d’écriture de la proposition et du code et à la deuxième phase des discussions communautaires impliquant les développeurs et les utilisateurs.

Ce que disent les développeurs de Bitcoin

Accordons une attention particulière à la discussion sur OP_CAT parmi les développeurs de Bitcoin ces dernières années.

Bien que le code d’opération OP_CAT ait été supprimé, l’utilité potentielle de OP_CAT pour faciliter les contrats avancés et améliorer les langages de script Bitcoin a été discutée à plusieurs reprises parmi les développeurs. Par exemple, sa capacité à connecter des valeurs de pile est considérée comme un obstacle au développement de certains protocoles Bitcoin, tels que TumbleBit, dont la taille des transactions peut être considérablement réduite si OP_CAT est pris en charge.

Maintenant que nous avons rassemblé la newsletter Optech et une variété de contenus connexes, trions certaines des discussions des développeurs Bitcoin sur le code d’opération OP_CAT dans l’ordre chronologique.

2019

Ethan Heilman, l’un des parrains du projet de proposition d’amélioration de Bitcoin (BIP) OP_CAT, a déclaré dans un e-mail en octobre 2019 qu’il comprenait pourquoi il avait été supprimé en raison de la situation désastreuse à laquelle étaient confrontés les scripts à l’époque, mais il a souligné la valeur de OP_CAT en tant que code d’opération : « La plupart des protocoles qui veulent s’appuyer sur Bitcoin aujourd’hui ont une limite : les valeurs de pile ne peuvent pas être connectées. En tant que chercheur, si j’éprouve cette limitation, il est probable qu’elle entrave également les progrès des autres. Si je pouvais agiter ma baguette pour réactiver l’un des codes d’opération désactivés, je choisirais OP_CAT. Bien entendu, cela s’accompagnera d’une condition : la taille de chaque valeur concaténée doit être limitée à 64 octets ou moins. 」

Lorsqu’il s’agit de discuter de OP_CAT, Andrew Poelstra est une personne qui ne peut jamais se déplacer. Il a écrit un article intitulé « CAT and Schnorr Tricks I » le 30 janvier 2021, qui a provoqué une vague de discussions sur OP_CAT. Andrew Poelstra est le directeur de la recherche chez Blockstream et un développeur de scripts BitcoinCryptography chevronné avec une forte présence dans l’industrie.

Dans l’article, Andrew Poelstra explique : « OP_CAT permet de combiner deux éléments de la pile et de repousser le résultat fusionné dans la pile. Cette fonction peut être utilisée pour assembler plusieurs petits éléments en un seul grand élément, ou pour décomposer un grand élément en plusieurs éléments plus petits. CHECKSIGFROMSTACK (CSFS) est un code d’opération inédit dans Bitcoin qui permet aux utilisateurs d’effectuer une vérification de signature sur des données arbitraires, contrairement au code d’opération CHECKSIG, qui ne vérifie que les signatures de transaction. 」

De plus, il souligne que l’utilisation de OP_CAT en conjonction avec CHECKSIGFROMSTACK peut fournir une approche ingénieuse de l’introspection transactionnelle.

Remarque : L’introspection de transaction fait référence à la capacité d’examiner et d’analyser les différents composants d’une transaction elle-même dans Bitcoin Script. En termes simples, cela permet au script de « comprendre » et de traiter les détails de la transaction qu’il traite, tels que la vérification de la sortie de la transaction, du montant ou de la signature spécifique. De cette façon, les scripts sont capables de répondre de manière plus intelligente et nuancée au contenu spécifique de la transaction.

CELA PERMET À L’UTILISATEUR DE FOURNIR LES DONNÉES DE L’ENSEMBLE DE LA TRANSACTION SUR LA PILE, ET LE SCRIPT UTILISE OP_CAT POUR EMPAQUETER LES DONNÉES DANS UN SINGLE ITEM, LE HACHER, PUIS LE TRANSMETTRE À CHECKSIGFROMSTACK POUR VÉRIFIER LA SIGNATURE SUR LES DONNÉES. Il transmet ensuite la même signature et la même clé secrète à CHECKSIG. Si les deux vérifications réussissent, cela indique que les données de transaction fournies par l’utilisateur sont bien des données de transaction réelles. De cette façon, le script peut directement utiliser ces données pour effectuer les vérifications requises par le contrat.

L’influence d’Andrew Poelstra et l’idée de l’article ont attiré l’attention des développeurs de Bitcoin, et lors de la conférence de cette semaine, il y a eu beaucoup de discussions sur cette combinaison de codes d’opération et sur la façon dont apporter de petites modifications au langage de script après l’activation de la racine pivotante pourrait améliorer la flexibilité du contrat.

Environ deux semaines après la sortie de CAT et Schnorr Tricks I, Andrew Poelstra a publié un deuxième article, CAT and Schnorr Tricks II, dans lequel Andrew Poelstra raconte plus de détails et ses réflexions :

En mai 2019, le développeur de Bitcoin, Jeremy Rubin, a proposé le code d’opération CHECKOUTPUTSHASHVERIFY de Bitcoin, dans le but de mettre en œuvre un contrat intelligent de base et limité qui évite les risques techniques et sociaux des conceptions de contrats intelligents précédentes. Ce code d’opération a ensuite été remplacé par SECURETHEBAG et plus tard par CHECKTEMPLATEVERIFY, qui est officiellement devenu Bitcoin Improvement Proposal BIP 0119 en janvier 2020.

En attendant, Russell O’Connor suggère d’ajouter CHECKSIGFROMSTACK et OP_CAT code d’opération directement au Bitcoin pour prendre en charge les contrats intelligents qui ne sont pas contraints par la proposition de Rubin. Bien que la proposition ait rencontré une certaine opposition et que les discussions aient fini par diminuer, principalement en raison de l’inefficacité des contrats intelligents de type CAT+CHECKSIG et de l’impression négative à long terme des avoirs complets de contrats intelligents universels.

Andrew Poelstra était également réticent à soutenir la fonctionnalité dite BitcoinSmart Contract au début. Cependant, à l’automne 2019, un échange privé avec Ethan Heilman l’a fait changer d’avis. Ethan Heilman a souligné que malgré les préoccupations, il est en fait possible de mettre en œuvre des contrats intelligents qui sont considérés comme nuisibles via CHECKMULTISIG et qui ne sont pas réellement acceptés par les portefeuilles et les utilisateurs en raison de leur manque de reconnaissance et de disponibilité. Pour le prouver, Ethan Heilman a mis les gens au défi sur les médias sociaux de trouver des contrats intelligents « sombres » viables, mais jusqu’à présent, personne n’a réussi.

Andrew Poelstra s’est donc mis à penser que la peur de tout le monde à l’égard des contrats intelligents était peut-être exagérée. L’article soutient également que le contrat intelligent est inévitable dans le développement de Bitcoin, même s’il y a des préoccupations, et encourage l’exploration continue de la possibilité de créer un contrat intelligent en utilisant le code d’opération non dédié OP_CAT.

En 2021

Cela a été suivi d’un article de Jeremy Rubin le 6 juillet 2021, expliquant le OP_CAT du point de vue de la sécurité quantique de Bitcoin. Jeremy Rubin n’est pas seulement un développeur Bitcoin, mais aussi le fondateur de Judica, une organisation de R&D Bitcoin axée sur le développement du langage de programmation Smart Contract de Bitcoin, Sapio.

Dans des e-mails et des articles de blog, Jeremy Rubin explique comment vérifier quantiquement Bitcoin avec OP_CAT code d’opération et signatures Lamport. L’auteur commence par passer en revue un article de blog précédent sur la façon d’enregistrer des valeurs de 5 octets à l’aide de l’arithmétique des scripts Bitcoin et des signatures Lamport. Bien que cette méthode soit soignée, elle a ses limites. Jeremy Rubin a eu une idée : et si nous pouvions signer des messages plus longs, surtout si nous pouvions signer jusqu’à 20 octets, nous pourrions signer un condensé HASH 160 potentiellement quantique.

Jeremy Rubin explore plus en détail les implications de la signature d’un condensé HASH 160 dans l’article et explique la possibilité de ne révéler que la clé privée sans altérer le contenu signé réel, même si Quantum Computer craque ECDSA. Pour ce faire, les auteurs ont consulté le scientifique en cryptographie Madars Virza et ont reçu une réponse affirmative.

Jeremy Rubin souligne que si nous exigeons que les signatures ECDSA soient signées à l’aide d’un algorithme de signature de preuve quantique, nous pouvons avoir une preuve quantique de Bitcoin. Le schéma de signature à 5 octets discuté précédemment est en fait une signature Lamport à sécurité quantique. Malheureusement, cette méthode nécessite au moins 20 octets consécutifs.

Par conséquent, Jeremy Rubin a proposé qu’une sorte d’opération de type OP_CAT était nécessaire. L’article explique que OP_CAT ne peut pas être un soft fork directement vers Segwit v 0 car il modifie la pile. Ainsi, pour simplifier, l’auteur montre comment utiliser un nouveau code d’opération OP_SUBSTRINGEQUALVERIFY ce code d’opération vérifie si une partie d’une chaîne est égale en validant la sémantique.

Le 5 novembre 2021, lors de la conférence Bitcoin d’Atlanta, Jeremy Rubin et Andrew Poelstra figuraient parmi les intervenants qui ont discuté de la proposition de réactiver le code d’opération OP_CAT, arguant que OP_CAT est important dans le contexte de Bitcoin et soulignant son potentiel, notamment en termes de sécurité quantique et de fabrication de contrats intelligents complexes. Par exemple, en combinaison avec le code d’opération de vérification de signature CAT et Schnorr, un contrat intelligent non récursif peut théoriquement être mis en œuvre. Ce contrat intelligent est capable de placer le hachage SHA 2 des données de transaction directement dans la pile. Ce faisant, des restrictions peuvent être imposées à diverses parties de la transaction dans une certaine mesure.

La discussion a également mentionné que si CAT est réintroduit, cela pourrait compliquer Bitcoin à certains égards, tout en introduisant de nouvelles fonctionnalités et possibilités. Le redémarrage du OP_CAT nécessite une attention particulière pour éviter les problèmes qui se sont produits dans le passé, tels que les explosions de mémoire.

2022

Lors d’une discussion sur la liste de diffusion des développeurs Bitcoin du 18 mai 2022 au sujet de la réintroduction du code d’opération OP_CAT qui a été supprimé du Bitcoin en 2010, le développeur ZmnSCPxj a suggéré que pour réaliser l’inévitable contrat intelligent récursif, OP_CAT devrait être combiné avec le code d’opération proposé tel que OP_TX, OP_CHECKSIGFROMSTACK (CSFS), etc. Les contrats intelligents récursifs utilisent les règles de BitcoinConsensus pour s’assurer que tous les bitcoins reçus d’un contrat ne peuvent être dépensés que pour le même contrat.

Les contrats intelligents récursifs s’appuient sur des techniques d’introspection de transaction, c’est-à-dire qu’un code d’opération peut analyser une partie de la transaction sur laquelle le code d’opération est exécuté. Le code d’opération actuel offre une introspection limitée. Afin de créer un contrat intelligent récursif, vous devez vous assurer que la sortie précédente et la sortie suivante sont identiques. Par conséquent, soit la sortie précédente, soit la sortie suivante, soit les deux doivent être construites dynamiquement à partir de leurs éléments constitutifs, c’est pourquoi CAT ou des structures similaires sont nécessaires pour implémenter des contrats intelligents récursifs.

Nadav Ivgi souligne qu’CAT est toujours nécessaire pour résoudre le problème de hachage lors de la création de contrats intelligents récursifs, mais cela signifie que des fonctionnalités telles que CTV et APO, qui se concentrent sur l’introspection de sortie, peuvent également être combinées avec CAT pour créer des contrats intelligents récursifs. Ivgi soutient que, lorsqu’il est utilisé en conjonction avec la fonctionnalité de taproot, la validation de la sortie précédente avec la sortie suivante facilite l’écriture de scripts de contrats intelligents, et fournit des liens vers deux exemples de contrats intelligents récursifs.

ZmnSCPxj était d’accord avec l’analyse d’Ivgi et a réitéré ses inquiétudes quant aux risques liés à l’activation de contrats intelligents récursifs sur Bitcoin, bien qu’il ait également noté dans un article de suivi que les contrats intelligents récursifs peuvent être sûrs car ils ne sont pas réellement Turing Complete. Russell O’Connor cite l’article d’Andrew Poelstra décrivant comment CAT lui-même peut être suffisamment combiné avec les fonctionnalités existantes de Bitcoin pour créer des contrats intelligents non récursifs, et théoriquement, s’il est rajouté à Bitcoin, peut également être capable de créer des contrats intelligents récursifs par lui-même.

En 2023

En janvier, Anthony Towns a lancé Bitcoin Inquisition, une réplique de Bitcoin Core conçue pour fonctionner sur le signe par défaut afin de tester les soft forks proposés et d’autres changements majeurs du protocole. À la fin de l’année 2023, Bitcoin Inquisition a pris en charge un certain nombre de propositions, et en outre, des PR (pull requests) conçues pour OP_CAT, OP_VAULT et limiter les transactions de 64 octets ont été soumises à sa base de code, ce qui devrait encore étendre les capacités de ce banc d’essai.

Le 23 août 2023, sur la liste de diffusion Lightning-Dev, Thomas Voegtlin a eu l’idée d’une preuve de fraude sur l’état des sauvegardes expirées. Voegtlin souligne qu’il est possible d’utiliser cette preuve de fraude on-chain si OP_CHECKSIGFROMSTACK (CSFS) et OP_ CAT code d’opération sont ajoutés au Bitcoin de manière Soft Fork. La proposition a suscité de nombreuses discussions, Peter Todd soulignant que le mécanisme de base est générique et ne se limite pas à LN et peut être utile dans divers protocoles, mais il a également proposé un mécanisme plus simple qui ne sera pas discuté ici.

En octobre, Rusty Russell travaillait sur un contrat intelligent à usage général pour le langage de script Bitcoin avec des changements minimes. Dans le même temps, Ethan Heilman et Armin Sabouri ont publié conjointement un projet de BIP proposant l’ajout de OP_CAT Operation Code, un code d’opération pour connecter deux éléments sur la pile. Les discussions sur ces deux sujets se sont poursuivies jusqu’en novembre.

En 2024

Nous sommes en janvier 2024, et Quantum Cats a en effet réussi à faire passer la discussion sur le BIP et le processus Bitcoin pour OP_CAT au niveau supérieur.

Lors d’une interaction avec la communauté, Ava Chow, développeuse de Bitcoin Core, a déclaré : « Je ne pense pas que CTV soit un consensus approximatif. Je pense que d’autres propositions plus générales de contrats intelligents sont en fait plus proches, telles que txhash ou CAT. Cependant, je n’ai pas suivi la discussion de près. 」

Classée par nombre de commits, Ava Chow (@achow 101) est actuellement classée 5e dans le classement des contributeurs de code Bitcoin Core avec 1 292 commits de code et est l’une des rares à avoir le droit de fusionner le code Bitcoin. En conséquence, elle est également très influente dans la communauté du développement.

« Je ne suggère pas que nous activions OP_CAT. Je soutiens OP_CAT parce que c’est le code d’opération qui a le plus de chances de faire consensus. Si vous ne connaissez pas OP_CAT, je résume la situation dans cette image. C’est ce qu’affirme Eric Wall (@ercwl), co-créateur de Taproot Wizard.

Cependant, Ava Chow ne semble pas être absolument en faveur de la mise en œuvre de OP_CAT : « Comme je l’ai déjà dit, je ne pense pas qu’une proposition de contrat intelligent se rapproche ou ait un consensus approximatif. Je ne pense pas que nous devrions essayer d’activer l’un d’entre eux. 」

Dix lignes de code pour permettre à Bitcoin de mettre en œuvre un contrat intelligent

Comme l’explique Eric Wall (@ercwl), co-créateur de Taproot Wizard, « Les gens ne s’en rendent pas compte, mais OP_CAT est en fait l’un des éléments constitutifs de zkrollup sur Bitcoin. 」

La réintroduction de OP_CAT fournit à Bitcoin un outil puissant pour soutenir des projets tels que BitVM, un concept récemment introduit de validation de calcul arbitraire sur Bitcoin qui sera rendu plus facile et plus efficace grâce à OP_CAT. L’écosystème Bitcoin permet la création de contrats intelligents plus polyvalents et plus expressifs.

Lecture connexe : Que pensent les développeurs vétérans de BitVM pour calculer quoi que ce soit sur Bitcoin ?

Avec OP_CAT, il est possible de mettre en œuvre ce que l’on appelle des contrats intelligents, c’est-à-dire que des conditions prédéfinies sont définies pour une sortie Bitcoin spécifique. Cela ouvre non seulement la porte à de nouvelles méthodes de mise à l’échelle, telles que l’Arche de Blockstream, mais prend également en charge de nombreuses autres approches innovantes qui s’appuient sur les contrats intelligents. De plus, cela signifie que Bitcoin n’est pas seulement un réseau de paiement, mais aussi une plateforme informatique polyvalente et évolutive.

Bien que le co-créateur de Taproot Wizard, Eric Wall, soit enthousiasmé par le concept de BitVM, il pense que la proposition pourrait être une « impasse technique » pour Bitcoin en raison de ses énormes frais généraux et de son long cycle de mise en œuvre. Il craint que BitVM ne détourne l’attention de la communauté et n’entrave le développement réel. Malgré cela, la proposition de BitVM montre toujours l’esprit actif d’exploration et d’innovation dans le domaine de la technologie Blockchain et des contrats intelligents.

En fait, l’équipe du projet Taproot Wizard elle-même travaille à la mise en œuvre d’une solution de couche 2 sur Bitcoin, et dans un espace précédent, ils ont également déclaré que le cycle de financement de 7,5 millions de dollars achevé sera utilisé pour étudier les options de mise à l’échelle de Bitcoin.

Par conséquent, le soft fork de OP_CAT sera également une étape importante pour eux. Eric Wall, qui était membre du conseil d’administration de la Fondation StarkNet, s’intéresse beaucoup à la construction de la DeFi en plus de la création d’une couche de règlement sans autorisation, donc lorsque Ethereum a commencé à émerger en 2019, il a été naturellement attiré par l’espace de la finance décentralisée sur Ethereum.

L’exploration de la finance décentralisée par Bitcoin a été presque complètement abandonnée lorsqu’il est devenu évident en 2019 qu’Ethereum et d’autres blockchains pouvaient évoluer en utilisant des zk-rollups ou des preuves de fraude optimistes. Avec des recherches sur la faisabilité de la mise à l’échelle zk-rollup appliquée à Bitcoin, Wall s’est tourné vers la finance décentralisée sur Ethereum. Mais finalement, il essaie d’apporter ce système et ces avantages technologiques à Bitcoin.

De plus, dans un fil de discussion sur OP_CAT dans le forum bitcointalk, Carter Feldman (@cmpeq), fondateur du projet QED, a été interrogé sur la façon dont il comptait tirer parti de ce code d’opération dans les scripts Bitcoin, et s’il calculait les octets moyens de la pile témoin et les frais qui pourraient être encourus.

Carter Feldman a déclaré qu’il reconnaissait que cela pouvait être un peu coûteux, mais explique que la preuve de Merkel est principalement utilisée dans son projet pour construire un script de verrouillage sans confiance ou un système de cheville dans le cadre de la couche deux zk sur Bitcoin. Ce système vise à prouver qu’une certaine quantité de Bitcoin peut être retirée à une adresse spécifique compte tenu de la racine de l’arbre de retrait (en tant qu’entrée publique à une preuve à divulgation nulle de connaissance).

Pour faire face aux coûts, il a mentionné qu’il s’agirait d’un dernier recours. Il envisage que les utilisateurs réguliers puissent acheter des BTC enveloppés sur la deuxième couche en demandant au vendeur de BTC enveloppés de verrouiller leur jeton sur L2 pendant un certain temps, période pendant laquelle l’acheteur doit prouver qu’il a payé le vendeur sur Bitcoin L1. Ils savent qu’ils peuvent toujours échanger des bitcoins sans confiance s’ils le souhaitent. Dans le même temps, plusieurs grands fournisseurs de liquidités deviendraient des entités qui échangeraient réellement entre wBTC et BTC et pourraient facturer des frais minimes aux petits utilisateurs qui souhaitent acheter des wBTC auprès d’eux ou les transférer vers Bitcoin.

Donc, en général, la proposition BIP de OP_CAT peut aider à construire des contrats intelligents sur Bitcoin avec seulement 13 lignes de code, mais il y aura encore beaucoup de discussions et de solutions d’essai pour les détails spécifiques de chaque projet.

La culture mémétique prend de l’ampleur et fait progresser la technologie

Rijndael (@rot 13 maxi), membre de l’équipe TaprootWizards, s’est rendu sur les réseaux sociaux pour partager les différentes mécaniques complexes qu’ils utilisent pour créer des œuvres d’art. Pour y parvenir, ils s’appuient sur une variété de techniques, notamment la récursivité ordinale, les transactions pré-signées, la cryptographie symétrique et la gestion de la charge côté client. Dans le processus de création de l’art, ils ont spécifiquement choisi d’utiliser des transactions pré-signées pour effectuer des opérations, montrant comment pré-soumettre le hachage d’une transaction à l’aide d’un contrat intelligent tel que OP_CAT ou CTV.

Mais Armin Sabouri a commenté sarcastiquement : « Le code et l’effort technique requis pour créer une collection évolutive de jetons non fongibles peuvent représenter 100 fois la quantité de travail nécessaire pour réactiver un code d’opération. 」

OP_CAT est considéré comme un code d’opération simple et facile à comprendre, et il a été soutenu qu’il peut rendre Bitcoin « quantique sécurisé » en signant des signatures ECDSA. Cette idée a été soutenue par certains et a inspiré le Taproot Wizard à lancer la campagne Quantum Cats Non-fungible Token pour sensibiliser le public à OP_CAT.

Cependant, il n’y a pas que OP_CAT qui utilise la culture mémétique pour créer un élan pour le progrès technologique.

Inspirée par Quantum Cats et son prix de vente de 0,1 BTC, et peut-être en partie insatisfaite de son prix de vente élevé, la communauté OP_CTV a également lancé un mème sandwich appelé #rubinsreubens pour promouvoir la technologie de OP_CTV.

Ce mème sandwich était à l’origine conçu comme une réponse humoristique au chat quantique et à ses mèmes. Cependant, c’est en fait très efficace car, comme CTV, il ajoute de la hiérarchie et vous pouvez faire autant de couches sur le « sammich » que vous le souhaitez.

Ce mème sandwich a attiré l’attention de nombreuses personnes. Les mèmes sont drôles et peuvent être utilisés pour montrer leur soutien à quelque chose, mais il est également important d’en comprendre la signification. L’objectif de la #rubinsreubens est d’améliorer la compréhension des propositions de OP_ctv, LNHANCE et Soft Fork pour le nouveau code de fonctionnement de la BTC et l’activation du Smart Contract.

Causes potentielles des défaillances de OP_CAT

Pour en revenir à OP_CAT, les gens peuvent s’opposer à l’introduction de fonctionnalités telles que OP_CAT pour un certain nombre de raisons. Tout d’abord, l’ajout de nouveaux codes de fonctionnement ou de fonctionnalités telles que OP_CAT pourrait augmenter la complexité de Bitcoin, le rendant plus difficile à comprendre et à utiliser en toute sécurité, ce qui augmenterait les risques. Deuxièmement, les problèmes de sécurité lors de l’introduction de nouvelles fonctionnalités ne doivent pas être négligés, et les fonctionnalités qui n’ont pas été entièrement testées peuvent abriter des vulnérabilités qui compromettent la sécurité globale de Bitcoin. De plus, si la mise à niveau du soft fork n’est pas adoptée par tous les nœuds, cela peut entraîner la scission du réseau, ce qui entraîne la coexistence de différentes versions du réseau Bitcoin, ce qui complique la recherche d’un consensus.

Les nouvelles fonctionnalités peuvent poser des problèmes de compatibilité, surtout si elles ne prennent pas en charge les nœuds plus anciens, ce qui peut exclure certains nœuds du réseau, ce qui a un impact négatif sur l’écosystème de Bitcoin. En particulier pour les utilisateurs qui n’ont pas effectué de mise à niveau, ils peuvent se retrouver dans l’incapacité de continuer à participer au réseau. De plus, certains peuvent considérer l’introduction de nouvelles fonctionnalités comme une décision hâtive sans donner la priorité à la résolution des problèmes urgents du protocole de base de Bitcoin. Des changements précipités peuvent introduire des risques et de l’instabilité inutiles.

En plus des considérations de sécurité et de risque, les deux principales raisons pour lesquelles OP_CAT échouera sont : la peur du Smart Contract dans la communauté Bitcoin et le manque de « légitimité » dans le BitcoinSmart Contract.

Peur des contrats intelligents

La peur de BitcoinSmart Contract peut être un autre obstacle important à la réalisation de OP_CAT. En tant que composant central de la technologie Blockchain, les contrats intelligents jouent un rôle essentiel dans de nombreux projets Blockchain, en particulier sur des plateformes telles qu’Ethereum.

Cependant, dans la communauté Bitcoin, l’acceptation des contrats intelligents est relativement faible, en partie en raison des préoccupations concernant les risques et les défis que les contrats intelligents peuvent poser. Les contrats intelligents peuvent avoir un impact sur les valeurs fondamentales de Bitcoin, telles que le peer-to-peer, la décentralisation et la sécurité. La communauté Bitcoin prend très au sérieux le maintien de ces valeurs fondamentales, et tout changement considéré comme menaçant ces valeurs est susceptible de faire l’objet d’opposition.

L’une des principales préoccupations concernant les contrats intelligents est qu’ils peuvent augmenter la complexité et les risques de sécurité sur l’ensemble du réseau. Les contrats intelligents impliquent souvent une logique et un code complexes, et tout petit bug ou vulnérabilité peut entraîner de graves problèmes de sécurité et même des pertes massives de fonds, comme cela s’est produit dans certains projets Blockchain dans le passé. En outre, l’introduction de contrats intelligents peut rendre l’ensemble du système plus difficile à comprendre et à auditer, ce qui augmente la probabilité d’erreurs.

De plus, la communauté Bitcoin a toujours mis l’accent sur le maintien de la stabilité et de la sécurité du réseau. La philosophie de conception de Bitcoin penche vers la simplicité et le conservatisme, donnant la priorité à la sécurité et à la décentralisation du réseau. Par conséquent, tout changement important qui pourrait constituer une menace pour la cyberstabilité fait l’objet d’un examen minutieux et d’un débat approfondi. L’introduction de OP_CAT et des contrats intelligents, tout en apportant potentiellement de nouvelles fonctionnalités et possibilités à Bitcoin, peut également être considérée comme contraire à la vision et à la philosophie de conception originales de Bitcoin.

Satoshi Nakamoto avait-il « tort » ?

La restauration de OP_CAT Operation Code a suscité une discussion approfondie au sein de la communauté, en partie parce qu’elle touche à un sujet sensible : cela signifie-t-il que Satoshi Nakamoto a tort ?

En tant que fondateur de Bitcoin, les décisions et la conception originale de Satoshi Nakamoto sont considérées comme une bible par beaucoup, et sa vision originale est considérée comme un guide central pour le développement de Bitcoin. Par conséquent, tout type de contestation ou de modification de la décision de Satoshi Nakamoto peut être considéré comme un manque de respect envers son héritage ou un écart par rapport aux principes fondamentaux de Bitcoin. Après tout, dans l’industrie de la Blockchain, la légitimité a toujours été un sujet incontournable.

Par conséquent, la proposition de restaurer le OP_CAT touche également à une question plus large : Bitcoin doit-il être une entité statique ou doit-il s’adapter à l’évolution de l’environnement technologique et des besoins des utilisateurs ?

Cependant, le domaine technique progresse et change constamment, et Bitcoin, en tant qu’innovation technologique, ne peut pas se débarrasser complètement de cette loi, et apparemment l’équipe de Taproot Wizard qui soutient la restauration de OP_CAT le pense. Après tout, ils ont délibérément conçu le plus grand BitcoinBlock de tous les temps, juste en dessous de la limite de 4 Mo de Bitcoin, pour libérer des assistants de racine pivotante de jetons non fongibles.

Udi Wertheimer, fondateur de Taproot Wizard, a déclaré qu’il comprenait que beaucoup de gens pensent que Bitcoin ne devrait pas changer. Il pense que les changements dans Bitcoin devraient être lents, prudents et délibérés. Il soutient que Bitcoin est trop jeune pour se solidifier complètement, notant que le processus de gouvernance est en quelque sorte brisé. Bien que la communauté technique s’accorde généralement à dire qu’il y aura d’autres mises à niveau de Bitcoin, il est vraiment difficile de déterminer exactement quelles mises à niveau le seront. Néanmoins, Wertheimer a souligné que le changement est nécessaire car le bitcoin actuel n’est pas encore en mesure de servir des milliards de personnes.

Bien entendu, de tels changements s’accompagnent également de risques et de défis, tels que des problèmes de sécurité, des risques de fragmentation du réseau, des problèmes de compatibilité, etc., qui doivent être soigneusement examinés et traités.

Comme on pouvait s’y attendre, à l’avenir, pour s’assurer que les améliorations proposées sont sûres et efficaces, le déploiement de OP_CAT dans un environnement de réseau de test est une étape essentielle qui permet aux développeurs d’identifier et de résoudre les problèmes sans affecter le réseau principal.

Dans le même temps, afin de vraiment réaliser le « redémarrage » de OP_CAT, l’ensemble du processus durera longtemps, voire des années, car il implique de nombreuses considérations et équilibres, y compris des détails techniques, un consensus de la communauté et des considérations pour la sécurité et la stabilité du réseau Bitcoin, et surtout, un large soutien et une reconnaissance de la communauté.