Dies ist die deutsche Community Übersetzung. Originalfassung vom 22. Oktober 2021: Hier

Dieser Artikel ist eine Zusammenfassung des Forschungsberichts — SoK: Validating Bridges as a Scaling Solution for Blockchains — geschrieben von Oasis Labs CEO und Gründerin Dawn Song, Patrick McCorry, Bennet Yee und ursprünglich veröffentlicht von Chris Buckland auf seinem Blog hier.

Rollups ermöglichen die Skalierung von Blockchains, indem sie die Ausführung in einen anderen Bereich verlagern. Die Transaktionsdaten werden auf der Main Chain gespeichert, aber nicht dort ausgeführt. Stattdessen werden sie im Rollup-Netzwerk ausgeführt, und in regelmäßigen Abständen wird ein Beitrag zum aktuellen Rollup-Status an die Main Chain zurückgesendet. Das bedeutet, dass die Nodes des Mainnets die Transaktionen nicht mehr ausführen müssen, was ihre Belastung verringert.

Aber wie kann die Main Chain davon überzeugt werden, dass der zugesagte Status des Rollups korrekt ist? Rollups gibt es in zwei verschiedenen Kategorien, die dieses Problem auf unterschiedliche Weise lösen:

zk-Rollups: Die Korrektheit der Commitments wird durch einen begleitenden Zero Knowledge Proof bewiesen.
Optimistische Rollups: Die Zusagen werden optimistisch angenommen, aber die Validatoren prüfen sie und reichen einen Fraud Proofs (Fraud Proof) ein, wenn sie eine Zusage für falsch halten. Bei optimistischen Rollups wird die Zusage auch als Behauptung bezeichnet, da der Zustand behauptet und nicht bewiesen wird.

Optimistische Rollups verlangen von den Validatoren, dass sie Zustandsübergänge überprüfen und einen Fraud Proof erbringen, wenn sie einen Betrug feststellen.

In diesem Beitrag werden wir uns nur auf optimistische Rollups und die Fraud Proofs konzentrieren, die sie sicher machen. Wir schauen uns an, wie sie derzeit von zwei beliebten optimistischen Rollups — Arbitrum und Optimism — eingesetzt werden und in welche Richtung die aktuelle Forschung zu Fraud Proofs geht.

Wenn ihr mehr über die Funktionsweise von Rollups im Allgemeinen erfahren wollt, empfehle ich euch diesen Blog-Beitrag.

Fraud Proofs

Derzeit gibt es zwei Arten von Fraud Proofs:

Nicht-interaktiv
Interaktiv

Nicht-interaktive Fraud Proofs ermöglichen es einer Partei, die Unrichtigkeit einer Behauptung ohne die Beteiligung anderer Parteien zu beweisen. Dazu werden alle Zustandsübergänge zwischen zwei behaupteten Commitments ausgeführt, um zu zeigen, dass sich das resultierende Commitment von dem behaupteten unterscheidet. Nicht-interaktive Fraud Proofs haben den Vorteil, dass sie einfach zu verstehen und zu entwerfen sind. Allerdings muss der Übergang zwischen den beiden Commitments klein genug sein, um auf der Chain ausgeführt werden zu können, es sei denn, es wird ein zk-Beweis verwendet, was in Kombination mit den aktuellen Fähigkeiten von Ethereum die Anzahl der Übergänge, die mit dieser Art von Fraud Proofs effektiv überprüft werden können, stark einschränkt.

Bei interaktiven Fraud Proofs müssen zwei oder mehr Parteien zusammenarbeiten, um zu zeigen, dass eine Behauptung gültig oder ungültig ist. In der Praxis gibt es derzeit einen Verteidiger (die Partei, die die Behauptung aufstellt) und einen Herausforderer. Der Herausforderer fordert den Verteidiger auf, seine Behauptung in Unterbehauptungen zu zerlegen, von denen der Herausforderer dann die Unterbehauptung auswählen kann, mit der er nicht einverstanden ist. Der Herausforderer kann sich dann die Unterbehauptung aussuchen, mit der er nicht einverstanden ist, und so weiter, bis er eine Behauptung erreicht hat, die klein genug ist, um in der Chain ausgeführt zu werden. Interaktive Fraud Proofs führen die Komplexität der Zusammenarbeit zwischen den Parteien ein. Aufgrund der damit verbundenen Anreize ist es von Natur aus komplizierter, sie sicher zu gestalten. Die einzige Einschränkung in Bezug auf die Ausführung ist jedoch, dass eine einzelne Operation auf der Chain ausführbar sein muss, was bedeutet, dass Transaktionen und Blöcke im Rollup durch keine der L1-Grenzen eingeschränkt sind.

