Da es in der chinesischen Community an einer professionellen Interpretation von Artikeln oder Materialien im Zusammenhang mit Layer2-Protokollen, insbesondere für Arbitrum und OP Rollup, mangelt, soll dieser Artikel diese Lücke schließen, indem er den Funktionsmechanismus von Arbitrum erläutert. Aufgrund der Komplexität von Arbitrum selbst umfasst der vollständige Text, selbst nachdem er so weit wie möglich vereinfacht wurde, immer noch mehr als 10.000 Wörter. Daher ist es in zwei Teile gegliedert und es wird empfohlen, es als Referenzmaterial zu speichern und weiterzugeben.“

Übersicht über den Rollup-Sequenzer

Das Prinzip der Rollup-Skalierung lässt sich in zwei Punkten zusammenfassen:

Kostenoptimierung: Verlagerung der meisten Rechen- und Speicheraufgaben auf Layer 2, der unter L1 betrieben wird. L2 läuft meist auf einem einzelnen Server, der als Sequenzer/Operator bezeichnet wird, und bildet eine separate Kette.

Der Sequenzer erscheint in Bezug auf die Wahrnehmung fast wie ein zentralisierter Server, der die Dezentralisierung in der „unmöglichen Dreifaltigkeit der Blockchain“ aufgibt, um Vorteile bei TPS und Kosten zu erzielen. Benutzer können L2 anstelle von Ethereum zur Abwicklung von Transaktionsanweisungen verwenden, wobei die Kosten im Vergleich zu Transaktionen auf Ethereum deutlich geringer sind.

(Quelle: BNB Chain)

Sicherheitsgarantie: Transaktionsinhalte und Post-Transaktionsstatus auf L2 werden mit Ethereum L1 synchronisiert und ihre Gültigkeit wird durch Verträge für den Statusübergang überprüft. Gleichzeitig behält Ethereum den Verlauf von L2 bei, sodass andere den gesamten Zustand von L2 mithilfe von Ethereum-Datensätzen rekonstruieren können, selbst wenn der Sequenzer dauerhaft abstürzt.

Grundsätzlich hängt die Sicherheit von Rollup von Ethereum ab. Wenn der Sequenzer den privaten Schlüssel eines Kontos nicht kennt, kann er keine Transaktionen im Namen dieses Kontos initiieren oder den Kontostand manipulieren (selbst wenn es versucht würde, würde dies schnell erkannt werden).

Während der Sequencer als zentraler Knotenpunkt einen zentralisierten Aspekt hat, kann der zentralisierte Sequencer in ausgereiften Rollup-Lösungen nur sanfte böswillige Aktivitäten wie Transaktionszensur oder böswillige Abstürze durchführen. In einem idealen Rollup-Szenario gibt es entsprechende Maßnahmen, um solche Aktionen einzudämmen, wie z. B. Zwangsabhebungen oder Sequenzierungsnachweise für Anti-Zensur-Mechanismen.

(Das Loopring-Protokoll legt im Vertragsquellcode auf L1 eine erzwungene Auszahlungsfunktion fest, die Benutzer aufrufen können.)

Die Statusüberprüfungsmechanismen zur Verhinderung böswilliger Aktionen durch Rollup-Sequenzer sind in zwei Kategorien unterteilt: Betrugsnachweis und Gültigkeitsnachweis. Rollup-Lösungen, die Fraud Proof verwenden, werden als OP Rollup (Optimistic Rollup, OPR) bezeichnet, während diejenigen, die Validity Proof verwenden, aufgrund des historischen Ballasts häufig als ZK Rollup (Zero-knowledge Proof Rollup, ZKR) und nicht als Validity Rollup bezeichnet werden.

Arbitrum One ist ein typischer OPR, der auf L1 mit Verträgen eingesetzt wird, die die übermittelten Daten nicht aktiv validieren, wobei optimistisch davon ausgegangen wird, dass die Daten korrekt sind. Wenn in den übermittelten Daten ein Fehler vorliegt, initiieren L2-Validierungsknoten aktiv eine Herausforderung.

Daher impliziert OPR eine Vertrauensannahme: Zu jedem Zeitpunkt gibt es mindestens einen ehrlichen L2-Validatorknoten. Andererseits validieren ZKR-Verträge aktiv und kostengünstig die vom Sequenzer übermittelten Daten durch kryptografische Berechnungen.

