13 lignes de code pour permettre aux contrats intelligents sur Bitcoin ? Comprendre le fork doux OP_CAT
TechFlow SélectionTechFlow Sélection
13 lignes de code pour permettre aux contrats intelligents sur Bitcoin ? Comprendre le fork doux OP_CAT
À la croisée des chemins, le bitcoin fait face à un choix historique : réactiver OP_CAT pour explorer les contrats intelligents, ou rester fidèle à la vision initiale de Satoshi en préservant sa nature pure.
Dédié à des analyses Web3 approfondiesRédaction : Jaleel, BlockBeats
Un opcode autrefois supprimé par Satoshi Nakamoto et depuis longtemps oublié dans les archives du code Bitcoin, « OP_CAT », pourrait bien être sur le point de « renaître ».
Autour de cet opcode OP_CAT, le projet NFT Bitcoin Taproot Wizards a lancé une nouvelle collection appelée Quantum Cats, suscitant un vif débat au sein de la communauté. Bien que l'appellation OP_CAT ne fasse pas directement référence aux « chats » familiers, Taproot Wizards a choisi d'utiliser l'image du chat pour lancer ce nouveau NFT baptisé Quantum Cats, exploitant ainsi la culture des mèmes afin de promouvoir l'opération OP_CAT.
OP_CAT, un opcode retiré par Satoshi du langage script de Bitcoin, refait aujourd'hui surface dans les discussions. Certains développeurs Bitcoin souhaitent « ressusciter » cet opcode via un fork souple impliquant seulement 13 lignes de code, préparant ainsi le terrain pour l'implémentation de contrats intelligents sur Bitcoin. Grâce à l'impulsion des développeurs et à l'utilisation stratégique de mèmes félin, le sujet OP_CAT a atteint un nouveau pic d'attention et de discussion.
« Ressusciter » un opcode supprimé par Satoshi Nakamoto
Les opcodes (opérations de code), également appelés instructions ou fonctions, sont les éléments fondamentaux du langage script de Bitcoin. Historiquement, certains opcodes ont été retirés des versions initiales de Bitcoin en raison de préoccupations concernant des vulnérabilités potentielles dans leur implémentation. OP_CAT fait partie de ces opcodes supprimés.
Initialement inclus dans le jeu d'instructions officiel de Bitcoin, OP_CAT permettait de concaténer deux éléments sur la pile. Cependant, en août 2010, des failles critiques découvertes dans d'autres opcodes comme OP_LSHIFT, pouvant entraîner l'effondrement de nœuds Bitcoin, ont conduit à sa suppression. On craignait aussi que OP_CAT provoque une croissance exponentielle des éléments sur la pile, entraînant une utilisation mémoire proportionnelle non plus linéaire mais exponentielle par rapport à la taille du script.
Par prudence, Satoshi Nakamoto a donc supprimé OP_CAT le 15 août 2010. Ces opcodes retirés sont souvent qualifiés de « désactivés », mais cette terminologie est inexacte : ils ont été entièrement effacés du protocole, rendant leur usage impossible pour tout utilisateur de Bitcoin.
En octobre 2023, le développeur Bitcoin Core Ethan Heilman et Armin Sabouri, ingénieur logiciel principal chez Botanix Labs, ont conjointement publié un brouillon de proposition d'amélioration de Bitcoin (BIP) intitulé « OP_CAT », relançant ainsi fortement le débat.
Ce brouillon, composé uniquement de 13 lignes de code concises, définit clairement une fonctionnalité simple : un nouvel opcode tapscript permettant de concaténer deux valeurs sur la pile. L’inspiration de cette implémentation provient directement de l’opcode OP_CAT originellement supprimé.
Les conditions de « résurrection » sont désormais réunies
Pourquoi un opcode supprimé par Satoshi ferait-il aujourd’hui l’objet d’un regain d’intérêt ? Le brouillon de BIP fournit une explication détaillée : la principale préoccupation portait sur l’utilisation excessive de la mémoire. Par exemple, un script simple poussant un octet sur la pile, puis utilisant OP_DUP pour le copier et OP_CAT pour le concaténer 40 fois, pouvait théoriquement générer une valeur de plus de 1 téraoctet, menaçant la stabilité du réseau.
Toutefois, avec l’évolution technologique, ce problème n’est plus insurmontable. Dans l’architecture tapscript, une règle explicite limite désormais la taille des éléments sur la pile à 520 octets maximum. Cette restriction élimine efficacement le risque d’explosion mémoire, rendant la réintégration sécurisée de OP_CAT envisageable.
La remise en discussion de OP_CAT s’explique par son potentiel à construire des scripts plus complexes et expressifs. Plusieurs facteurs rendent aujourd’hui sa réactivation possible :
1. Demande croissante en contrats intelligents avancés : Avec l’évolution de l’écosystème Bitcoin, la nécessité de contrats plus sophistiqués augmente. OP_CAT enrichit l’expressivité de tapscript en permettant la combinaison d’objets sur la pile. Il peut notamment servir à construire et vérifier des arbres de Merkle, supporter des signatures Lamport post-quantiques, des contrats non-répudiables ou des coffres-forts numériques.
2. Exemples réussis sur d'autres chaînes : Des forks comme Bitcoin Cash ou des sidechains comme Liquid ont réactivé OP_CAT avec succès, l’utilisant pour créer des jetons, gérer des canaux de paiement ou stocker des données. Cela démontre qu’il peut être utilisé de manière sûre sous certaines limites.
3. Sécurité quantique : Des recherches montrent que combiné à des techniques comme les signatures Lamport, OP_CAT pourrait permettre de concevoir des transactions Bitcoin résistantes aux ordinateurs quantiques, renforçant ainsi la sécurité future du réseau.
4. Évolution communautaire et technique : La communauté Bitcoin continue d’évaluer ses choix passés. Une meilleure compréhension du protocole et l’apparition de nouvelles technologies permettent de redonner vie à des fonctionnalités anciennement jugées dangereuses, mais désormais maîtrisables.
Un fork souple, jamais une affaire simple
Sur le plan technique, peu de propositions sont aussi simples à comprendre que celle d’OP_CAT. Pourtant, son activation via un fork souple reposant sur la réaffectation de l’opcode OP_SUCCESS126 reste un processus complexe.
Le dernier fork souple majeur date de trois ans, avec l’activation de Taproot, qui a ouvert la voie aux Ordinals. La communauté Bitcoin accorde une grande importance au consensus et à la transparence. Toute modification importante du code est longuement discutée et examinée. Voici les étapes clés du processus :
1. Rédaction de la proposition et du code : Un développeur rédige un document détaillé expliquant la motivation, les aspects techniques, les impacts et les risques potentiels.
2. Discussion communautaire : La proposition est soumise à la communauté (développeurs, mineurs, investisseurs, utilisateurs) pour examen et retour.
3. Modifications et améliorations : En fonction des retours, l’auteur ajuste la proposition.
4. Vote et consensus : Pour les changements majeurs, un consensus est nécessaire, souvent exprimé par les mineurs via des signaux dans les blocs minés.
5. Implémentation du code : Une fois le consensus atteint, l’équipe Bitcoin Core examine soigneusement le code pour garantir sa qualité et sa sécurité.
6. Fusion dans le dépôt officiel : Après validation, le code est intégré au dépôt principal de Bitcoin.
7. Déploiement et activation : Les nœuds et mineurs doivent adopter la mise à jour. Un seuil d’adoption est requis pour que le changement prenne effet.
À ce stade, la proposition OP_CAT en est encore aux premières phases : elle a été publiée il y a moins de quatre mois, sans numéro BIP attribué, et se trouve entre la phase de rédaction initiale et celle de discussion communautaire.
Que pensent les développeurs Bitcoin ?
Examinons les discussions récentes des développeurs Bitcoin autour de OP_CAT.
Même après sa suppression, l’utilité potentielle de OP_CAT pour les contrats avancés a toujours été débattue. Par exemple, son absence freine des protocoles comme TumbleBit, dont la taille des transactions pourrait être réduite si OP_CAT était disponible.
Après analyse des newsletters Optech et autres sources, voici un résumé chronologique des échanges sur OP_CAT.
2019
Ethan Heilman, co-auteur du brouillon de BIP OP_CAT, avait déjà exprimé en octobre 2019, dans un courrier, sa compréhension de la suppression initiale — liée à des circonstances critiques — tout en soulignant la valeur de OP_CAT : « La plupart des protocoles que nous essayons de construire sur Bitcoin butent sur une limitation : l’impossibilité de concaténer les valeurs sur la pile. En tant que chercheur, je sais que cette contrainte ralentit probablement d’autres innovations. Si je pouvais réactiver un opcode désactivé, ce serait OP_CAT. Bien sûr, avec une condition : limiter chaque concaténation à 64 octets ou moins. »
Andrew Poelstra, directeur de recherche chez Blockstream et expert reconnu en cryptographie Bitcoin, est une figure incontournable du débat. Le 30 janvier 2021, il publie un article intitulé « CAT and Schnorr Tricks I », ravivant l’intérêt pour OP_CAT.
Dans cet article, il explique : « OP_CAT permet de combiner deux éléments sur la pile et d’en repousser le résultat. Cette fonction peut assembler de petits éléments ou diviser un gros élément. CHECKSIGFROMSTACK (CSFS), en revanche, est un opcode inédit sur Bitcoin, capable de valider une signature sur des données arbitraires, contrairement à CHECKSIG, limité aux signatures de transaction. »
Plus important encore, il montre que combiné à CSFS, OP_CAT permet une forme d’« introspection transactionnelle ».
Note : L’introspection transactionnelle permet à un script d’examiner les composants de la transaction elle-même — sorties, montants, signatures — offrant ainsi une capacité de réponse plus fine et intelligente.
L'utilisateur fournit les données complètes de la transaction sur la pile, le script utilise OP_CAT pour les regrouper, les hache, puis passe le résultat à CSFS pour vérification. Ensuite, la même signature et clé sont envoyées à CHECKSIG. Si les deux vérifications réussissent, cela confirme l’authenticité des données. Le script peut alors exécuter des règles basées sur ces informations.
L’influence de Poelstra et la pertinence de son idée ont attiré l’attention des développeurs, alimentant les discussions lors de la réunion hebdomadaire suivante sur l’amélioration du langage script après Taproot.
Deux semaines plus tard, Poelstra publie un deuxième article, « CAT and Schnorr Tricks II ». Il y aborde davantage de détails :
En mai 2019, le développeur Jeremy Rubin propose l’opcode CHECKOUTPUTSHASHVERIFY pour des contrats simples, évitant les risques techniques et sociaux des conceptions antérieures. Ce opcode sera remplacé par SECURETHEBAG, puis par CHECKTEMPLATEVERIFY, qui deviendra la BIP 0119 en janvier 2020.
Parallèlement, Russell O'Connor propose d’ajouter directement CSFS et OP_CAT à Bitcoin pour soutenir des contrats intelligents plus généraux. Cette idée rencontre des résistances, notamment parce que les contrats de type CAT+CHECKSIG sont perçus comme inefficaces, et que les contrats intelligents généralistes restent mal vus.
Initialement sceptique, Poelstra change d’avis à l’automne 2019 après un échange privé avec Ethan Heilman. Ce dernier fait remarquer que des contrats « nuisibles » peuvent déjà être réalisés via CHECKMULTISIG, mais qu’ils ne sont ni adoptés ni supportés par les portefeuilles. Pour illustrer son propos, Heilman lance un défi public : proposer un contrat intelligent « sombre » viable — aucun participant n’y parviendra.
Poelstra conclut alors que la peur des contrats intelligents est exagérée. Il encourage à explorer la création de contrats via OP_CAT, même si cela reste controversé.
2021
Jeremy Rubin, développeur Bitcoin et fondateur de Judica (organisation spécialisée dans le langage Sapio pour contrats intelligents Bitcoin), aborde en juillet 2021 la question de la sécurité quantique via OP_CAT.
Il rappelle une méthode précédente utilisant Lamport pour signer des valeurs de 5 octets, mais souligne ses limites. Il pose alors une question : et si on pouvait signer jusqu’à 20 octets ? Cela permettrait de signer un hash HASH160, potentiellement sécurisé contre les ordinateurs quantiques.
Rubin approfondit la signification de signer un tel hash et explique que même si un ordinateur quantique casse ECDSA, cela ne compromet pas la capacité de vérifier les signatures existantes. Il consulte le cryptographe Madars Virza, qui confirme la faisabilité.
Il note que si les signatures ECDSA étaient elles-mêmes signées avec un algorithme résistant au quantique, Bitcoin deviendrait quantique-proof. La solution à 5 octets mentionnée plus tôt est en réalité une signature Lamport sécurisée. Mais hélas, celle-ci requiert au moins 20 octets consécutifs.
D’où la nécessité d’un opcode similaire à OP_CAT. Il précise cependant que OP_CAT ne peut pas être soft-forké directement dans Segwit v0 car cela modifierait la pile. Pour simplifier, il propose d’utiliser un nouvel opcode OP_SUBSTRINGEQUALVERIFY, qui vérifie l’égalité d’une sous-chaîne.
Le 5 novembre 2021, lors de la conférence Bitcoin d’Atlanta, Jeremy Rubin et Andrew Poelstra interviennent ensemble sur la réactivation de OP_CAT. Ils insistent sur son importance dans le contexte Bitcoin, notamment pour la sécurité quantique et la création de contrats complexes. Combiné à CSFS, OP_CAT permettrait théoriquement des contrats intelligents non récursifs capables d’insérer le hash SHA2 des données de transaction directement sur la pile, imposant ainsi des contraintes fines sur la transaction.
Ils reconnaissent que réactiver CAT ajouterait de la complexité, mais aussi de nouvelles possibilités. Toutefois, cela doit être fait prudemment pour éviter les problèmes passés, comme l’explosion mémoire.
2022
Le 18 mai 2022, sur la liste de diffusion des développeurs Bitcoin, le développeur ZmnSCPxj affirme que pour réaliser des contrats intelligents récursifs inévitables, il faut combiner OP_CAT avec des opcodes comme OP_TX et CSFS. Ces contrats reposent sur la règle de consensus selon laquelle les bitcoins reçus ne peuvent être dépensés que dans le même contrat.
Ces contrats utilisent l’introspection transactionnelle : l’opcode analyse une partie de la transaction qui l’exécute. Les opcodes actuels offrent une introspection limitée. Pour garantir que la sortie précédente et la suivante soient identiques, l’une ou les deux doivent être construites dynamiquement à partir de leurs éléments — d’où la nécessité de CAT ou d’une structure similaire.
Nadav Ivgi ajoute que même pour les contrats récursifs, CAT est nécessaire pour résoudre des problèmes de hachage. Cela signifie que des fonctionnalités comme CTV et APO, centrées sur l’introspection des sorties, pourraient aussi utiliser CAT. Ivgi pense qu’avec Taproot, vérifier la sortie suivante à partir de la précédente faciliterait l’écriture de scripts, et partage deux exemples de contrats récursifs.
ZmnSCPxj approuve l’analyse d’Ivgi, mais réaffirme ses craintes face aux risques des contrats récursifs, tout en notant dans un message ultérieur qu’ils pourraient être sûrs car non Turing-complets. Russell O'Connor cite Poelstra pour montrer que CAT seul, combiné aux fonctions existantes, suffit à créer des contrats non récursifs, et pourrait même permettre des contrats récursifs s’il était réintégré.
2023
En janvier, Anthony Towns lance Bitcoin Inquisition, une version forkée de Bitcoin Core destinée à tester des forks souples et autres modifications majeures sur un signet par défaut. Fin 2023, cette plateforme prend en charge plusieurs propositions, dont une PR (pull request) visant à intégrer OP_CAT, OP_VAULT et à limiter les transactions à 64 octets, élargissant ainsi ses capacités.
Le 23 août 2023, sur la liste Lightning-Dev, Thomas Voegtlin propose une idée de preuve de fraude pour les sauvegardes expirées. Il indique que si OP_CSFS et OP_CAT étaient ajoutés via un fork souple, une telle preuve pourrait être utilisée sur chaîne. Cette proposition suscite de nombreux échanges. Peter Todd souligne que le mécanisme est générique, utile au-delà de LN, bien qu’il propose une alternative plus simple (non développée ici).
En octobre, Rusty Russell étudie les contrats intelligents généraux dans le langage script Bitcoin. Parallèlement, Ethan Heilman et Armin Sabouri publient leur brouillon de BIP pour OP_CAT. Ces deux sujets font l’objet de discussions prolongées jusqu’en novembre.
2024
Début 2024, Quantum Cats parvient à porter la discussion sur le BIP OP_CAT et l’évolution de Bitcoin à un niveau inédit.
Durant les échanges communautaires, la développeuse Bitcoin Core Ava Chow déclare : « Je ne pense pas que CTV représente un consensus approximatif. D’autres propositions plus générales comme txhash ou CAT me semblent plus proches du consensus. Mais je n’ai pas suivi les discussions de près. »
Classée 5e par nombre de contributions au code Bitcoin Core (1292 commits à ce jour), Ava Chow est l’une des rares personnes ayant le droit de fusionner du code. Son influence au sein de la communauté est donc considérable.
« Je ne suggère pas qu’on active OP_CAT. Je le soutiens car c’est un opcode susceptible d’atteindre un consensus. Si vous ne comprenez pas OP_CAT, j’ai résumé la situation dans cette image », déclare Eric Wall (@ercwl), cofondateur de Taproot Wizards.
Cependant, Ava Chow ne semble pas totalement favorable à l’implémentation : « Comme je l’ai déjà dit, je ne pense qu’aucune proposition de contrat intelligent soit proche d’un consensus approximatif. Je pense que nous ne devrions essayer d’activer aucune d’entre elles. »
Dix lignes de code pour des contrats intelligents sur Bitcoin
Comme l’affirme Eric Wall, cofondateur de Taproot Wizards : « Les gens ne s’en rendent pas compte, mais OP_CAT est en réalité l’un des blocs constitutifs d’un zkrollup sur Bitcoin. »
La réintroduction de OP_CAT offre un outil puissant à Bitcoin, permettant à des projets comme BitVM de progresser. Le concept récent de BitVM — vérifier des calculs arbitraires sur Bitcoin — devient ainsi plus simple et efficace grâce à OP_CAT. L’écosystème Bitcoin peut alors créer des contrats intelligents plus expressifs et polyvalents.
Grâce à OP_CAT, il devient possible de définir des conditions préalables pour des sorties Bitcoin spécifiques, ouvrant la voie à de nouvelles méthodes d’extension comme Ark de Blockstream, ou d’autres innovations reposant sur les contrats intelligents. Cela marque une évolution : Bitcoin n’est plus seulement un réseau de paiement, mais aussi une plateforme de calcul décentralisée et extensible.
Bien qu’enthousiasmé par BitVM, Eric Wall pense que cette proposition pourrait être une « impasse technique » pour Bitcoin en raison de ses coûts élevés et de sa longue mise en œuvre. Il craint qu’elle ne détourne l’attention de la communauté et freine les vrais progrès. Malgré tout, BitVM illustre bien l’esprit d’innovation dans le domaine des blockchains et des contrats intelligents.
Par ailleurs, l’équipe de Taproot Wizards travaille elle-même sur une solution de couche 2 pour Bitcoin. Lors d’un Space précédent, elle a annoncé que les 7,5 millions de dollars levés serviraient à financer la recherche sur l’évolutivité de Bitcoin.
La mise en œuvre du fork souple OP_CAT constituerait donc une étape cruciale pour eux. Ancien membre du conseil d’administration de la StarkNet Foundation, Wall s’intéresse vivement à la construction de la finance décentralisée sur des couches de règlement sans permission. C’est naturellement qu’il s’est tourné vers DeFi sur Ethereum quand celle-ci a émergé en 2019.
Quand il est devenu clair qu’Ethereum et d’autres blockchains pouvaient s’étendre via zk-Rollups ou des preuves optimistes de fraude, l’exploration de DeFi sur Bitcoin a presque été abandonnée. Wall s’est alors concentré sur DeFi sur Ethereum, tout en cherchant à ramener ces avantages technologiques vers Bitcoin.
Enfin, sur le forum bitcointalk, Carter Feldman (@cmpeq), fondateur du projet QED, est interrogé sur la manière dont il entend utiliser OP_CAT dans les scripts Bitcoin, ainsi que sur les frais potentiels liés à la taille moyenne de la pile de témoins.
Feldman admet que cela pourrait être coûteux, mais explique que les preuves de Merkle dans son projet servent à construire un script de verrouillage sans confiance ou un système d’ancrage, intégré à une couche 2 zk sur Bitcoin. Ce système permettrait de prouver qu’un retrait spécifique vers une adresse donnée est valide à partir d’une racine d’arbre de retraits (entrée publique d’une preuve ZK).
Pour résoudre le problème des coûts, il envisage un modèle où les utilisateurs ordinaires achètent du BTC emballé (wBTC) sur la couche 2 en verrouillant leurs jetons auprès d’un vendeur pendant une période donnée. Pendant ce temps, l’acheteur doit prouver qu’il a payé le vendeur sur Bitcoin L1. Il sait qu’il peut toujours récupérer son BTC sans confiance. En parallèle, quelques grands fournisseurs de liquidité effectueraient les échanges réels entre wBTC et BTC, facturant de petits frais aux petits utilisateurs.
En résumé, la proposition BIP OP_CAT, avec seulement 13 lignes de code, ouvre la voie à des contrats intelligents sur Bitcoin. Mais les détails d’implémentation varieront selon les projets, générant encore de nombreux débats et expérimentations.
La culture des mèmes au service de l’avancement technique
Un membre de l’équipe TaprootWizards, Rijndael (@rot13maxi), partage sur les réseaux sociaux les mécanismes complexes utilisés pour créer leurs œuvres d’art. Pour y parvenir, ils utilisent des techniques variées : récursion d’ordinaux, transactions pré-signées, cryptographie symétrique et gestion de charge client. Dans ce processus, ils choisissent spécifiquement des transactions pré-signées pour illustrer comment OP_CAT ou CTV permettent de pré-engager le hash d’une transaction dans un contrat intelligent.
Armin Sabouri répond avec ironie : « Les efforts techniques et en code déployés pour créer une collection NFT évolutive sont probablement 100 fois supérieurs à ceux nécessaires pour réactiver un opcode. »
OP_CAT est perçu comme un opcode simple et compréhensible. Certains pensent qu’il pourrait rendre Bitcoin « sécurisé contre le quantique » en permettant de signer des signatures ECDSA. Cette idée trouve un écho favorable, incitant Taproot Wizards à lancer la campagne NFT Quantum Cats pour sensibiliser à OP_CAT.
Mais ce n’est pas le seul cas où la culture des mèmes sert à promouvoir une avancée technique.
Inspiré par Quantum Cats et son prix de 0,1 BTC — peut-être aussi par une certaine critique de ce tarif élevé —, la communauté OP_CTV lance un mème de sandwich appelé #rubinsreubens pour promouvoir la technologie OP_CTV.
Ce mème de sandwich commence comme une réponse humoristique à Quantum Cats, mais s’avère très efficace : tout comme CTV, il ajoute une structure hiérarchique, permettant de superposer autant de couches que souhaité sur le « sammich ».
Le mème attire beaucoup d’attention. Les mèmes sont amusants et expriment un soutien, mais il est crucial d’en comprendre la signification profonde. #rubinsreubens vise à mieux faire connaître op_ctv, lnhance, et les nouveaux opcodes Bitcoin activant les contrats intelligents via des forks souples.
Les raisons possibles de l’échec d’OP_CAT
Revenons à OP_CAT. Plusieurs raisons peuvent motiver une opposition à son introduction. Premièrement, ajouter un opcode comme OP_CAT augmente la complexité de Bitcoin, le rendant plus difficile à comprendre, à utiliser en toute sécurité, et plus exposé aux risques. Deuxièmement, les questions de sécurité liées à de nouvelles fonctionnalités sont cruciales : des caractéristiques mal testées peuvent cacher des vulnérabilités compromettant la sécurité globale. Troisièmement, un fork souple non universellement adopté risque de diviser le réseau, créant des versions concurrentes de Bitcoin, compliquant le consensus.
Les nouvelles fonctionnalités peuvent poser des problèmes de compatibilité, surtout si elles ne supportent pas les anciens nœuds, excluant ainsi certains participants du réseau et nuisant à l’écosystème. Les utilisateurs non mis à jour risquent de se retrouver isol
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
BlockBeats