Welche Fraud Proofs verwenden einige der aktuellen optimistischen Rollups?

Optimism

Nicht-interaktive Fraud Proofs sind der attraktivste Ansatzpunkt, und in der Tat ist dies die Richtung, die Optimism in seiner ersten Version eingeschlagen hat. In der Version V2 wird jedoch auf interaktive Beweise umgestellt. Um zu verstehen, warum das so ist, sehen wir uns die Grenzen eines nicht-interaktiven Fraud Proofs genauer an.

Nicht-interaktive Fraud Proofs müssen den gesamten Zustandsübergang zwischen zwei Assertions ausführen. Optimism hat die Transaktionsebene als Granularität für den Zustandsübergang gewählt, in der Hoffnung, dass die Nutzer/innen in der Lage sind, normale Ethereum-Transaktionen auf ihrem Rollup auszuführen.

Die erneute Ausführung einer Ethereum-Transaktion, die auf dem Rollup stattgefunden hat, auf dem Ethereum Mainnet wird von Ethereum jedoch nicht unterstützt. Das liegt daran, dass Transaktionen Zugriff auf den zugrunde liegenden Status und die Konten der Chain haben, die sich zwischen dem Rollup und dem Mainnet unterscheiden.

Damit Optimism seine Transaktionen im Mainnet ausführen kann, müssen die Opcodes, die auf den Status und die Konten zugreifen, durch synthetische Opcodes ersetzt werden, die einen bestimmten Vertrag aufrufen, der mit dem relevanten Status vorausgefüllt ist. Insgesamt wurden 18 Opcodes auf diese Weise ersetzt, 6 weitere wurden ganz entfernt. Bytecode, bei dem diese Opcodes durch Funktionsaufrufe ersetzt wurden, wird in der Optimistic Virtual Machine (OVM) ausgeführt. Optimism hat den Solidity-Compiler geforkt, damit die Entwickler ihre Verträge für die OVM kompilieren können.

Das Ersetzen von Befehlen für den Zugriff auf den Zustand durch Vertragsaufrufe bläht die Bytecodegröße einiger Contracts stark auf. Ethereum hat eine Größenbeschränkung von ~25kB für Contracts, was bedeutet, dass einige Contracts nach der Übersetzung von der EVM in die OVM ein Refactoring benötigen oder zerlegt werden müssen, damit sie bei einem Fraud Proof wieder eingesetzt werden können.
Da Aufrufe anstelle des nativen Zugriffs auf den Status viel mehr Gas benötigen, hatten Transaktionen, die auf der OVM liefen, ein niedrigeres Gaslimit als ihre Äquivalente, die auf Ethereum liefen.

Verträge, die von EVM in OVM-Bytecode übersetzt werden, leiden unter zwei großen Einschränkungen:

Beide Einschränkungen betreffen Vertragsentwickler/innen und Nutzer/innen, da es für die Entwickler/innen sehr aufwändig ist, Verträge neu zu schreiben, die für das Ethereum Mainnet konzipiert wurden. Da die Entwicklung von Verträgen ein teurer, zeitaufwändiger und sicherheitsintensiver Prozess ist, stellen diese Einschränkungen eine große Hürde für die Akzeptanz von Optimism V1 dar und sind der Hauptgrund für den Wechsel zu interaktiven Fraud Proofs.

Arbitrum

Ein Rollup, das derzeit interaktive Fraud Proofs in der Produktion einsetzt, ist Arbitrum. Ihr Protokoll erlaubt es dem Verteidiger und dem Herausforderer, die Behauptungen des anderen so lange zu zerlegen, bis sie einen einzelnen Schritt finden, bei dem sie sich nicht einig sind, und diesen dann in der Chain auszuführen. Die Größe des von Arbitrum gewählten Einzelschritts ist die einer einzelnen Anweisung. Die Ausführung einer einzelnen Anweisung in einer virtuellen Maschine erfordert den Zugriff auf den internen Zustand der virtuellen Maschine. Dazu gehören der Stack und der Speicher, aber auch der Status und die Globals. Es muss ein Interpreter für die virtuelle Maschine geschrieben werden, der auf Ethereum läuft und einzelne Anweisungen ausführen kann.