(Optimistische Rollup-Operationsmethode)

(ZK-Rollup-Betriebsmethode)

Dieser Artikel bietet eine ausführliche Einführung in das führende Projekt in Optimistic Rollup – Arbitrum One, und deckt alle Aspekte des gesamten Systems ab. Nach sorgfältiger Lektüre verfügen Sie über ein umfassendes Verständnis von Arbitrum und Optimistic Rollup/OPR.

Kernkomponenten und Arbeitsablauf von Arbitrum

Kernverträge:

Zu den wichtigsten Verträgen in Arbitrum gehören SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge usw. Diese werden in den folgenden Abschnitten detailliert beschrieben.

Sequenzer:

Der Sequenzer empfängt Benutzertransaktionen, sortiert sie, berechnet die Transaktionsergebnisse und sendet die Belege schnell (normalerweise <1 s) an die Benutzer zurück. Benutzer sehen ihre Transaktionen auf L2 oft innerhalb weniger Sekunden, was ein ähnliches Erlebnis wie bei Web2-Plattformen bietet.

Gleichzeitig sendet der Sequenzer sofort den zuletzt generierten L2-Block unter Ethereum außerhalb der Kette. Jeder Layer2-Knoten kann diese L2-Blöcke asynchron empfangen. Allerdings sind diese L2-Blöcke zu diesem Zeitpunkt noch nicht endgültig und können vom Sequenzer zurückgesetzt werden.

Alle paar Minuten komprimiert der Sequenzer die sortierten L2-Transaktionsdaten, aggregiert sie in Stapeln und übermittelt sie an den SequencerInbox-Vertrag auf Layer1, um die Datenverfügbarkeit und den Betrieb des Rollup-Protokolls sicherzustellen. Im Allgemeinen können an Layer1 übermittelte L2-Daten nicht zurückgesetzt werden und können endgültigen Determinismus haben.

Aus dem obigen Prozess können wir zusammenfassen: Layer2 verfügt über ein eigenes Knotennetzwerk, aber die Anzahl dieser Knoten ist gering und es gibt im Allgemeinen kein Konsensprotokoll, das üblicherweise von öffentlichen Ketten verwendet wird, sodass die Sicherheit sehr gering ist. Es muss sich auf Ethereum verlassen, um die Zuverlässigkeit der Datenfreigabe und die Wirksamkeit von Zustandsübergängen sicherzustellen. Sex.

Arbitrum-Rollup-Protokoll:

Dabei handelt es sich um eine Reihe von Verträgen, die die Struktur des Block-RBlocks der Rollup-Kette, die Fortsetzungsmethode der Kette, die Freigabe von RBlock und den Challenge-Modus-Prozess definieren. Beachten Sie, dass es sich bei der hier erwähnten Rollup-Kette nicht um das Layer-2-Ledger handelt, das jeder versteht, sondern um eine abstrakte „kettenartige Datenstruktur“, die unabhängig von Arbitrum One eingerichtet wurde, um den betrugssicheren Mechanismus zu implementieren.

Ein RBlock kann die Ergebnisse mehrerer L2-Blöcke enthalten und auch die Daten sind sehr unterschiedlich. Seine Datenentität RBlock wird in einer Reihe von Verträgen in RollupCore gespeichert. Wenn es ein Problem mit einem RBlock gibt, fordert der Validator den Einreicher des RBlocks heraus.

Validator:

Die Validator-Knoten von Arbitrum sind eigentlich eine spezielle Teilmenge der vollständigen Layer-2-Knoten und haben derzeit Zugriff auf eine Whitelist.

Der Validator erstellt einen neuen RBlock (Rollup-Block, auch Assertion genannt) basierend auf dem vom Sequenzer an den SequencerInbox-Vertrag übermittelten Transaktionsstapel, überwacht den Status der aktuellen Rollup-Kette und stellt die vom Sequenzer übermittelten falschen Daten in Frage.

