TL; DR

Vorstellung:

Dieser Artikel bietet eine Interpretation des BitVM-Whitepapers und erläutert den Ansatz von BitVM: Daten müssen zunächst nicht auf der Kette sein; es wird außerhalb der Blockchain veröffentlicht und gespeichert, wobei nur ein Commitment auf der Blockchain gespeichert ist.

Weitergeleiteter Original-Artikeltitel: Eine vereinfachte Interpretation von BitVM: Wie man Betrugsnachweise auf der BTC-Blockchain verifiziert (EVM oder andere VM-Opcodes ausführen)

Vorwort: Derzeit ist Bitcoin Layer 2 zu einem Trend geworden, mit Dutzenden von Projekten, die sich selbst als "Bitcoin Layer 2" identifizieren. Viele von ihnen, die behaupten, "Rollups" zu sein, geben an, dass sie den im BitVM-Whitepaper vorgeschlagenen Ansatz verwenden und BitVM als prominenten Teil des Bitcoin-Ökosystems positionieren.

Der größte Teil der vorhandenen Literatur zu BitVM erklärt jedoch seine Prinzipien nicht in laienverständlichen Worten. Dieser Artikel, der auf unserer Lektüre des 8-seitigen BitVM-Whitepapers und nach der Konsultation von Ressourcen zu Taproot, MAST-Bäumen und Bitcoin Script basiert, bietet eine vereinfachte Zusammenfassung. Um das Verständnis zu erleichtern, haben wir einige Ausdrücke aus dem BitVM-Whitepaper geändert, vorausgesetzt, der Leser verfügt über einige Kenntnisse von Layer 2 und kann die Grundidee der "Betrugsnachweise" verstehen.

Das vorläufige Konzept von BitVM lässt sich in wenigen Sätzen zusammenfassen: Es eliminiert die Notwendigkeit von Daten auf der Kette, indem Daten zunächst außerhalb der Kette veröffentlicht und gespeichert werden, wobei nur eine Verpflichtung auf der Blockchain gespeichert wird. Im Falle von Anfechtungen oder Betrugsbeweisen werden nur die notwendigen Daten auf die Blockchain gebracht, um ihre Verbindung mit der Verpflichtung auf der Blockchain nachzuweisen. Anschließend überprüft das BTC-Mainnet die On-Chain-Daten auf Probleme und ob der Datenproduzent (der Knoten, der die Transaktionen verarbeitet) an böswilligen Aktivitäten beteiligt ist. Dieser Ansatz hält sich an Ockhams Razor-Prinzip – "Entitäten sollten nicht unnötig multipliziert werden" (wenn es Off-Chain sein kann, halte es außerhalb der Kette).

Haupttext: Das sogenannte BTC-Blockchain-Betrugssicherungsschema auf Basis von BitVM, laienhaft ausgedrückt:

1. Erstens ist ein Computer/Prozessor ein Eingabe-Ausgabe-System, das aus einer großen Anzahl von Logikgatterschaltungen besteht. Eine der Kernideen von BitVM ist die Verwendung von Bitcoin Script, um die Input-Output-Effekte von Logikgatterschaltungen zu simulieren. Solange die Logikgatterschaltungen simuliert werden können, kann theoretisch eine Turingmaschine erreicht werden, die alle berechenbaren Aufgaben erfüllt. Das bedeutet, dass Sie, wenn Sie über genügend Ressourcen und Arbeitskräfte verfügen, ein Team von Ingenieuren zusammenstellen können, um zunächst die Logikgatterschaltungen mit dem rudimentären Bitcoin Script-Code zu simulieren und dann eine große Anzahl von Logikgatterschaltungen zu verwenden, um die Funktionalitäten von EVM oder WASM zu implementieren.

(Dieser Screenshot stammt aus einem Lernspiel: "Turing Complete", bei dem der Kerninhalt darin besteht, einen kompletten CPU-Prozessor zu bauen, insbesondere unter Verwendung von Logikgatterschaltungen wie NAND-Gattern.)

Einige haben den Ansatz von BitVM mit dem Bau eines M1-Prozessors in "Minecraft" unter Verwendung von Redstone-Schaltkreisen verglichen. Oder es ist so, als würde man das Empire State Building in New York mit LEGO-Steinen bauen.