Da sie einen Interpreter für die virtuelle Maschine schreiben müssten, entschied sich Arbitrum dafür, einen neuen Interpreter zu schreiben, der für ihren Anwendungsfall, die Ausführung einzelner Schritte, optimiert ist, anstatt einen Interpreter für die EVM zu schreiben. Ein Beispiel für eine Optimierung war die Änderung der Struktur des VM-Speichers, so dass er unveränderlich ist und immer in konstanter Zeit zugegriffen werden kann, anstatt in logarithmischer Zeit, wie es die aktuelle EVM-Struktur erfordern würde. Sie nannten diese rollup-optimierte virtuelle Maschine AVM (Arbitrum Virtual Machine).

AVM-Verträge und -Transaktionen haben nicht dieselben Beschränkungen wie OVM-Verträge. Da Transaktionen nie vollständig neu ausgeführt werden, können sie sogar die Grenzen des Ethereum-Mainnet überschreiten, wenn die Arbitrum-Nodes dies zulassen. Das Schreiben einer neuen VM hat weitere Vorteile. Da alles, was in AVM-Code geschrieben wird, auf Ethereum nachgewiesen werden kann, können die Arbitrum-Entwickler neue Opcodes einbinden, solange sie von EVM-Opcodes unterstützt werden können. Dadurch können sie andere Node-Verhaltensweisen, wie das Lesen von Transaktionen aus ihren Inbox-Verträgen, einfach in die Menge der Operationen einbeziehen, die als korrekt bewiesen werden können. Arbitrum kann die gleiche Art von Fraud Proof für jedes Verhalten des Nodes verwenden, das sie nachweisbar machen wollen.

Ein großer Nachteil beim Schreiben einer neuen VM ist, dass sie nicht immer mit Ethereum kompatibel ist, und wo eine Kompatibilität möglich ist, kann ein zusätzlicher Aufwand nötig sein, um sie zu erreichen.

Abweichung von Ethereum

Beide oben genannten Ansätze weichen von der EVM ab, was für Arbitrum, Optimism und ihre Nutzer/innen technische Herausforderungen mit sich bringt. Entwickler, die Contracts für die EVM schreiben, erwarten, dass ihre Contracts auf der AVM und der OVM laufen, dass bestehende Tools funktionieren und dass JSON-RPCs mit Ethereum konsistent sind. Um dies zu erreichen, müssen die Rollups möglicherweise die JSON-RPC-Endpunkte der Nodes so anpassen, dass sie sich konsistent verhalten, was in einigen Fällen möglich ist, in anderen jedoch nicht.

Ein Beispiel dafür, wo Arbitrum Parität erreicht hat, ist die Annahme von EVM-Transaktionen. Arbitrum hat einen EVM-zu-AVM-Compiler geschrieben, der selbst auf dem AVM läuft. Das bedeutet, dass Transaktionen, die im EVM-Bytecode signiert und eingereicht werden, als Teil ihrer Ausführung nachweislich kompiliert werden können.

Ein Beispiel dafür, wo beide Rollups bisher keine vollständige Parität erreichen konnten, ist bei den Gas-Semantiken: Optimism hat einige Opcodes ersetzt, die möglicherweise mehr Gas benötigen, und Arbitrum hat die Gaskosten so angepasst, dass sie die Kosten für den AVM widerspiegeln.

Annäherung an Ethereum

Die Wahl des Fraud Proofs von Optimism hat zu erheblichen Einschränkungen für die Nutzer geführt und stellt ein Hindernis für die Akzeptanz dar. Sie wenden sich nun interaktiven Fraud Proofs zu, um diese Einschränkungen zu beseitigen.

Anders als bei der aktuellen Version von Arbitrum wollen sie jedoch keine neue virtuelle Maschine entwickeln, sondern versuchen, eine Darstellung des EVM zu finden, die effizient auf der Chain bewiesen werden kann. Auf diese Weise versuchen sie, die 100%ige Kompatibilität mit der EVM und Ethereum zu erhalten. Sie können dann möglicherweise minimale Änderungen an bestehenden Ethereum-Client-Codebases vornehmen und sie als Rollup-Clients laufen lassen, wobei sie die Sicherheit und die harte Arbeit, die in sie investiert wurde, übernehmen. Das sollte auch bedeuten, dass sie ohne zusätzlichen Aufwand Kompatibilität mit allen bestehenden JSON-RPC-Endpunkten und den Tools, die darauf aufbauen, erreichen.

