Autor: Aaron Zhang; Quelle: X, @zzmjxy
Bitcoin Core v30 lockert die OP_RETURN-Beschränkung. Jeder sagt, es liege daran, dass die Beschränkung der Ordinalzahl ungültig sei.
In den letzten drei Monaten habe ich mich mit der Bitcoin Core v30-Mailingliste, dem Citrea-Whitepaper und der zugehörigen technischen Dokumentation befasst.Entdecken Sie eine Wahrheit, die jeder ignoriert hat: Der wahre Grund für die Änderung der OP_RETURN-Richtlinie waren überhaupt nicht die Ordnungszahlen.Es ist BitVM.
Diese Geschichte ist wichtiger als die Erzählung der Ordinals.Aus dieser Perspektive hat noch nie jemand in der chinesischen und englischen Gemeinschaft darüber gesprochen.
Fallhintergrund
Im April 2024 veröffentlichte Citrea die erste vollständige BitVM-Brücke – Clementine.
Es ist das erste zkRollup auf Bitcoin, das BitVM für die L1-Verifizierung verwendet.
Dann stießen sie auf ein technisches Problem: 144 Byte Ankerdaten mussten in der Kette veröffentlicht werden.
Technische Anforderungen
Zu diesen 144 Bytes gehören:
-
128 Bytes: Groth16 Zero-Knowledge-Beweis
-
16 Bytes: Gesamte akkumulierte Arbeit (Gesamtarbeitsnachweis)
Diese Daten wurden von Watchtower verwendet, um bei der Befragung des Betreibers nachzuweisen, dass sie über die richtige Bitcoin-Kette verfügten. Hier ist das Problem: OP_RETURN erlaubt nur 83 Bytes.nicht genug.
Grundlegende technische Einschränkungen
Manche Leute fragen sich vielleicht: Warum es nicht bezeugen?Wie Ordnungszahlen?Hauptunterschied: Die nachfolgenden Validierungstransaktionen von Citrea erfordern das Lesen dieser Daten.
Bitcoin Script kann nicht auf die Zeugendaten der vorherigen Transaktion verweisen.Die Daten müssen sich also am scriptPubKey-Speicherort befinden, dies ist nicht optional.
Technische Grundlagen
Einfach ausgedrückt ist es:
Zeugendaten:
-
Es kann nur nachgewiesen werden, dass „die aktuelle Transaktion gültig ist“ ✓
-
Kann von nachfolgenden Transaktionen nicht gelesen werden ✗
scriptPubKey-Daten:
-
Kann von Skripten in nachfolgenden Transaktionen referenziert werden ✓
Die Verifizierungslogik von BitVM erfordert verkettete Referenzen, daher muss scriptPubKey verwendet werden.
erzwungener Plan
83 Bytes waren nicht genug, also war Citrea gezwungen, einen schrecklichen Ansatz zu verwenden: „unverzichtbare“ Taproot-Ausgaben zu erstellen, die die Daten als öffentliche Schlüssel tarnten.
Spezifische Methoden:
-
Ausgabe 0: OP_1 <Die ersten 32 Bytes werden als öffentlicher Schlüssel getarnt>
-
Ausgabe 1: OP_1 <32 Bytes getarnt als öffentlicher Schlüssel>
-
Ausgabe 2: OP_RETURN <80 verbleibende Bytes>
Diese „öffentlichen Schlüssel“ haben überhaupt keine entsprechenden privaten Schlüssel.Es wird niemals ausgegeben.
Gefahrenanalyse
Das Problem bei dieser Lösung: das UTXO-Set dauerhaft aufzublasen.
Jede WatchtowerChallenge-Transaktion erstellt zwei UTXOs, die niemals bereinigt werden können.Alle Full Nodes müssen diese „gefälschten öffentlichen Schlüssel“ dauerhaft speichern.Dies ist genau das Worst-Case-Szenario, das die Core-Entwickler zu vermeiden versucht haben.
Originaltext der Mailingliste
Antoine Poinsot schrieb in dem Vorschlag deutlich:
„Clementine verwendet nicht entbehrliche Taproot-Ausgaben zum Speichern von Daten … aufgrund der Größenbeschränkungen von OP_RETURN“
Dieser Fall löst **direkt** den OP_RETURN-Richtlinienänderungsvorschlag aus.Ursprüngliche E-Mail.
Logik des Entwicklers
Denkkette der Kernentwickler:
-
Aktuelle Situation: Citrea verwendet gefälschtes UTXO (schlecht)
-
Zukunft: Weitere BitVM-Projekte werden diesem Beispiel folgen
-
Oder: Sie verwenden nackte Multisignaturen (wie das Stamp-Protokoll).
-
Fazit: Es ist besser, OP_RETURN loszulassen und einen „weniger schädlichen“ Pfad bereitzustellen
Dies ist eine Strategie zur Schadensminderung.
Die strategische Position von BitVM
Warum ist Core bereit, den Weg für BitVM zu ebnen?Denn BitVM ist eine wichtige Richtung der Bitcoin-L1-Innovation.
Adam Back, CEO von Blockstream, sagte: „Der Ankermechanismus von BitVM ist eine wichtige Richtung von L1.“
Wenn sich das BitVM-Ökosystem entwickelt:
-
Verschiedene zkRollups
-
Kreuzkettenbrücken
-
Komplexe On-Chain-Verifizierung
Es wird ähnliche Verankerungsbedürfnisse geben.
Der wesentliche Unterschied zu Ordinalzahlen
Ordinalzahlen vs. BitVM-Ankerdaten:
Ordnungszahlen:
-
Standort: Zeuge (kann beschnitten werden)
-
Motiv: Spekulation/Kunst
-
Eigenschaften: Kann verblassen
BitVM-Anker:
-
Speicherort: scriptPubKey (muss dauerhaft sein)
-
Motivation: Sicherheitsbedürfnisse der Infrastruktur
-
Merkmale: Langfristiger Wachstumsbedarf
Völlig anderes technisches Szenario.
Fazit
Daher ist die OP_RETURN-Richtlinienänderung von Bitcoin Core v30 keine Kapitulation gegenüber Ordinals, sondern ein aktiver Leitfaden für das BitVM-Ökosystem; Es ist keine passive Reaktion auf Spekulationen, sondern eine Möglichkeit, den Weg für technologische Innovationen im Voraus zu ebnen.Das ist zukunftsorientiertes Denken von Core-Entwicklern.
Daher lag der Fokus von Core nie auf JPEG, sondern:
-
Den Weg für zukünftige VMs ebnen (BitVM/Simplicity/Covenants)
-
Bereinigen Sie die Sonderregeln, die vor über zehn Jahren übrig geblieben sind, damit sich das System weiterentwickeln kann
-
Vermeiden Sie, dass die politische Ebene zu einem „unsichtbaren Konsens“ wird, der Innovationen einschränkt
Wenn Sie diese beherrschen, werden Sie die technische Richtung von Bitcoin in den nächsten zehn Jahren verstehen.Es handelt sich nicht nur um einen Wortkrieg zwischen Ordinalzahlen und Knoten, sondern um ein wahres Verständnis der Logik der technologischen Evolution.