(Es heißt, dass jemand ein Jahr damit verbracht hat, einen "Prozessor" in "Minecraft" zu bauen.)

1. Warum also Bitcoin Script verwenden, um EVM oder WASM zu simulieren? Ist das nicht sehr umständlich? Der Grund dafür ist, dass die meisten Bitcoin-Layer-2-Lösungen oft Hochsprachen wie Solidity oder Move unterstützen, während die einzige Sprache, die derzeit direkt auf der Bitcoin-Blockchain ausgeführt werden kann, Bitcoin Script ist. Diese Sprache ist primitiv, besteht aus einem Haufen einzigartiger Opcodes und ist nicht Turing-vollständig.

(Ein Beispiel für Bitcoin Script-Code)

Wenn Bitcoin Layer 2 darauf abzielt, Betrugsbeweise auf Layer 1 zu verifizieren, wie die Layer-2-Lösungen von Ethereum wie Arbitrum, um die Sicherheit von BTC weitgehend zu erben, muss es "eine umstrittene Transaktion" oder "einen umstrittenen Opcode" direkt auf der BTC-Blockchain verifizieren. Das bedeutet, dass die von Layer 2 verwendeten Solidity-Sprach-/EVM-Opcodes auf der Bitcoin-Blockchain neu ausgeführt werden müssen. Die Herausforderung läuft auf Folgendes hinaus:

Verwendung von Bitcoin Script, einer nativen, aber rudimentären Programmiersprache von Bitcoin, um die Effekte von EVM oder anderen virtuellen Maschinen zu erzielen.

Aus der Perspektive der Kompilierungsprinzipien übersetzt der BitVM-Ansatz daher EVM/WASM/JavaScript-Opcodes in Bitcoin-Script-Opcodes, wobei Logikgatterschaltungen als Zwischenrepräsentation (IR) zwischen "EVM-Opcodes – > Bitcoin-Script-Opcodes" dienen.

(Das BitVM-Whitepaper diskutiert den allgemeinen Ansatz zur Ausführung bestimmter "umstrittener Anweisungen" auf der Bitcoin-Blockchain)

Wie auch immer, der ultimative simulierte Effekt besteht darin, Anweisungen, die ursprünglich nur auf EVM / WASM verarbeitet werden konnten, direkt auf der Bitcoin-Blockchain zu verarbeiten. Obwohl diese Lösung machbar ist, besteht die Schwierigkeit darin, eine große Anzahl von Logikgatterschaltungen als Zwischenform zu verwenden, um alle EVM/WASM-Opcodes auszudrücken. Darüber hinaus kann die Verwendung von Kombinationen von Logikgatterschaltungen zur direkten Darstellung einiger extrem komplexer Transaktionsverarbeitungsabläufe zu einer enormen Arbeitsbelastung führen.

1. Lassen Sie uns ein weiteres Kernkonzept besprechen, das im BitVM-Whitepaper erwähnt wird, nämlich die "Interactive Fraud Proofs", die denen von Arbitrum sehr ähnlich sind.

Interaktive Betrugsnachweise beinhalten einen Begriff, der als Assert bekannt ist. In der Regel veröffentlicht der Vorschlagende von Schicht 2 (oft von einem Sequenzer ausgeführt) eine Assertion auf Schicht 1, in der er erklärt, dass bestimmte Transaktionsdaten und Zustandsübergangsergebnisse gültig und fehlerfrei sind.

Wenn jemand der Meinung ist, dass die vom Antragsteller eingereichte Behauptung problematisch ist (zugehörige Daten sind falsch), kommt es zu einem Streitfall. Zu diesem Zeitpunkt tauschen der Antragsteller und der Herausforderer in Runden Informationen aus und verwenden eine binäre Suchmethode für die strittigen Daten, um schnell eine sehr feinkörnige Bedienungsanweisung und das zugehörige Datensegment zu finden.

