OP_CAT, la mise à jour qui va révolutionner Bitcoin ?

OP_CAT, ce n’est ni notre petit compagnon favori ni le dernier mème coin à la mode. Il s’agit d’un tout autre animal, plus technologique. OP_CAT, c’est une fonction initialement présente dans le code de Bitcoin et qui pourrait, si elle venait à ressurgir, changer la face du protocole tel qu’on le connait aujourd’hui. Les enjeux sont grands et beaucoup plus complexes qu’il n’y parait de prime abord.

L’entité à l’initiative de la résurgence de la fonction OP_CAT dans les discussions sur Bitcoin, c’est Starkware. Cette firme est à l’origine de Starknet, protocole de seconde couche bien connu et déployé récemment sur Ethereum. Sa particularité ? La technologie des ZKP (Zero Knowledge Proofs) dont nous allons de ce pas expliciter les détails. Starkware vient, en l’occurrence, de déposer une demande d’amélioration du protocole Bitcoin : le BIP 347 dont nous expliquerons les tenants et aboutissants dans la suite de cet article.

L’émergence des Zero Knowledge Proofs (ZKPs)

Tout démarre de l’idée d’un homme, Eli Ben-Sansson, l’inventeur des zk-starks ou ZKPs (Zero Knowledge Proofs). Les ZKPs sont des protocoles cryptographiques qui permettent de prouver la validité d’une information sans dévoiler le contenu de celle-ci. Par exemple, grâce à cette technologie, vous êtes en mesure de prouver que vous disposez d’un permis de conduire sans toutefois être obligé de montrer celui-ci, et donc par extension de dévoiler votre identité.

Cette technologie fait sont apparition à partir de 1992 avec l’émergence du protocole PCP pour « Probabilistic Checking of Proofs ». Celui-ci permet de garantir l’intégrité d’un calcul volumineux à partir d’un ordinateur de faible puissance. Un tour de force pour l’époque. Dès lors, un calcul complexe peut ainsi être vérifiable par tous, à une condition toutefois : que cet ordinateur soit fiable à 100%.

Et c’est là que le bât blesse : un ordinateur fiable à 100%, c’est un scénario impossible dans les années 90’ car tous les systèmes sont alors centralisés. Cette condition fut rendue possible seulement des années plus tard, en 2008, grâce à une invention qui va tout changer : l’apparition des blockchains décentralisées. La technologie qui a émergée avec Bitcoin a permis de supprimer le besoin d’intermédiaire : une véritable révolution ! L’innovation autour des système PCP retrouve tout à coup un nouveau souffle.

Les Zk-starks : la problématique Bitcoin

En 2013, Elie Ben-Sansson présente son fameux projet : les ZKPs sur Bitcoin. Néanmoins, un souci de taille se pose à lui : pour construire sur Bitcoin, il faut coder dans le langage qui lui est propre : Bitcoin Script. C’est un langage très simple et très sécurisé mais dont la contrepartie est un niveau de complexité très limité pour ses applications.

Le langage Bitcoin Script est un langage qui n’est intentionnellement pas Turing-Complet. Cela signifie qu’il ne permet pas de réaliser des boucles, procédé très répandu dans les langage de programmation et source d’une grande liberté pour les programmeurs. Par exemple, avec Bitcoin Script, impossible de réaliser des multiplications sur Bitcoin. Il faut obligatoirement passer par des additions, ce qui rend la programmation très laborieuse.

Ce langage se compose d’une série d’instructions appelées opcodes. Ces opcodes décrivent essentiellement les paramètres associés à l’accès aux bitcoins lors d’une transaction entre deux personnes et à la gestion de leur détention. De fait, faute d’avoir un langage suffisamment permissif pour implémenter sa technologie des ZKPs sur Bitcoin, Eli se tourne vers d’autres solutions.

Eli créé sa propre blockchain, Zcash en 2016, un hard fork de Bitcoin. Malgré cela, il reste sur sa faim. En effet, Zcash ne bénéficie pas du même effet de réseau et du même niveau de décentralisation que Bitcoin.

Les Zk-starks : l’option Ethereum

Toutefois, à cette même époque émerge une nouvelle blockchain particulièrement décentralisée et disposant d’un important effet réseau : Ethereum.

De plus, celle-ci choisit de se tourner résolument vers la création d’applications et de s’orienter vers les solutions de sharding. Derrière ce mot compliqué se trouve tout simplement la volonté de développer des couches supérieures, au-dessus du réseau principal Ethereum, afin d’accueillir tout un tas d’applications : les fameux layers 2 (L2) et layers 3 (L3), aussi appelés rollups.

Ces couches supplémentaires vont permettre de désencombrer le réseau principal en traitant bien plus de transactions par secondes sur leur propre chaine, en dehors du réseau. Elles les regroupent ensuite par paquets afin de les faire valider par la blockchain principale pour le prix d’une seule transaction. Un moyen d’augmenter considérablement la scalabilité du réseau Ethereum, c’est-à-dire le nombre de transactions pouvant être effectuées dans un même laps de temps.

