jakiro
Auteur : Aaron Zhang ; Source : X, @zzmjxy
Bitcoin Core v30 assouplit la restriction OP_RETURN. Tout le monde dit que c’est parce que « la restriction d’inscription des ordinaux n’est pas valide ».
Au cours des trois derniers mois, j’ai consulté la liste de diffusion Bitcoin Core v30, le livre blanc Citrea et la documentation technique associée.Découvrez une vérité que tout le monde a ignorée : la véritable raison du changement de politique OP_RETURN n’était pas du tout les ordinaux.C’est BitVM.
Cette histoire est plus importante que le récit des Ordinaux.De ce point de vue, personne dans les communautés chinoise et anglaise n’en a jamais parlé.
Contexte de l’affaire
En avril 2024, Citrea a publié le premier pont BitVM-Clementine complet.
Il s’agit du premier zkRollup sur Bitcoin, utilisant BitVM pour la vérification L1.
Ensuite, ils ont rencontré un problème technique : 144 octets de données d’ancrage devaient être publiés en chaîne.
Exigences techniques
Ces 144 octets comprennent :
-
128 octets : preuve de connaissance nulle Groth16
-
16 octets : travail total accumulé (preuve totale de travail)
Ces données ont été utilisées par Watchtower pour prouver qu’elles disposaient de la bonne chaîne Bitcoin lors de l’interrogation de l’opérateur. Voici le problème : OP_RETURN n’autorise que 83 octets.pas assez.
Contraintes techniques fondamentales
Certains pourraient se demander : pourquoi ne pas en témoigner ?Comme les ordinaux ?Différence clé : les transactions de validation ultérieures de Citrea nécessitent la lecture de ces données.
Bitcoin Script ne peut pas référencer les données témoins de la transaction précédente.Les données **doivent** se trouver à l’emplacement scriptPubKey, ce n’est pas facultatif.
Principes techniques
En termes simples, c’est :
Données des témoins :
-
Il peut seulement prouver que « la transaction en cours est valide » ✓
-
Ne peut pas être lu par les transactions ultérieures ✗
Données scriptPubKey :
-
Peut être référencé par des scripts dans les transactions ultérieures ✓
La logique de vérification de BitVM nécessite des références chaînées, donc scriptPubKey doit être utilisé.
plan forcé
83 octets n’étaient pas suffisants, alors Citrea a été contraint d’utiliser une approche terrible : créer des sorties Taproot « inutilisables » qui déguisent les données en clés publiques.
Méthodes spécifiques :
-
Sortie 0 : OP_1 <Les 32 premiers octets sont déguisés en clé publique>
-
Sortie 1 : OP_1 <32 octets déguisés en clé publique>
-
Sortie 2 : OP_RETURN <80 octets restants>
Ces « clés publiques » n’ont aucune clé privée correspondante. Il ne sera jamais dépensé.
analyse des dangers
Le problème de cette solution : gonfler en permanence l’ensemble UTXO.
Chaque transaction WatchtowerChallenge crée deux UTXO qui ne pourront jamais être nettoyées.Tous les nœuds complets doivent stocker ces « fausses clés publiques » en permanence.C’est exactement le pire des cas que les développeurs Core ont essayé d’éviter.
Texte original de la liste de diffusion
Antoine Poinsot écrit clairement dans la proposition :
« Clementine utilise les sorties Taproot non utilisables pour stocker les données… en raison des limitations de taille de OP_RETURN »
Ce cas **déclenche directement** la proposition de changement de politique OP_RETURN.E-mail d’origine.
Logique du développeur
Chaîne de réflexion des développeurs principaux :
-
Situation actuelle : Citrea utilise de faux UTXO (mauvais)
-
Avenir : d’autres projets BitVM suivront
-
Ou : ils utilisent le multisig nu (comme le protocole Stamp)
-
Conclusion : il vaut mieux abandonner OP_RETURN et fournir un chemin « moins nuisible »
Il s’agit d’une stratégie de réduction des méfaits.
La position stratégique de BitVM
Pourquoi Core est-il prêt à « ouvrir la voie » à BitVM ?Parce que BitVM est une direction importante de l’innovation Bitcoin L1.
Adam Back, PDG de Blockstream, a déclaré : « Le mécanisme d’ancrage de BitVM est une direction importante de L1. »
Si l’écosystème BitVM se développe :
-
Divers zkRollups
-
Ponts à chaînes croisées
-
Vérification complexe en chaîne
Il y aura des besoins d’ancrage similaires.
La différence essentielle avec les ordinaux
Données d’ancrage Ordinaux vs BitVM :
Ordinaires :
-
Localisation : Témoin (peut être taillé)
-
Motif : spéculation/art
-
Caractéristiques : Peut s’estomper
Ancre BitVM :
-
Emplacement : scriptPubKey (doit être permanent)
-
Motivation : Besoins en matière de sécurité des infrastructures
-
Caractéristiques : demande de croissance à long terme
Scénario technique complètement différent.
Conclusion
Par conséquent, le changement de politique OP_RETURN de Bitcoin Core v30 n’est pas un abandon aux ordinaux, mais un guide actif pour l’écosystème BitVM ; il ne s’agit pas d’une réponse passive à la spéculation, mais d’un moyen d’ouvrir la voie à l’innovation technologique à l’avance.Il s’agit d’une réflexion prospective de la part des développeurs Core.
Par conséquent, Core n’a jamais mis l’accent sur le JPEG, mais :
-
Ouvrir la voie aux futures VM (BitVM/Simplicity/Covenants)
-
Nettoyer les règles particulières laissées il y a plus de dix ans pour que le système puisse continuer à évoluer
-
Éviter que le niveau politique ne devienne un « consensus invisible » qui limite l’innovation
Maîtrisez-les et vous comprendrez l’orientation technique du Bitcoin dans les dix prochaines années. Il ne s’agit pas seulement d’une guerre de mots entre vs.Ordinals et vs. Knots, mais d’une véritable compréhension de la logique de l’évolution technologique.