Für diese umstrittene Betriebsanweisung (OP-Code) ist es notwendig, sie zusammen mit ihren Eingabeparametern direkt auf Layer 1 auszuführen und das Ausgabeergebnis zu validieren (Layer-1-Knoten vergleichen das von ihnen berechnete Ausgabeergebnis mit dem zuvor vom Antragsteller veröffentlichten Ausgabeergebnis). In Arbitrum wird dies als "Single-Step Fraud Proofs" bezeichnet. (Im interaktiven Betrugssicherungsprotokoll von Arbitrum wird die binäre Suche verwendet, um die umstrittene Anweisung und ihr Ausführungsergebnis schnell zu finden, und dann wird ein einstufiger Betrugsnachweis zur endgültigen Überprüfung an Layer 1 gesendet).

Daran anknüpfend:

1. Der Prozess ist interaktiv, beide Parteien wechseln sich ab. Eine Partei segmentiert die historischen Daten, die in einem Rollup-Block enthalten sind, und die andere Partei weist darauf hin, welches Datensegment problematisch ist. Dies ist vergleichbar mit einer binären Methode (in Wirklichkeit ein Prozess der schrittweisen Eingrenzung des Bereichs, N/K).

2. Anschließend ist es möglich, weiter zu lokalisieren, welche Transaktion und welches Ergebnis problematisch sind, und dann weiter auf eine bestimmte Maschinenanweisung innerhalb dieser Transaktion einzugrenzen, die umstritten ist.

3. Der ChallengeManager-Vertrag prüft lediglich, ob das durch die Unterteilung der Originaldaten erzeugte "Datensegment" gültig ist.

4. Sobald der Herausforderer und der Herausgeforderte die anzufechtende Maschinenanweisung gefunden haben, ruft oneStepProveExecution()der Herausforderer auf und sendet einen einstufigen Betrugsbeweis, um zu zeigen, dass es ein Problem mit dem Ausführungsergebnis dieser Maschinenanweisung gibt.

(Im interaktiven Betrugssicherungsprotokoll von Arbitrum beinhaltet der Prozess die Verwendung einer binären Suche, um die umstrittene Anweisung und ihr Ausführungsergebnis schnell aus den vom Antragsteller veröffentlichten Daten zu finden. Nach der Identifizierung der umstrittenen Daten oder des Opcodes wird ein einstufiger Betrugsnachweis zur endgültigen Überprüfung an Layer 1 gesendet.)

Referenzen:

Ehemaliger technischer Botschafter von Arbitrum erklärt die Komponentenstruktur von Arbitrum (Teil 1)

(Arbitrums interaktives Betrugssicherungs-Flussdiagramm, die Erklärung ist relativ grob)

An diesem Punkt wird das Konzept der einstufigen Betrugsnachweise recht einfach: Die überwiegende Mehrheit der Transaktionsanweisungen, die auf Layer 2 auftreten, müssen nicht erneut auf der BTC-Blockchain verifiziert werden. Wenn jedoch ein bestimmtes umstrittenes Datensegment/Opcode angefochten wird, muss es auf Layer 1 wiedergegeben werden.

Wenn das Verifizierungsergebnis darauf hindeutet, dass die zuvor vom Antragsteller veröffentlichten Daten problematisch sind, werden die eingesetzten Vermögenswerte des Antragstellers gekürzt. Wenn sich herausstellt, dass der Herausforderer schuld ist, wird das eingesetzte Vermögen des Herausforderers gekürzt. Prüfer, die nicht rechtzeitig auf Herausforderungen reagieren, können ebenfalls gekürzt werden.

Arbitrum implementiert die oben genannten Effekte durch Verträge auf Ethereum, während BitVM darauf abzielt, eine ähnliche Funktionalität mit Bitcoin Script zu erreichen, um Zeitsperren, Multisig und andere Funktionen zu implementieren.

4. Nachdem wir "Interaktive Betrugsnachweise" und "Einstufige Betrugsnachweise" besprochen haben, werden wir über MAST-Bäume und Merkle-Beweise sprechen. Wir haben bereits erwähnt, dass in der BitVM-Lösung die große Menge an Transaktionsdaten und Logikgatterschaltungen, die außerhalb der Kette auf Layer 2 verarbeitet werden, nicht direkt auf die Kette gelegt werden. Nur eine minimale Menge an Daten-/Logikgatterschaltungen wird bei Bedarf in die Kette gelegt. Wir brauchen jedoch einen Weg, um zu beweisen, dass diese Daten, die ursprünglich außerhalb der Kette waren und jetzt auf die Kette gestellt werden müssen, nicht fabriziert sind. Hier kommt das Konzept des Commitments in der Kryptographie ins Spiel, und Merkle Proof ist eine Form eines solchen Commitments.