C’est le terrain de jeu parfait pour Starkware, l’entreprise créé par Eli afin de développer sa technologie des Zero Knowledge Proofs. En 2020, Eli créé StarkEx, le premier rollup utilisant les zk-starks déployé sur Ethereum.

Un terrain de jeu parfait, à moins que…

Les Zk-starks : le retour sur Bitcoin ?

À moins que cela ne satisfasse pas complètement Eli Ben-Sansson… Le réseau Bitcoin est le plus sécurisé au monde. Profiter de sa sécurité infaillible au sein de layers 2, eux-mêmes porteurs d’une multitude d’applications décentralisées, serait pour lui le saint Graal.

Actuellement, il est impossible pour la blockchain Bitcoin de vérifier l’intégrité de l’entièreté des transactions traitées par ses réseaux de seconde couche (layers 2). Avec les zk-starks, comme nous le précisions au début de cet article, cela serait enfin possible.

Pour imager, considérons que les transactions sur un layer 2 sont des courriers à distribuer. Ceux-ci sont regroupés sous forme de colis puis envoyé sur la chaine principale. Pour l’instant, la blockchain Bitcoin vérifie uniquement le code barre du colis, mais pas son contenu. Il est donc impossible de s’assurer de l’intégrité des transactions présentes à l’intérieur du colis, ou en l’occurrence produites sur le layer 2. Avec les ZKP de Starknet, cela devient possible… seulement et seulement si une certaine instruction du langage Script de Bitcoin est réintégrée au protocole Bitcoin : la fameuse instruction OP_CAT. La star de notre article, la voici en chair et en code ! C’est une opération de concaténation essentielle au fonctionnement des zk-starks.

OP_CAT, clé de voûte des ZK-starks

Cette instruction de concaténation, anciennement présente au sein du protocole Bitcoin mais bannie depuis, pourrait tout changer. Cette opération permettrait de faire fonctionner des technologies comme les covenants ou encore les arbres de Merkle (ou Merkel Trees), essentiels au fonctionnement des ZKPs.

Pour faire simple, les covenants permettent de rendre conditionnel la dépense de bitcoins. Cela signifie pouvoir dépenser des BTC sous certaines conditions. L’exemple typique dans le monde réel serait les tickets restaurants qui ne peuvent être utilisés que dans certains commerces, et pas dans d’autres.

Les arbres de Merkel, quant à eux, sont des structures qui, bien que dépourvues de feuilles, permettent de vérifier l’intégrité des données. L’instruction OP_CAT rend possible l’intégration des arbres de Merkle directement dans le script de Bitcoin, faisant ainsi fonctionner les ZKPs d’Eli Ben-Sansson. À titre d’exemple, cette technologie pourrait autoriser l’hébergement de fichiers décentralisés sur Bitcoin mais surtout : le développement de layers 2 et d’applications décentralisée (dApps) sur la reine des blockchains.

Toutefois, comme précisé brièvement juste un peu plus haut, il y a un hic. L’instruction OP_CAT a été retirée en 2010 de la liste des commandes disponibles par Satoshi Nakamoto lui-même, au tout début de l’existence du protocole. Il en a été de même, en réalité, pour de nombreux opcodes, ces outils qui permettent de réaliser des opérations simples dans le langage Script de Bitcoin. Satoshi s’était en effet rendu compte d’un souci d’interaction entre ces fonctions et le langage Bitcoin Script. Il existait alors un risque de saturation des nœuds Bitcoin. Pour ne prendre aucun risque, un certain nombre d’opérations dont OP_CAT ont été bannies à ce moment-là.

L’instruction OP_CAT fait 8 lignes. 8 lignes de codes qui pourraient tout changer. 8 lignes de codes pour déployer Starknet et ses ZKPs sur Bitcoin. Mais pourquoi sa réintroduction dans le protocole Bitcoin fait-elle autant débat ?

OP_CAT : le point sur la situation actuelle

En ce moment même, une nouvelle version d’OP_CAT est proposée à la communauté Bitcoin sous l’identifiant BIP 347 (Bitcoin Improvment Proposal) avec un code revu qui assure un contrôle de longueur capable de prévenir tout risque de saturation des nœuds.

Cette révision du code permettrait d’éliminer le vecteur d’attaque initialement redouté, mais ce n’est pas suffisant. Starkware, l’entreprise derrière Starknet, a lancé un fond d’1 million de dollars pour soutenir la recherche autour de la fonction OP_CAT. Ce faisant, ils souhaitent permettre aux chercheurs de mettre en lumière les avantages et inconvénient de la réintégration de cette fonction au sein du code de Bitcoin. Ceci afin d’appuyer leur demande auprès de la communauté Bitcoin. Le combat est toutefois loin d’être gagné.