Active Validator muss im Voraus Vermögenswerte in der ETH-Kette einsetzen. Manchmal nennen wir es auch Staker. Obwohl Layer-2-Knoten, die nicht beteiligt sind, auch die Betriebsdynamik von Rollup überwachen und abnormale Alarme an Benutzer senden können, können sie nicht direkt auf die vom Sequenzer in der ETH-Kette übermittelten Fehlerdaten eingreifen.

Herausforderung:

Die grundlegenden Schritte können als mehrere Runden interaktiver Segmentierung und einstufiger Beweis zusammengefasst werden. Im Segmentierungsprozess führen die herausfordernden Parteien zunächst mehrere Segmentierungsrunden für die problematischen Transaktionsdaten durch, bis sie die problematischen Operationscodeanweisungen zerlegen und eine Überprüfung durchführen. Das Paradigma der „mehreren Runden der Segmentierung – einstufiger Beweis“ wird von den Arbitrum-Entwicklern als die energiesparendste Implementierung des Betrugsnachweises angesehen. Alle Links unterliegen der Vertragskontrolle und keine Partei kann betrügen.

Challenge-Zeitraum:

Aufgrund des optimistischen Charakters von OP Rollup wird der Vertrag nach der Übermittlung jedes RBlocks an die Kette nicht aktiv geprüft, so dass dem Verifizierer ein Zeitfenster zur Fälschung verbleibt. Dieser Fensterzeitraum ist der Herausforderungszeitraum, der im Hauptnetzwerk von Arbitrum One eine Woche dauert. Nach Ablauf des Herausforderungszeitraums wird der RBlock endgültig bestätigt. Nur die entsprechenden Nachrichten, die innerhalb des Blocks von L2 an L1 weitergeleitet werden (z. B. über die offizielle Brücke durchgeführte Auszahlungsvorgänge), können freigegeben werden.

ArbOS, Geth, WAVM:

Die von Arbitrum verwendete virtuelle Maschine heißt AVM und umfasst Geth und ArbOS. Geth ist die am häufigsten verwendete Client-Software in Ethereum und Arbitrum hat geringfügige Änderungen daran vorgenommen. ArbOS ist für alle L2-bezogenen Sonderfunktionen verantwortlich, wie z. B. Netzwerkressourcenverwaltung, Generieren von L2-Blöcken, Arbeiten mit EVM usw. Wir betrachten die Kombination der beiden als Native AVM, also die von Arbitrum verwendete virtuelle Maschine. WAVM ist das Ergebnis der Kompilierung von AVM-Code in Wasm. Im Arbitrum-Challenge-Prozess überprüft der letzte „One-Step-Proof“ die WAVM-Anweisung.

Hier können wir die folgende Abbildung verwenden, um die Beziehung und den Arbeitsablauf zwischen den oben genannten Komponenten darzustellen:

Transaktionslebenszyklus auf L2

Der Verarbeitungsablauf einer Transaktion auf L2 ist wie folgt:

1. Benutzer senden Handelsanweisungen an den Sequenzer.

2. Der Sequenzer überprüft zunächst die Transaktionen, die in digitale Signaturen und andere Daten verarbeitet werden sollen, eliminiert ungültige Transaktionen und führt Sequenzen und Berechnungen durch.

3. Der Sequenzer sendet den Transaktionsbeleg an den Benutzer (normalerweise sehr schnell), was lediglich die „Vorverarbeitung“ darstellt, die vom Sortierer unter der ETH-Kette durchgeführt wird. Es befindet sich im Zustand „Soft Finality“ und ist nicht zuverlässig. Aber Benutzer (die meisten Benutzer), die dem Sequenzer vertrauen, können optimistisch sein, dass die Transaktion abgeschlossen wurde und nicht zurückgesetzt wird.

4. Der Sequenzer komprimiert die vorverarbeiteten ursprünglichen Transaktionsdaten stark und kapselt sie in einen Batch.

5. Von Zeit zu Zeit (beeinflusst durch Faktoren wie Datenvolumen und ETH-Überlastung) veröffentlicht der Sequenzer Transaktionsstapel im Sequencer Inbox-Vertrag auf L1. An diesem Punkt kann davon ausgegangen werden, dass die Transaktion eine harte Endgültigkeit aufweist.

Sequencer-Posteingangsvertrag