Lassen Sie uns zunächst über MAST-Bäume sprechen. Der vollständige Name von MAST ist Merkelized Abstract Syntax Trees, die eine Transformation von AST (Abstract Syntax Trees) aus dem Bereich der Compilerprinzipien in Merkle-Bäume sind. Also, was ist ein AST? Einfach ausgedrückt handelt es sich um eine baumartige Datenstruktur, die einen komplexen Befehl durch lexikalische Analyse in eine Reihe grundlegender Operationseinheiten zerlegt.

(Ein Beispiel für eine AST-Struktur wäre die Aufschlüsselung einfacher Berechnungen wie "x=2, y=x*3" in zugrunde liegende Vorgangscodes und Daten. )

Der MAST-Baum ist also das Ergebnis der Anwendung von Merkleisierung auf einen AST-Baum, der Merkle-Proofs unterstützt. Ein Vorteil von Merkle-Bäumen ist ihre Fähigkeit, Daten effizient zu "komprimieren". Wenn Sie beispielsweise bei Bedarf ein Datensegment aus dem Merkle-Baum auf der BTC-Blockchain veröffentlichen und gleichzeitig glaubhaft machen möchten, dass dieses Datensegment wirklich auf dem Merkle-Baum existiert und nicht willkürlich ausgewählt wurde, was tun Sie?

Sie zeichnen einfach die Wurzel des Merkle-Baums im Voraus auf der Blockchain auf. In Zukunft reicht es aus, einen Merkle-Beweis vorzulegen, der beweist, dass ein Datenelement im Merkle-Baum existiert, das der Wurzel entspricht.

(Die Beziehung zwischen Merkle Proof/Branch und Root)

Daher ist es nicht erforderlich, den kompletten MAST-Baum auf der BTC-Blockchain zu speichern. es reicht aus, seine Wurzel im Voraus als Verpflichtung offenzulegen. Bei Bedarf ist die Darstellung des Datensegments + Merkle Proof/Branch ausreichend. Dies reduziert die Datenmenge auf der Kette erheblich und stellt gleichzeitig sicher, dass die On-Chain-Daten wirklich im MAST-Baum vorhanden sind. Darüber hinaus kann die Offenlegung nur eines kleinen Teils der Datensegmente + Merkle Proof auf der BTC-Blockchain anstelle aller Daten den Schutz der Privatsphäre erheblich verbessern.

Referenzen:Datenvorbehalt und Betrugssicherheit: Warum Plasma keine Smart Contracts unterstützt

(Beispiel für einen MAST-Baum)

In der Lösung von BitVM werden alle Logikgatterschaltungen mithilfe von Bitcoin-Skripten ausgedrückt, die in einem massiven MAST-Baum organisiert sind. Die unteren Blätter dieses Baumes, die im Diagramm als Inhalt gekennzeichnet sind, entsprechen den Logikgatterschaltungen, die in der Bitcoin-Schrift implementiert sind. Der Proposer von Layer 2 veröffentlicht häufig die Wurzel des MAST-Baums auf der BTC-Blockchain, wobei jeder MAST-Baum mit einer Transaktion verbunden ist, die alle seine Eingangsparameter/Betriebscodes/Logikgatterschaltungen umfasst. Dies ist in gewisser Weise vergleichbar mit der Veröffentlichung von Rollup-Blöcken auf der Ethereum-Blockchain durch Arbitrum's Proposer.

Wenn es zu einem Streitfall kommt, erklärt ein Herausforderer auf der BTC-Blockchain, welche Wurzel er herausfordern möchte, und bittet dann den Antragsteller, ein bestimmtes Datensegment offenzulegen, das der Wurzel entspricht. Anschließend legt der Antragsteller einen Merkle-Beweis vor, der kontinuierlich kleine Segmente der Daten des MAST-Baums on-chain offenlegt, bis die umstrittene Logikgatterschaltung gemeinsam mit dem Herausforderer lokalisiert wird. Danach kann ein Slash ausgeführt werden.

