[Thread] Die übersehene Wahrheit: Der wahre Grund für die Freigabe von OP_RETURN in Bitcoin Core v30

Chainfeeds Einleitung:

Die OP_RETURN-Politikänderung in Bitcoin Core v30: Es handelt sich nicht um eine Kapitulation gegenüber Ordinals, sondern um eine proaktive Steuerung für das BitVM-Ökosystem. Es ist keine passive Reaktion auf Spekulationen, sondern eine vorausschauende Vorbereitung für technologische Innovationen. Dies ist das vorausschauende Denken der Core-Entwickler.

Quelle:

Autor:

Aaron Zhang

Meinung:

Aaron Zhang: Im April 2024 veröffentlichte Citrea die erste vollständige BitVM-Bridge – Clementine. Sie ist das erste zkRollup auf Bitcoin und verwendet BitVM für die L1-Verifizierung. Dann stießen sie auf ein technisches Problem: Sie mussten 144 Bytes Ankerdaten on-chain veröffentlichen. Diese 144 Bytes bestehen aus 128 Bytes: Groth16 Zero-Knowledge Proof und 16 Bytes: total accumulated work (Gesamtnachweis der Arbeitsleistung). Diese Daten werden benötigt, wenn Watchtower den Operator herausfordert, um zu beweisen, dass sie die korrekte Bitcoin-Chain besitzen. Das Problem: OP_RETURN erlaubt nur 83 Bytes. Das reicht nicht. Manche fragen vielleicht, warum man die Daten nicht im Witness unterbringt, wie bei Ordinals? Der entscheidende Unterschied ist, dass Citreas nachfolgende Verifizierungstransaktionen diese Daten lesen müssen. Bitcoin Script kann jedoch nicht auf Witness-Daten vorheriger Transaktionen zugreifen. Daher müssen die Daten an der scriptPubKey-Position stehen – das ist keine Option, sondern eine Notwendigkeit. Kurz gesagt: Witness-Daten können nur die Gültigkeit der aktuellen Transaktion beweisen, können aber nicht von nachfolgenden Transaktionen gelesen werden. scriptPubKey-Daten können von nachfolgenden Transaktions-Skripten referenziert werden. Die Verifizierungslogik von BitVM benötigt eine kettenartige Referenzierung, daher muss scriptPubKey verwendet werden. 83 Bytes reichen nicht aus, sodass Citrea gezwungen war, eine sehr schlechte Methode zu verwenden: Sie erstellten „unspendable“ Taproot-Outputs und tarnten die Daten als öffentliche Schlüssel. Das Problem bei diesem Ansatz ist eine permanente Aufblähung des UTXO-Sets. Jede WatchtowerChallenge-Transaktion erzeugt zwei UTXOs, die niemals bereinigt werden können. Alle Full Nodes müssen diese gefälschten öffentlichen Schlüssel dauerhaft speichern. Genau dies ist das schlimmste Szenario, das die Core-Entwickler immer vermeiden wollten. Die Gedankenkette der Core-Entwickler: Der aktuelle Stand ist, dass Citrea gefälschte UTXOs verwendet (schlecht), und in Zukunft werden weitere BitVM-Projekte diesem Beispiel folgen oder sie verwenden Bare-Multisig (wie das Stamp-Protokoll). Das Fazit ist, dass es besser ist, OP_RETURN zu öffnen und einen Weg mit „geringerem Schaden“ zu bieten. Das ist eine Harm-Reduction-Strategie. Warum ist Core bereit, für BitVM den Weg zu ebnen? Weil BitVM eine wichtige Innovationsrichtung für Bitcoin L1 ist. Blockstream-CEO Adam Back sagte: „Der Ankermechanismus von BitVM ist eine wichtige Richtung für L1.“ Wenn sich das BitVM-Ökosystem entwickelt: Verschiedene zkRollups, Cross-Chain-Bridges und komplexe On-Chain-Verifizierungen werden ähnliche Ankeranforderungen haben.