Pourquoi le changement OP_RETURN de Bitcoin Core v30 est en réalité une démarche stratégique (pas une concession)

Tout le monde parle de la version 30 de Bitcoin Core qui supprime la restriction OP_RETURN, mais la plupart ont tout inversé. Ce n’est pas Core qui cède face à l’engouement pour les Ordinals—c’est Core qui ouvre activement la voie pour l’avenir de BitVM. Voici ce qui s’est réellement passé.

Le vrai problème dont personne ne parlait

En avril 2024, lorsque Citrea a lancé Clementine (le premier zkRollup basé sur BitVM), ils ont rencontré un mur. Ils devaient stocker 144 octets de données critiques sur la chaîne—128 octets pour les preuves à zéro connaissance et 16 octets pour la preuve de travail total. Ces données sont référencées plus tard lorsque les watchtowers défient les opérateurs et doivent vérifier la chaîne Bitcoin.

Mais voici le problème : OP_RETURN ne permet que 83 octets. Pas assez.

Pourquoi ne pas simplement utiliser les données de witness comme Ordinals ?

C’est là que la nuance technique devient importante. Les Ordinals peuvent utiliser les données de witness parce qu’ils ne s’intéressent qu’à prouver la validité d’une transaction. Mais la vérification de BitVM nécessite une référence en chaîne—les transactions suivantes doivent pouvoir lire ces données. Le script Bitcoin a une règle stricte : vous ne pouvez pas lire les données de witness des transactions précédentes. Point final.

Les données doivent résider dans scriptPubKey. Ce n’est pas un choix ; c’est une exigence technique. Pensez-y comme ceci : les données de witness sont scellées dans une enveloppe (ne prouve que la transaction en cours), tandis que les données dans scriptPubKey se trouvent dans un endroit public où les transactions futures peuvent réellement les voir et les utiliser.

La solution bricolée qui a poussé Core à agir

Forcés par la limite de 83 octets, Citrea a dû faire preuve de créativité—et de laideur. Ils ont créé des sorties Taproot « invendables », déguisant les données en fausses clés publiques. Cela peut sembler astucieux, mais cela a un effet secondaire terrible : chaque défi de watchtower crée deux UTXOs qui ne pourront jamais être nettoyés. Les nœuds complets partout doivent stocker en permanence ces fausses clés publiques.

C’est exactement le scénario cauchemardesque que les développeurs de Core ont essayé d’éviter depuis des années. Gonflement des UTXO. Déchets permanents sur la chaîne.

La stratégie de réduction des dommages

Core a vu la situation clairement : Citrea utilise déjà de faux UTXOs (mauvais), et si BitVM décolle, d’autres projets suivront ou recourront à des multisigs simples comme le protocole Stamp. Des approches encore pires.

Donc, Core a pris la décision—relaxer OP_RETURN et offrir une voie « moins nocive ». On peut l’appeler pragmatisme ou réflexion stratégique, mais c’est essentiellement une réduction des dommages : si les projets BitVM doivent ancrer des données, qu’ils le fassent sans gonfler inutilement l’ensemble des UTXO.

Pourquoi cela a vraiment de l’importance pour l’avenir de Bitcoin

BitVM n’est pas juste une autre innovation crypto—c’est une infrastructure L1 réelle. Adam Back, CEO de Blockstream, a qualifié le mécanisme d’ancrage de BitVM « d’orientation importante pour le L1 ». Si cela décolle (et que tout indique que c’est le cas), nous parlons d’un écosystème de zkRollups, ponts cross-chain, et systèmes de vérification complexes en chaîne. Tous nécessitant des solutions d’ancrage similaires.

En relâchant OP_RETURN maintenant, Core prépare le terrain pour que cette couche d’infrastructure se développe proprement. C’est une vision à long terme, pas une réaction. La scalabilité de Bitcoin pourrait dépendre de décisions comme celle-ci plus que ce que l’on pense.

La prochaine fois que quelqu’un dira que Core fait des compromis, demandez-lui si le gonflement permanent des UTXO ou une limite OP_RETURN légèrement plus grande est le meilleur compromis.