Es scheint, dass auch Arbitrum den Wert dieses Ansatzes erkannt hat, und in ihrem letzten Blogbeitrag haben sie einen Ansatz skizziert, der sie in diese Richtung bringt.

Es gibt eine Reihe von Möglichkeiten, wie dies erreicht werden kann:

Erweiterung des Befehlssatzes um eine vollständige Blockvalidierung und Aufteilung großer Einzelschritte in kleinere Teilschritte. Das Macula-Projekt ist ein Versuch in diese Richtung. Es zielt darauf ab, eine Ausführungsspur für die vollständige Ausführung eines Ethereum-Blocks zu erstellen und dann einen Interpreter für diese Ausführungsspur zu schreiben. Auf diese Weise können alle Operationen in einem Block in einen einzigen Schritt zerlegt und dann auf der Chain ausgeführt werden. Es behandelt Opcodes, die für den Nachweis nicht effizient sind, wie z.B. das Kopieren von Speicher, indem es sie in Unterbefehle zerlegt, deren Summe der Ausführung des ursprünglichen Befehls entspricht.

Eine bestehende Architektur wird verwendet, die sich besser beweisen lässt, und es wird ein EVM-Interpreter für sie implementiert. Das Cannon-Projekt extrahiert die Teile von Geth, die für die Verifizierung eines Blocks verwendet werden. Anschließend werden diese Teile von Geth in einen Befehlssatz kompiliert, der sich besser für die Prüfung eignet — wie MIPS oder RISC-V. Wenn dieser MIPS-Geth zur Verifizierung eines Blocks verwendet wird, wird eine Ausführungsspur aufgezeichnet, die zwei Parteien zerlegen können, um eine einzelne Anweisung zu finden, über die sie sich nicht einig sind und die dann mit einem MIPS-Interpreter auf der Chain ausgeführt werden würde. Dies scheint auch die Richtung zu sein, die Arbitrum einschlagen will, allerdings wollen sie statt MIPS den WASM-Standard verwenden.

Erstelle einen Zero Knowledge Proof der Einzelschrittausführung. Anstatt den einzelnen Schritt in der Chain auszuführen, könnte der Contract stattdessen überprüfen, ob ein Beweis für die Ausführung dieses einzelnen Schritts gültig ist. Große Zustandsübergänge, wie z. B. vollständige Transaktionen, in der zk zu beweisen, ist derzeit in kurzen Zeiträumen nicht möglich, aber Beweise für einen einzelnen Schritt zu erstellen, sollte machbar sein. Dieser Ansatz wird derzeit von Forschern der Oasis Labs und der UC Berkeley untersucht, wurde aber auch im Arbitrum Paper beschrieben.

Jede dieser Methoden bietet Fraud Proofs, die für die Nutzer/innen keine Adoptionshürden darstellen und es den Rollup Nodes ermöglichen, bestehende Ethereum-Implementierungen zu betreiben und deren Sicherheit, Wartbarkeit und Kompatibilität mit dem Ethereum Mainnet zu übernehmen.

Aber sie alle erfordern die kompliziertere interaktive Art des Fraud Proofs. Ist es also möglich, die oben genannten Eigenschaften mit einem nicht-interaktiven Fraud Proofs zu erreichen?

Nun, eigentlich ja! Es gibt derzeit zwei bekannte Ansätze dafür:

Zero Knowledge Proofs für den vollständigen Zustandsübergang. Es gibt noch eine Reihe von Herausforderungen, die überwunden werden müssen, bevor zk-Beweise für vollständige Transaktionen in kurzen (Blockzeit-)Zeiträumen erstellt werden können. Wenn der Zero Knowledge Proof jedoch als Fraud Proof verwendet wird, muss die Erstellung des Beweises nicht effizient sein. Derzeit gibt es bei Fraud Proofs eine lange Challenge-Periode (~1 Woche), damit die Herausforderer Zeit haben, die aktuelle Chain zu validieren, einen Fraud Proof zu erstellen und ihn an Ethereum zu übermitteln. Selbst wenn die Erstellung eines Fraud Proofs sehr lange dauert (z. B. 1–2 Tage), kann dieser Zeitraum verlängert werden, ohne dass das Protokoll insgesamt beeinträchtigt wird. Wie die interaktiven Fraud Proofs kann auch diese Art von Fraud Proof die Grenzen von L1 überschreiten. Dieser Ansatz wird derzeit von Sumo und Consensys erforscht.