(Quelle:https://medium.com/crypto-garage/deep-dive-into-bitvm-computing-paradigm-to-express-turing-complete-bitcoin-contracts-1c6cb05edfca)

1. Bis zu diesem Zeitpunkt wurden die wichtigsten Aspekte der BitVM-Lösung weitgehend abgedeckt. Obwohl einige Details noch etwas unklar sind, wird angenommen, dass die Leser das Wesen und die Hauptpunkte von BitVM erfassen können. In Bezug auf die in seinem Whitepaper erwähnte "Bitwertverpflichtung" soll verhindert werden, dass ein Vorschlagender den Eingangswerten eines Logikgatters sowohl 0 als auch 1 zuweist, wenn er aufgefordert und gezwungen wird, die Logikgatterschaltung auf der Kette zu verifizieren, wodurch Mehrdeutigkeit und Verwirrung entstehen.

Zusammenfassend lässt sich sagen, dass das BitVM-Schema mit der Verwendung von Bitcoin-Skripten beginnt, um Logikgatterschaltungen auszudrücken, diese Schaltkreise dann verwendet, um die Opcodes der EVM/anderen VMs auszudrücken, die wiederum den Verarbeitungsfluss einer bestimmten Transaktionsanweisung ausdrücken, und diese schließlich in einem Merkle-Baum/MAST-Baum organisiert. Wenn der Transaktionsverarbeitungsfluss, der durch einen solchen Baum dargestellt wird, sehr komplex ist, kann er leicht 100 Millionen Blätter überschreiten, daher ist es wichtig, den Blockplatz, der von Verpflichtungen belegt wird, und den Umfang, der von Betrugsnachweisen betroffen ist, zu minimieren.

Obwohl ein einstufiger Betrugsnachweis nur eine sehr geringe Datenmenge und ein Logikgatter-Skript on-chain benötigt, muss der komplette Merkle-Baum über einen langen Zeitraum off-chain gespeichert werden, damit jederzeit on-chain darauf zugegriffen werden kann, wenn jemand ihn in Frage stellt. Jede Transaktion in einer Schicht 2 erzeugt einen großen Merkle-Baum, und man kann sich den Rechen- und Speicherdruck auf die Knoten vorstellen. Die meisten Leute möchten vielleicht keine Nodes betreiben (solche historischen Daten können jedoch auslaufen, und das B^2-Netzwerk führt speziell zk-storage proofs ähnlich wie Filecoin ein, um Anreize für Storage Nodes zu schaffen, historische Daten langfristig zu speichern).

Optimistische Rollups, die auf Betrugsbeweisen basieren, benötigen jedoch nicht zu viele Knoten, da ihr Vertrauensmodell 1/N ist, was bedeutet, dass das Layer-2-Netzwerk sicher ist, solange einer der N-Knoten ehrlich ist und in einem kritischen Moment einen Betrugsnachweis einleiten kann.

Dennoch gibt es viele Herausforderungen beim Design von Layer-2-Lösungen auf Basis von BitVM, wie zum Beispiel:

1) Um Daten weiter zu komprimieren, ist es theoretisch nicht notwendig, Opcodes direkt auf Layer 1 zu verifizieren. Der Verarbeitungsfluss von Opcodes kann weiter in einen zk-proof komprimiert werden, so dass Herausforderer die Verifizierungsschritte des zk-proof anfechten können. Dadurch könnte die Datenmenge auf der Kette deutlich reduziert werden. Die spezifischen Entwicklungsdetails können jedoch sehr komplex sein.

2) Antragsteller und Herausforderer müssen wiederholt Interaktionen außerhalb der Kette generieren. Wie das Protokoll gestaltet werden soll und wie der Commitment- und Challenge-Prozess im Verarbeitungsablauf weiter optimiert werden soll, erfordert viel intellektuellen Aufwand.

Verzichtserklärung:

1. Dieser Artikel ist ein Nachdruck von [Geek Web3], Forward the Original Title "A minimalist interpretation of BitVM: How to verify fraud proof on the BTC chain (execute the operation code of EVM or other VM)", das Urheberrecht liegt beim ursprünglichen Autor [Faust & Misty Moon]
   . Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an das Gate Learn-Team , das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verbreiten oder Plagiieren der übersetzten Artikel verboten.