Der Vertrag erhält den vom Sequenzer übermittelten Transaktionsstapel, um die Datenverfügbarkeit sicherzustellen. Wenn wir dies genauer betrachten, zeichnen die Stapeldaten im Sequencer Inbox die Transaktionseingabeinformationen von Layer2 vollständig auf. Selbst wenn der Sequenzer dauerhaft ausgefallen ist, kann jeder anhand des Chargenprotokolls den aktuellen Zustand von Layer 2 wiederherstellen und den fehlerhaften/laufenden Sequenzer ersetzen.

Um es physikalisch zu verstehen: Der L2, den wir sehen, ist nur die Projektion des Stapels in SequencerInbox und die Lichtquelle ist STF. Da sich die Lichtquelle STF nicht so leicht ändert, wird die Form des Schattens nur durch die Charge bestimmt, die als Objekt fungiert.

Der Sequencer Inbox-Vertrag wird als Fast Box bezeichnet. Der Sequenzer übermittelt ihm gezielt vorverarbeitete Transaktionen, und nur der Sequenzer kann ihm Daten übermitteln. Die entsprechende schnelle Box ist die langsame Box Delayer Inbox, deren Funktion im weiteren Verlauf beschrieben wird.

Der Validator überwacht immer den Sequencer-Inbox-Vertrag. Immer wenn der Sequenzer eine Charge für den Vertrag freigibt, wird ein On-Chain-Ereignis erzeugt. Nachdem der Validator das Auftreten dieses Ereignisses erkennt, lädt er die Batch-Daten herunter. Nach der lokalen Ausführung wird RBlock an den Rollup-Protokollvertrag in der ETH-Kette ausgegeben.

Der Brückenvertrag von Arbitrum verfügt über einen Parameter namens Akkumulator, der den neu übermittelten L2-Batch sowie die Anzahl und Informationen neu empfangener Transaktionen im langsamen Posteingang aufzeichnet.

(Der Sequenzer übermittelt kontinuierlich Stapel an den Sequenzer-Posteingang.)

（Die spezifischen Informationen der Charge; Das Datenfeld entspricht den Batch-Daten. Dieser Teil der Daten ist sehr groß und der Screenshot wird nicht vollständig angezeigt.）

Der SequencerInbox-Vertrag hat zwei Hauptfunktionen:

Sequenzer L2Batch von Origin() hinzufügen

Der Sequenzer ruft diese Funktion jedes Mal auf, um Batch-Daten an den Sequencer Inox-Vertrag zu übermitteln.

erzwinge Inklusion()

Diese Funktion kann von jedem aufgerufen werden und dient der Umsetzung zensurresistenter Transaktionen. Die Wirkungsweise dieser Funktion wird später im Detail erläutert, wenn wir über den Delayed-Inbox-Vertrag sprechen.

Die beiden oben genannten Funktionen rufen „bridge.enqueueSequencerMessage()“ auf, um den Akkumulatorparameter im Bridge-Vertrag zu aktualisieren.

Gaspreise

Offensichtlich können L2-Transaktionen nicht kostenlos sein, da dies zu DoS-Angriffen führen würde. Darüber hinaus fallen Betriebskosten für den Sortierer L2 selbst an und es entsteht ein Mehraufwand für die Datenübermittlung auf L1. Wenn ein Benutzer eine Transaktion innerhalb des Layer-2-Netzwerks initiiert, sieht die Gasgebührenstruktur wie folgt aus:

Kosten für die Datenveröffentlichung, die durch die Belegung von Layer1-Ressourcen entstehen

Diese Kosten entstehen hauptsächlich durch die vom Sequenzer übermittelten Stapel (jeder Stapel hat viele Benutzertransaktionen) und die Kosten werden letztendlich zu gleichen Teilen auf die Transaktionsinitiatoren aufgeteilt. Der durch die Datenfreigabe generierte Gebührenpreisalgorithmus ist dynamisch, und der Sequenzer berechnet die Preise auf der Grundlage des aktuellen Gewinn- und Verluststatus, der Chargengröße und des aktuellen Ethereum-Gaspreises.

Die Kosten, die Benutzern entstehen, wenn sie Layer-2-Ressourcen belegen