Bare-Metal- Fraud Proof. Das ursprüngliche Ziel von Optimism war es, EVM-Code auf dem EVM auszuführen, aber das war nicht möglich, da der Mainnet-EVM keinen Zugriff auf den Rollup-Status hat. Aber ist es möglich, ein System zu entwickeln, in dem dies möglich ist?

Das ist der Ansatz von Oasis Labs. Ihre Blockchain unterteilt die Ausführung in einen schnellen und einen langsamen Weg. Unterausschüsse der Konsensgruppe führen Transaktionen gegen einen Stammzustand aus. Der daraus resultierende Stammzustand wird dann auf einer Basis-Chain gespeichert, die von der gesamten Konsensgruppe validiert wird. Wenn ein Mitglied eines Unterkomitees mit dem resultierenden Stammzustand nicht einverstanden ist, kann es die gesamte Konsensgruppe auffordern, den strittigen Zustandsübergang erneut auszuführen. Ein einziger ehrlicher Validator ist in einem Unterkomitee erforderlich, um die Sicherheit der Basis-Chain zu übernehmen — die gleiche Sicherheit wie bei optimistischen Rollups.

Dieser Ansatz fügt sich nahtlos in das Konzept des Stateless Clients von Ethereum ein. In diesem Paradigma speichern die Konsensknoten nur den Stammzustand der Chain. Die Transaktionen werden dann von dem Zustand begleitet, auf den sie zugreifen, und von einem Zeugen, der beweist, dass der Zustand Teil des Stammzustands ist. Zustandslose Clients akzeptieren Transaktionen, die von einem Zustand begleitet werden, und führen sie gegen ihren gespeicherten Stammzustand aus, um einen neuen Stammzustand zu erzeugen. Wenn sie die empfangenen Transaktionen nicht gegen ihre gespeicherte State Root, sondern gegen eine bereitgestellte State Root ausführen würden, könnten sie Transaktionen für andere Ethereum-kompatible Chains erneut ausführen. Diese Funktionalität könnte als neuer Transaktionstyp hinzugefügt werden, der sich wie folgt verhält:

Die Daten enthalten einen Block von Rollup-Transaktionen mit zugehörigem Status und Zeugen sowie einen Status-Root.
Der Client führt den Block von Transaktionen gegen den State Root aus, um den nächsten State Root zu erzeugen
Das Tupel (vorheriger State Root, Transaktionsblock-Hash, nächster State Root) wird dann in einem globalen Contract gespeichert, so dass alle Smart Contracts diese Informationen abrufen und anhand der Ergebnisse Slashing usw. durchführen können.

Mit einer solchen neuen Transaktionsart für zustandslose Clients wäre Ethereum in der Lage, Zustandsübergänge für andere Ethereum-kompatible Chains vollständig neu auszuführen. Es könnte einen einfachen nicht-interaktiven Fraud Proof für Ethereum-kompatible optimistische Rollups bieten. Dieser Fraud Proof läuft direkt auf dem EVM und nicht in einer virtualisierten Umgebung, die im EVM gehostet wird — ein Bare Metal Fraud Proof.

Zusammenfassung

Optimistische Rollups erfordern Fraud Proofs, um sicher zu sein. Wir haben uns zwei populäre Rollups angeschaut und gesehen, wie ihre Wahl des Fraud Proofs entweder zu Einschränkungen für ihre Nutzer und Vertragsentwickler geführt hat (Optimism) oder die Kompatibilität mit Ethereum nicht vollständig aufrechterhalten hat (Arbitrum). Beide Rollups bewegen sich auf eine vollständige Kompatibilität mit Ethereum zu, ohne neue Einschränkungen, und verwenden dazu interaktive Fraud Proofs. Interaktive Fraud Proofs sind jedoch komplizierter zu konstruieren und es gibt derzeit Forschungsansätze, um effiziente nicht-interaktive Fraud Proofs zu finden, die keine zusätzlichen Einschränkungen mit sich bringen und trotzdem mit Ethereum kompatibel bleiben können.

Vielen Dank an Patrick McCorry, Dawn Song, Bennet Yee und Nicholas Liochon für ihr Feedback und ihren Beitrag.

Ursprünglich veröffentlicht von Chris Buckland auf https://medium.com am 22. Oktober 2021.

Fraud Proofs und virtuelle Maschinen