En effet, une partie significative de la communauté Bitcoin souhaite une « ossification » du protocole dans son état actuel. Ils sont conscients que tout changement du code source entraînerait inévitablement un risque pour celui-ci. L’ajout de ces 8 lignes de code serait-il en mesure de faire émerger de nouveaux vecteurs d’attaque non anticipés par les programmeurs ? Là est toute la question et c’est pourquoi le retour de l’opération OP_CAT dans le code Script de Bitcoin reste incertain aujourd’hui. Tout changement du code de Bitcoin comporte des risques, si infimes soient les modifications.

« Le meilleur moyen de ne pas introduire de bug est de ne pas écrire de code. »

Cette phrase, régulièrement utilisée comme mème par les développeurs, est particulièrement juste à propos de Bitcoin. L’espérance de gain de n’importe quel BIP pourrait bien être devenu négative aux yeux de certains au vu de la nouvelle dimension prise par le réseau Bitcoin aujourd’hui. Ils ne souhaitent pas prendre le risque de « tout casser ».

Bitcoin : Réserve de valeur ou moyen d’échange ?

En réalité, cette discussion autour de la fonction OP_CAT fait écho à un débat plus large au sein de la communauté Bitcoin. La source de cette confrontation prend ses racines dans le questionnement suivant : Bitcoin est-il une réserve de valeur ou un réseau d’échange ?

Si Bitcoin se cantonne à un rôle de réserve de valeur, alors l’ajout de la fonction OP_CAT n’a aucun sens.

Bitcoin est parfait dans son état actuel pour assurer cette fonction. Nul besoin de construire de couches supplémentaires, de faciliter la création d’applications ou les échanges monétaires. Les bitcoins doivent simplement être achetés puis conservés dans le temps, nul besoin de les déplacer ou de les intégrer à un éventuel système similaire à la Finance Décentralisée (DeFi) sur Ethereum.

Toutefois, dans son whitepaper, Satoshi lui-même choisissait pour titre « Bitcoin, a Peer to Peer Electronic Cash System ». Ou dans notre bon vieux français : « Bitcoin, un système de paiement électronique pair à pair ». Bitcoin : un moyen d’échange entre individus.

Les partisans de ce statut de moyen d’échange souhaitent évidemment augmenter la scalabilité du réseau Bitcoin afin d’en faire un système de paiement utilisé partout dans le monde. Un réseau qui accueillerait potentiellement en son sein tout un tas d’applications, à l’image d’Ethereum aujourd’hui. Ils cherchent à résoudre le fameux Trilemme de la Blockchain, à savoir obtenir un réseau à la fois sécurisé, décentralisé et scalable. Pour ceux qui souhaitent orienter le protocole Bitcoin dans cette direction, la solution des ZKPs proposée par Starware et Eli Ben-Sansson prend tout son sens. Elle permettrait une avancée significative vers cet objectif.

De nombreux développeurs sont confiants dans l’implémentation d’OP_CAT. Toutefois, même si le risque est très limité, le jeu en vaut-il la chandelle ? Vaste débat. Et vous, quel est votre avis sur la question ?

Starknet sur Bitcoin, cycle vertueux ?

Si l’on se projette plus loin toutefois, il est difficile d’envisager la pérennité du réseau Bitcoin sans transactions ni échanges. Bitcoin ne peut pas devenir une masse immuable. Pour une raison très simple : la rémunération des mineurs. Tous les quatre ans, la récompense en nouveaux bitcoins offerts aux mineurs diminue. Mécaniquement, la part de cette rémunération représentée par les frais de transaction croit par rapport à celle relative aux nouveaux bitcoins créés. Si les transactions sur le réseau venaient à se tarir, la rémunération des mineurs, au bout d’un certain temps, s’en retrouverait très limitée et leur business model menacé.

De fait, trouver une source de rémunération alternative, autre que la récompense en nouveaux bitcoins minés est essentielle pour la survie du réseau Bitcoin. Dans la poursuite de ce but, le déploiement d’applications facilitées par les ZKPs de Starkware via le retour de l’instruction OP_CAT dans le code de Bitcoin prend tout son sens.

Le réseau Starknet servirait de couche de base pour accueillir une multitude d’applications décentralisées, certaines de profiter de la sécurité du réseau le sécurisé au monde : Bitcoin. Ces applications génèreraient du trafic et donc plus de frais pour le réseau. Cela augmenterait les gains des mineurs et renforcerait donc l’attractivité de la blockchain Bitcoin. Et in fine, cela renforcerait sa sécurité et participerait à la bonne santé du réseau et à sa pérennité.

Pour toutes ces raisons, l’approbation ou non du BIP 347 concernant OP_CAT est loin d’être une question tranchée. La prise de décision n’est pas pour demain. Elle pourrait prendre 6 mois à un an dans le meilleur des cas, avant d’être mise sur la table. Et son implémentation a des chances d’être tout simplement refusée. On se donne donc rendez-vous dans quelques années pour la réponse sur cette épineuse question.