Um den stabilen Betrieb des Systems zu gewährleisten, wird ein Gaslimit für TPS festgelegt (derzeit 7 Millionen in Arbitrum One). Die Gasrichtpreise für L1 und L2 werden von ArbOS verfolgt und angepasst, und die Formel wird hier vorerst nicht detailliert beschrieben.

Obwohl der spezifische Gaspreisberechnungsprozess relativ kompliziert ist, müssen Benutzer diese Details nicht kennen und können deutlich spüren, dass die Rollup-Transaktionsgebühren viel günstiger sind als die des ETH-Mainnets.

Optimistischer Betrugsbeweis

Unter Berücksichtigung des oben Gesagten ist L2 eigentlich nur die Projektion des vom Sequenzer in der Fast-Box übermittelten Transaktionseingabestapels, das heißt:

Transaktionseingaben -> STF -> Statusausgaben. Die Eingabe wurde bestimmt und die STF bleibt unverändert, sodass auch das Ausgabeergebnis bestimmt wird. Das System zur Betrugserkennung und zum Arbitrum-Rollup-Protokoll ist ein System, das die Ausgangszustandswurzel in Form von RBlock (auch bekannt als Assertion) an L1 veröffentlicht und darauf einen optimistischen Beweis durchführt.

Auf L1 gibt es Eingabedaten, die vom Sequenzer veröffentlicht werden, und Ausgabestatus, die vom Verifizierer veröffentlicht werden. Betrachten wir es sorgfältig: Ist es notwendig, den Status von Layer 2 in der Kette zu veröffentlichen?

Erscheint es überflüssig, den Ausgabeergebnisstatus zu übermitteln, da die Eingabe die Ausgabe vollständig bestimmt hat und die Eingabedaten öffentlich sichtbar sind? Diese Idee ignoriert jedoch die tatsächliche Notwendigkeit einer staatlichen Regelung zwischen den beiden Systemen L1 und L2, dh das Rückzugsverhalten von L2 zu L1 erfordert einen Zustandsnachweis.

Bei der Erstellung von Rollups besteht eine der Kernideen darin, den Großteil der Rechenleistung und des Speichers auf L2 zu verlagern, um die hohen Kosten von L1 zu vermeiden. Das bedeutet, dass L1 den Status von L2 nicht kennt, sondern nur L2 hilft. Der Sequenzer veröffentlicht die Eingabedaten aller Transaktionen, ist jedoch nicht für die Berechnung des Status von L2 verantwortlich.

Das Abhebungsverhalten besteht im Wesentlichen darin, die entsprechenden Gelder aus dem L1-Vertrag freizuschalten, sie auf das L1-Konto des Benutzers zu übertragen oder andere Dinge zu erledigen, indem der von L2 bereitgestellten kettenübergreifenden Nachricht gefolgt wird.

Zu diesem Zeitpunkt wird im Layer-1-Vertrag gefragt: Wie ist Ihr Status auf Layer 2 und wie können Sie nachweisen, dass Sie wirklich Eigentümer der Vermögenswerte sind, die Sie für die Übertragung angeben? Zu diesem Zeitpunkt muss der Benutzer den entsprechenden Merkle-Beweis usw. vorlegen.

Wenn wir also ein Rollup ohne Auszahlungsfunktion erstellen, ist es theoretisch möglich, den Status nicht mit L1 zu synchronisieren, und es ist kein Statusnachweissystem wie Betrugsnachweis erforderlich (obwohl dies andere Probleme verursachen kann). In realen Anwendungen ist dies jedoch offensichtlich nicht realisierbar.

Beim sogenannten optimistischen Beweis prüft der Vertrag nicht, ob der an L1 übermittelte Ausgabestatus korrekt ist, sondern geht optimistisch davon aus, dass alles korrekt ist. Das optimistische Beweissystem geht davon aus, dass es zu jedem Zeitpunkt mindestens einen ehrlichen Validator gibt. Wenn ein falscher Status auftritt, wird dieser durch einen Betrugsbeweis angefochten.

Der Vorteil dieses Designs besteht darin, dass nicht jeder an L1 ausgegebene RBlock aktiv überprüft werden muss, um Gasverschwendung zu vermeiden. Tatsächlich ist es für OPR unrealistisch, jede Behauptung zu überprüfen, da jeder Rblock einen oder mehrere L2-Blöcke enthält und jede Transaktion auf L1 erneut ausgeführt werden muss. Es unterscheidet sich nicht von der direkten Ausführung von L2-Transaktionen auf L1, wodurch die Layer-2-Erweiterung bedeutungslos wird.

