[Long thread] La vérité négligée : la véritable motivation derrière l’assouplissement d’OP_RETURN dans Bitcoin Core v30

Chainfeeds Guide :

Le changement de politique OP_RETURN dans Bitcoin Core v30 : il ne s'agit pas d'une capitulation face à Ordinals, mais d'une orientation proactive pour l'écosystème BitVM. Ce n'est pas une réaction passive à la spéculation, mais une anticipation pour préparer le terrain à l'innovation technologique. C'est une réflexion prospective des développeurs Core.

Source de l'article :

Auteur de l'article :

Aaron Zhang

Opinion :

Aaron Zhang : En avril 2024, Citrea a lancé le premier BitVM bridge complet — Clementine. Il s'agit du premier zkRollup sur Bitcoin, utilisant BitVM pour la vérification L1. Ils ont alors rencontré un défi technique : il fallait publier sur la chaîne 144 octets de données d'ancrage. Ces 144 octets comprennent 128 octets : une preuve à connaissance nulle Groth16, et 16 octets : total accumulated work (preuve de travail totale accumulée). Ces données servent à prouver, lors d'une contestation par le Watchtower contre l'Operator, qu'ils détiennent la bonne chaîne Bitcoin. Le problème est le suivant : OP_RETURN n'autorise que 83 octets. Ce n'est pas suffisant. Certains demanderont pourquoi ne pas placer ces données dans le witness, comme le fait Ordinals ? La différence clé est que les transactions de vérification ultérieures de Citrea doivent lire ces données. Or, Bitcoin Script ne peut pas référencer les données witness de la transaction précédente. Les données doivent donc être placées dans scriptPubKey, ce qui n'est pas optionnel. Pour résumer : les données witness ne peuvent que prouver la validité de la transaction actuelle, mais ne peuvent pas être lues par les transactions suivantes. Les données scriptPubKey peuvent être référencées par le Script des transactions ultérieures. La logique de vérification de BitVM nécessite une référence en chaîne, donc scriptPubKey est indispensable. Les 83 octets ne suffisent pas, Citrea a donc été contrainte d'utiliser une méthode très problématique : créer des outputs Taproot « non dépensables », en déguisant les données en clé publique. Le problème de cette solution est qu'elle gonfle de façon permanente le set UTXO. Chaque transaction WatchtowerChallenge crée deux UTXO qui ne pourront jamais être nettoyés. Tous les nœuds complets doivent stocker ces fausses clés publiques indéfiniment. C'est précisément la pire situation que les développeurs Core ont toujours cherché à éviter. La chaîne de réflexion des développeurs Core : la situation actuelle est que Citrea utilise de faux UTXO (problématique), à l'avenir davantage de projets BitVM pourraient imiter cette méthode ou utiliser des multisignatures nues (comme le protocole Stamp). La conclusion est qu'il vaut mieux assouplir OP_RETURN, offrant ainsi une voie de « moindre nuisance ». C'est une stratégie de réduction des risques (harm reduction). Pourquoi les développeurs Core sont-ils prêts à ouvrir la voie à BitVM ? Parce que BitVM représente une direction majeure d'innovation sur Bitcoin L1. Le CEO de Blockstream, Adam Back, a déclaré : « Le mécanisme d'ancrage de BitVM est une direction importante pour le L1 ». Si l'écosystème BitVM se développe : divers zkRollups, bridges cross-chain et vérifications on-chain complexes auront tous des besoins similaires en matière d'ancrage.