ZKR hat dieses Problem nicht, da ZK Proof prägnant ist. Es muss nur ein sehr kleiner Beweis verifiziert werden, und es ist nicht erforderlich, tatsächlich viele dem Beweis entsprechende Transaktionen auszuführen. Daher agiert ZKR nicht optimistisch. Bei jeder Statusfreigabe wird ein Verifier-Vertrag zur mathematischen Verifizierung abgeschlossen.

Obwohl der Betrugsnachweis nicht so präzise sein kann wie der Zero-Knowledge-Beweis, verwendet Arbitrum einen rundenbasierten interaktiven Prozess mit „mehreren Segmentierungsrunden und einem Schritt Beweis“. Am Ende muss nur ein einziger Betriebscode einer virtuellen Maschine nachgewiesen werden, und die Kosten sind relativ gering.

Rollup-Protokoll

Werfen wir zunächst einen Blick auf den Eingang zum Initiieren von Herausforderungen und zum Starten von Beweisen, also auf die Funktionsweise des Rollup-Protokolls.

Der Kernvertrag des Rollup-Protokolls ist RollupProxy.sol. Dabei wird eine seltene Dual-Agenten-Struktur verwendet und gleichzeitig sichergestellt, dass die Datenstruktur konsistent ist. Ein Agent entspricht zwei Implementierungen von RollupUserLogic.sol und RollupAdminLogic.sol, die von Tools wie Scan nicht gut analysiert werden können.

Darüber hinaus ist der ChallengeManager.sol-Vertrag für die Verwaltung von Herausforderungen verantwortlich, und die Verträge der OneStepProver-Serie werden zur Ermittlung von Betrugsnachweisen verwendet.

(Quelle: offizielle Website von L2BEAT)

Dies zeigt die Aufzeichnung einer Reihe von RBlocks (auch Assertions genannt) in RollupProxy, die von verschiedenen Validatoren übermittelt wurden. Dies sind die Kästchen in der folgenden Abbildung: Grün bestätigt, Blau unbestätigt, Gelb verfälscht.

RBlock enthält den Endzustand nach der Ausführung eines oder mehrerer L2-Blöcke seit dem letzten RBlock. Diese RBlocks bilden eine formelle Rollup-Kette (beachten Sie, dass das L2-Ledger selbst anders ist). Unter optimistischen Umständen sollte diese Rollup-Kette keine Forks haben, da ein Fork bedeutet, dass ein Validator widersprüchliche Rollup-Blöcke übermittelt hat.

Um eine Behauptung vorzuschlagen oder ihr zuzustimmen, muss der Verifizierer zunächst einen bestimmten Betrag an ETH für die Behauptung einsetzen und ein Staker werden. Auf diese Weise werden die Sicherheiten des Verlierers gekürzt, wenn ein Anfechtungs-/Betrugsbeweis vorliegt. Dies ist die wirtschaftliche Grundlage, um das ehrliche Verhalten des Gutachters sicherzustellen.

Der blaue Block Nr. 111 in der unteren rechten Ecke des Bildes wird irgendwann durchgestrichen, weil sein übergeordneter Block Nr. 104 (gelb) falsch ist.

Darüber hinaus schlug Prüfer A den Rollup-Block Nr. 106 vor, B war jedoch anderer Meinung und focht ihn an.

Nachdem B die Herausforderung initiiert hat, ist der ChallengeManager-Vertrag für die Überprüfung der Segmentierung der Herausforderungsschritte verantwortlich:

1. Segmentierung ist ein Prozess, bei dem beide Parteien abwechselnd interagieren. Eine Partei segmentiert die in einem bestimmten Rollup-Block enthaltenen historischen Daten, und die andere Partei weist darauf hin, welcher Teil des Datenfragments problematisch ist, ein Prozess ähnlich der Dichotomie (eigentlich N/K), der den Umfang kontinuierlich und schrittweise einschränkt.

2. Danach können Sie weiterhin die problematische Transaktion und das Ergebnis lokalisieren und sie dann weiter in eine umstrittene Maschinenanweisung in der Transaktion unterteilen.

3. Der ChallengeManager-Vertrag prüft lediglich, ob die nach der Segmentierung der Originaldaten generierten „Datenfragmente“ gültig sind.

4. Wenn der Herausforderer und die herausgeforderte Partei die Maschinenanweisung finden, die angefochten werden soll, ruft der Herausforderer die Funktion „oneStepProveExecution()“ auf und sendet einen einstufigen Betrugsnachweis, um zu beweisen, dass ein Problem mit dem Ausführungsergebnis dieser Maschinenanweisung vorliegt.

Beweis in einem Schritt

Der Ein-Schritt-Beweis ist der Kern des gesamten Arbitrum-Betrugsnachweises. Werfen wir einen Blick darauf, was der Ein-Schritt-Beweis konkret beweist.

Dies erfordert zunächst ein Verständnis von WAVM. Wasm Arbitrum Virtual Machine ist eine virtuelle Maschine, die aus dem ArbOS-Modul und dem Geth-Kernmodul (Ethereum-Client) kompiliert wird. Da sich L2 stark von L1 unterscheidet, musste der ursprüngliche Geth-Kern leicht modifiziert werden und mit ArbOS funktionieren.

Daher ist der Zustandsübergang auf L2 tatsächlich die gemeinsame Arbeit von ArbOS+Geth Core.

Der Node-Client von Arbitrum (Sequencer, Verifier, Full Node usw.) kompiliert das oben genannte ArbOS+Geth Core-Verarbeitungsprogramm in nativen Maschinencode, den der Node-Host direkt verarbeiten kann (für x86/ARM/PC/Mac/usw.).

Wenn Sie die nach der Kompilierung erhaltene Zielsprache in Wasm ändern, erhalten Sie die WAVM, die der Verifizierer beim Generieren von Betrugsnachweisen verwendet, und der Vertrag zur Überprüfung des Ein-Schritt-Beweises simuliert auch die Funktionen der virtuellen WAVM-Maschine.

Warum muss es also beim Generieren von Betrugsnachweisen in Wasm-Bytecode kompiliert werden? Der Hauptgrund besteht darin, dass zur Überprüfung des Vertrags auf Betrugssicherheit in einem Schritt der Ethereum-Smart-Vertrag verwendet werden muss, um eine virtuelle Maschinen-VM zu simulieren, die einen bestimmten Satz von Befehlssätzen verarbeiten kann, und WASM einfach zu simulieren ist der Vertrag.

Allerdings läuft WASM etwas langsamer als nativer Maschinencode, sodass die Knoten/Verträge von Arbitrum WAVM nur zum Generieren und Überprüfen von Betrugsnachweisen verwenden.

Nach den vorherigen Runden der interaktiven Segmentierung bewies der einstufige Beweis schließlich die einstufige Anweisung im WAVM-Befehlssatz.

Wie im folgenden Code zu sehen ist, bestimmt OneStepProofEntry zunächst, zu welcher Kategorie der Operationscode der zu beweisenden Anweisung gehört, und ruft dann den entsprechenden Prüfer wie Mem, Math usw. auf, um die einstufige Anweisung an zu übergeben Prüfvertrag.

Das Endergebnis afterHash wird an den ChallengeManager zurückgegeben. Wenn der Hash nicht mit dem Hash nach der im Rollup-Block aufgezeichneten Befehlsoperation übereinstimmt, ist die Herausforderung erfolgreich. Wenn sie konsistent sind, bedeutet dies, dass es kein Problem mit dem Ausführungsergebnis dieser im Rollup-Block aufgezeichneten Anweisung gibt und die Herausforderung fehlgeschlagen ist.

In Teil 2 werden wir Arbitrum und sogar das Vertragsmodul analysieren, das kettenübergreifende Messaging-/Bridging-Funktionen zwischen Layer2 und Layer1 übernimmt, und weiter klären, wie ein echter Layer2 Zensurresistenz erreichen sollte.

Haftungsausschluss:

1. Dieser Artikel wurde von [WeChat] nachgedruckt. Alle Urheberrechte liegen beim ursprünglichen Autor [Luo Benben]. Wenn Sie Einwände gegen diesen Nachdruck haben, 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.