Besonderer Dank geht an Jon Charbonneau und Conor McMenamin für die Durchsicht dieses Artikels.

An dieser Stelle sollten wir alle wissen, dass Bestätigungsregeln Sicherheit haben, nicht Rollups selbst. Wenn wir sagen, dass Rollups die „Ethereum-Sicherheit“ erben oder dass sie „vertrauensminimiert“ sind, meinen wir eigentlich, dass es bei Rollups möglich ist, Bestätigungsregeln zu verwenden, die ungefähr die gleiche Sicherheit wie die Bestätigungsregeln von Ethereum haben. Block-Explorer legen jedoch meist Wert darauf, ein grünes Abzeichen anzuzeigen, ohne näher darauf einzugehen, auf welche Bestätigungsregel sie sich beziehen oder welche Sicherheitseigenschaften sie bereitstellen.

Bei L2BEAT wollen wir dieses Problem angehen und es für alle zugänglich machen. Insbesondere möchten wir uns auf die Endgültigkeit konzentrieren, die stärkste Bestätigungsregel gegen Double-Spend-Angriffe.

Bestätigungsregeln: Konsistenz vs. Verfügbarkeit

Bestätigungsregeln sind Algorithmen, die unter bestimmten Annahmen angeben, wann ein Block bestätigt ist und wahrscheinlich nicht neu organisiert wird. Sobald ein Block bestätigt ist, können Aktionen im Zusammenhang mit seinen Transaktionen durchgeführt werden. Dabei kann es sich beispielsweise um die Übergabe eines Kaffees an einen Kunden oder die Übergabe eines Autos an seinen Käufer handeln.

Unterschiedliche Bestätigungsregeln geben Benutzern unterschiedliche Sicherheitsgarantien. Die Sicherheit einer Bestätigungsregel umfasst Konsistenz und Verfügbarkeit und hängt stark von den zugrunde liegenden Konsensalgorithmen ab:

• Konsistenz (Sicherheit): Die Ansichten zweier beliebiger Knoten sind unter Netzwerkpartitionen konsistent.
• Verfügbarkeit (Liveness): Transaktionen werden innerhalb einer bestimmten Zeit weiterhin in das Hauptbuch aufgenommen, auch wenn ein erheblicher Teil der Knoten nicht mehr am Protokoll teilnimmt.

Das CAP-Theorem sagt uns, dass es nicht möglich ist, einen Konsensalgorithmus zu entwerfen, der sowohl unter Netzwerkpartitionen konsistent bleibt als auch unter dynamischer Beteiligung verfügbar bleibt: Wenn eine schwerwiegende Netzwerkpartition auftritt, können Knoten entweder entscheiden, weiterhin Blöcke zu produzieren und die Konsistenz zu verlieren, oder sie stoppen und Verfügbarkeit verlieren. Es gibt für Knoten keine Möglichkeit zu unterscheiden, ob andere einfach offline sind (dynamische Teilnahme) oder aktiv, aber nicht erreichbar sind (Netzwerkpartitionen), und daher ist es nicht möglich, anders zu handeln.

Eve kann nicht wissen, ob Bob einfach offline ist oder sich auf einer anderen Netzwerkpartition befindet.

Blockchains wie Bitcoin, die einen Nakamoto-ähnlichen Konsens verwenden, sind lebensfördernd, was bedeutet, dass während einer Netzwerkspaltung beide Seiten weiterhin Blöcke produzieren und sich schließlich neu organisieren, wenn die Teilung aufgelöst wird, während andere wie Cosmos-Ketten einen PBFT-ähnlichen Konsens verwenden Konsens , Halt unter Netzwerkpartitionen, um die Konsistenz zu wahren.

Bestätigungsregeln für Ethereum

Ethereum priorisiert die Verfügbarkeit unter Netzwerkpartitionen mithilfe des LMD GHOST- Algorithmus. Dieser Ansatz bedeutet, dass ehrliche Knoten möglicherweise unterschiedliche Ansichten über die Spitze der Kette haben und unterschiedliche Blöcke für dieselbe Höhe bestätigen könnten, was möglicherweise zu Neuorganisationen führt.

Unter günstigen Netzwerkbedingungen zielt Ethereum auch darauf ab, Konsistenzgarantien durch Endgültigkeit unter Verwendung des Casper FFG- Protokolls bereitzustellen. Finalität ist die stärkste mögliche Bestätigungsregel, wobei Knoten eine fest codierte Regel haben, um finalisierte Blöcke niemals neu zu organisieren.

Das endgültige Hauptbuch (grün) ist immer ein Präfix des Live-Hauptbuchs (blau).

Die Finalitätsgarantien werden gefährdet, wenn zwei widersprüchliche Blöcke finalisiert werden, ein Ereignis, das eintreten kann, wenn mehr als ein Drittel der Validatoren böswillig handeln. Bei Ethereum sind solche Aktionen jedoch mit der erheblichen Strafe verbunden, dass sie ihren Anteil verlieren.

Benutzer können wählen, ob sie die Casper FFG als sicherste Bestätigungsregel verwenden oder durch die Verwendung von LMD GHOST aktiver sein möchten. Bestätigungsregeln für LMD GHOST können, ähnlich wie die K-Bestätigungsregel in Bitcoin, anspruchsvoller sein als nur die Prüfung, ob die Transaktion im Ledger enthalten ist, wie in der Safe Block-Bestätigungsregel angegeben.

Bestätigungsregeln für Rollups

Rollups können grundsätzlich dieselben Bestätigungsregeln verwenden, die auf Ethereum verfügbar sind. Wenn Sie eine Transaktion in einem Rollup senden und später sehen, dass dieselbe Transaktion auf L1 in einem finalisierten Block gepostet wird, möchten Sie möglicherweise auch die L2-Transaktion als final betrachten. Es stellt sich heraus, dass die Geschichte viel komplexer ist.

Rollups von Transaktionsdaten

Auf Ethereum enthalten Blöcke sowohl die Liste der Transaktionen als auch den vorgeschlagenen Statusstamm im Blockheader. Wenn die Ausführung der Transaktionen nicht zu dem Zustand führt, den die Wurzel darstellt, wird der gesamte Block verworfen, einschließlich der Transaktionen, die später in einer anderen Reihenfolge zu anderen Blöcken hinzugefügt werden können.

Da bei Rollups die Aktionen zum Veröffentlichen von Daten und Roots entkoppelt sind, müssen Transaktionen abhängig von der Gültigkeit der entsprechenden Statusroots nicht verworfen werden. Angesichts dieser Trennung reicht es aus, zu überprüfen, ob Transaktionen abgeschlossen sind, ohne auf die Finalisierung des Statusstamms zu warten, wodurch zusätzliche Verzögerungen wie die 7-tägige Herausforderungsfrist bei optimistischen Rollups umgangen werden.

Rollup der Statusunterschiede

Zustandsunterschiede sind Ausgaben einer Zustandsübergangsfunktion, und um zu bestätigen, dass sie tatsächlich gültig sind, muss man auf einen ZK-Beweis warten. Die Erstellung von ZK-Beweisen braucht Zeit, und darüber hinaus besteht ein Anreiz, die Aufnahme weiterer Transaktionen in einen einzigen Beweis noch weiter zu verzögern, um die Kosten für die Beweiserstellung und -verifizierung besser zu amortisieren.

Proof-Aggregation-Techniken bieten eine Lösung für diesen Kompromiss zwischen Bestätigungszeiten und Kostenamortisation: Selbst wenn ein Rollup nur minimale Aktivität erfährt, kann er dennoch von der Amortisation profitieren, indem Transaktionen von aktiveren Rollups in denselben Proof einbezogen werden. Ein Beispiel für diesen Ansatz ist SHARP von Starkware, das derzeit Beweise aus Starknet-, Paradex- und StarkEx-Rollups wie dYdX und sogar Validiums zusammenfasst.

Wo es kompliziert wird

Rollup-Ableitungsspezifikation

Wenn ein Rollup nicht basiert, kann die Ableitungsreihenfolge von Batches durch den Rollup-Sequenzer definiert werden, der sie möglicherweise in einer anderen Reihenfolge auf L1 veröffentlicht.

Um ein Beispiel zu nennen: OP-Stack-Ketten veröffentlichen Stapel auf L1, die mithilfe der Hashes des vorherigen Stapels verknüpft sind. Diese Stapel müssen nicht in chronologischer Reihenfolge veröffentlicht werden, was zu einem 12-stündigen Sequenzierungsfenster führt, in dem Knoten auf möglicherweise fehlende Transaktionen warten. Transaktionen sollten nicht allein deshalb als einbezogen betrachtet werden, weil sie auf L1 veröffentlicht werden: Wenn ein Batch noch nicht mit der kanonischen Batch-Kette verbunden ist, besteht das Risiko, dass ein alternativer Fork mit einer anderen Reihenfolge oder einem anderen Transaktionssatz erstellt wird.

Bei OP-Stack-Ketten beträgt die Blockzeit 2 Sekunden, was zu 6 Blöcken innerhalb jedes Ethereum-Blocks führt. Diese Gruppierung von 6 Blöcken zwischen Ethereum-Blöcken wird als „Epoche“ bezeichnet. Über L1 übermittelte L1-zu-L2-Nachrichten sind im ersten Teil des ersten Blocks der entsprechenden Epoche für den angegebenen L1-Block enthalten. Während diese Transaktionen als bestätigt betrachtet werden können, ohne auf den Ablauf des Sequenzierungsfensters warten zu müssen, da ihre Reihenfolge innerhalb des L2-Ledgers bei der Ableitung bekannt ist, ist es wichtig zu beachten, dass Knoten nicht mit der Berechnung von Blöcken beginnen, die diese Nachrichten enthalten, wenn ein vorhergehender Stapel fehlt. Dies liegt daran, dass der Zustand ohne die vollständige Sequenz nicht berechnet werden kann und daher auch keine Zustandswurzeln auf L1 veröffentlicht werden.

Dies hat zur Folge, dass die bloße Untersuchung von On-Chain-Daten nicht ausreicht, um L1-Bestätigungszeiten zu verfolgen. Es ist auch notwendig zu verstehen, wie L2-Blöcke aus L1-Daten abgeleitet werden, indem man die Rollup-Knotensoftware selbst untersucht.

Erlaubte Funktionen

Scroll ist ein ZK-Rollup, bei dem Transaktionsdaten gebucht werden. Das bedeutet, dass man im Prinzip nicht auf einen ZK-Beweis warten muss, um die Transaktion als endgültig zu betrachten. Dies wäre der Fall gewesen, wenn sie keine Funktion zum Löschen noch nicht nachgewiesener Chargen implementiert hätten.

https://etherscan.io/address/0x2e07f0fba71709bb5e1f045b02152e45b451d75f#code#F1#L260

Das Gleiche kann für Rollups gelten, die Statusunterschiede veröffentlichen: zkSync Era und zkSync Lite verfügen über einen dreistufigen Prozess zum Posten von Statusunterschieden: Zuerst werden die Daten ohne Nachweis übermittelt, dann wird ein Nachweis dafür bereitgestellt und dann nach einer Verzögerung von 24 Stunden , wird der Stamm zur Ausführung verfügbar, um Abhebungen zu verarbeiten. Wenn ein Beweis vorgelegt wird, ist theoretisch die Reihenfolge der Transaktionen festgelegt, sodass man nicht warten muss, bis die Ausführungsverzögerung verstrichen ist. Allerdings kann zkSync diese Blöcke rückgängig machen:

https://etherscan.io/address/0x7Ed066718Dfb1b2B04D94780Eca92b67ECF3330b#code#F10#L425

Während bei zkSync Era noch nie eine Blockierung rückgängig gemacht wurde, kam es bei zkSync Lite achtmal vor.

Beobachtbarkeit der Endgültigkeit

Da Rollup-Buchungsstatusunterschiede keine Transaktionsdaten veröffentlichen, wie können wir dann nachverfolgen, ob tatsächlich eine Transaktion enthalten ist? Ja, wir könnten Effekte wie Konto-Nonces verfolgen, aber im Allgemeinen wird es schwierig. Vor einem Monat habe ich folgende Frage gestellt:

Werfen wir einen Blick auf einige der Antworten:

Dies ist eine Lösung, die funktioniert, wenn der Sequenzer bereit ist, auf Sie zu antworten, und wenn Sie ihm vertrauen. Was ist, wenn dies nicht der Fall ist? Oder was ist, wenn es funktioniert, Sie ihm aber nicht vertrauen? Wie überprüfen Sie, ob die Behauptung korrekt ist?

Meine Lieblingsantwort.

Eine tatsächlich funktionierende Lösung wurde hier vorgeschlagen:

Dies funktioniert zwar, bedeutet aber, dass die technische Entscheidung zur Verwendung von Statusunterschieden in die Anwendungslogik eindringt, was bedeutet, dass Projekte ihren Vertrag an diese Überlegung anpassen müssen, selbst wenn ein Rollup EVM-äquivalent ist.

Eine Teillösung besteht darin, einen Transaktionsstamm zu veröffentlichen und ihre Gültigkeit im ZK-Beweis zu überprüfen. Aber selbst in diesem Fall muss man sich auf den Sequenzer verlassen, um den notwendigen Merkle-Pfad zu erhalten, was bei seriösen zentralisierten Sequenzern sinnvoll sein könnte, in einer erlaubnisfreien Umgebung jedoch schwieriger wird.

Liveness-Metriken

Als ersten Schritt zur Verfolgung der Zeitspanne bis zur Endgültigkeit von Rollup-Transaktionen haben wir auf L2BEAT damit begonnen, Liveness-Metriken zu verfolgen, insbesondere Intervalle zwischen Transaktionsstapeln (falls zutreffend) und Statuswurzeln. Der Grund dafür ist, dass Benutzer nicht erwarten können, dass die Zeit bis zur Endgültigkeit in der Größenordnung von Minuten liegt, wenn ein Rollup beispielsweise nur einmal im Monat mit L1 interagiert. Liveness-Metriken können als unterer Indikator für die Zeit bis zur Endgültigkeit betrachtet werden: Wenn ein Transaktionsdaten-Rollup alle zwei Minuten Stapel sendet und davon ausgegangen wird, dass die Verteilung der L2-Transaktionen gleichmäßig ist, beträgt die erwartete Zeit bis zur Endgültigkeit nicht weniger als eine Minute .

Hier sind einige Beispiele für Daten, die wir für zkSync Era (Statusaktualisierungen) und OP Mainnet (TX-Batches) verfolgen:

Liveness-Metriken der zkSync-Ära für den Monat September.

OP-Mainnet-Liveness-Metriken für den Monat September.

Wie vorhergesagt, hat zkSync Era schlechtere Liveness-Metriken als OP Mainnet, da die Generierung von ZK-Proofs einige Zeit in Anspruch nimmt und der Anreiz besteht, mehr Transaktionen in einen einzigen Proof einzubeziehen. Es ist wichtig zu bedenken, dass sich Liveness-Metriken, wie wir in den vorherigen Abschnitten besprochen haben, nicht direkt in Überlegungen zur Endgültigkeit umsetzen lassen: Im schlimmsten Fall hat OP Mainnet aufgrund seines Sequenzierungsfensters tatsächlich eine längere Zeit bis zur Endgültigkeit.

Sie können jetzt Liveness-Metriken für die meisten Rollups auf L2BEAT erkunden:

Einschränkungen bei der Verfolgung der Lebendigkeit

Während Lebendigkeit als unterer Indikator für Endgültigkeit angesehen werden kann, kann sie manchmal auch ein sehr schlechter Indikator sein. Stellen Sie sich ein Rollup mit einer Blockzeit von 4 Sekunden vor, was bedeutet, dass es für jeden Ethereum-Block 3 Rollup-Blöcke gibt. Wenn der Rollup-Betreiber nur zwei L2-Blöcke pro L1-Block veröffentlicht, wird er, selbst wenn das Rollup aus Sicht von Ethereum sehr aktiv ist, zunehmend hinter den weichen L2-Bestätigungen zurückbleiben und die Zeit bis zur Endgültigkeit wird immer schlechter. Obwohl dies ein Extremszenario ist, müssen Rollups dies berücksichtigen.

Ein praktisches Beispiel ist Starknet: Obwohl zwischen Statusaktualisierungen durchschnittlich 32 Sekunden vergehen, beträgt die Zeit bis zur Endgültigkeit tatsächlich fast 6 Stunden:

Quelle: starkscan.co

Dies liegt daran, dass Starknet für jeden L2-Block auf L1 ein Status-Root-Update veröffentlicht. Dazu müssen sie jedoch auf einen SHARP-Beweis verweisen, der normalerweise etwa alle 30 Minuten veröffentlicht wird. Darüber hinaus liegen diese Beweise etwa 6 Stunden hinter der Spitze der weich bestätigten L2-Kette.

Sanfte Bestätigungen

Soft-Bestätigungen sind Bestätigungsregeln, mit denen kürzere Bestätigungszeiten auf L2 auf Kosten von Sicherheitsgarantien erreicht werden sollen. Derzeit setzen Soft-Bestätigungen in allen Fällen voraus, dass man dem zentralen Betreiber vertrauen muss, dass er keine unterschiedlichen Sendungen auf L1 postet. Falsche Soft-Bestätigungen sind auf Fehler zurückzuführen, daher können Mechanismen implementiert werden, um die Reputation von Sequenzern außerhalb der Kette oder in der Kette zu verfolgen. In Zusammenarbeit mit Nethermind planen wir, diese Sicherheitseigenschaften abzuschätzen und den gefährdeten Wert zu jedem Zeitpunkt zu verfolgen.

Links: Wirtschaftsgarantien für Starknet, wenn sie über weiche Bestätigungen verfügten, die durch einen Slashing-Mechanismus gesichert waren. Rechts: Gesamtwert, bei dem das Risiko einer Neuordnung im Laufe der Zeit besteht.

Vorwärts gehen

Die Verfolgung der Zeit bis zur Endgültigkeit ist eine komplexe Aufgabe. Unser erster Schritt besteht darin, die Intervalle der Proof-Einreichungen für ZK-Rollups zu überwachen, die eine höhere Untergrenze für die Zeit bis zur Endgültigkeit festlegen als die Intervalle zwischen staatlichen Root-Einreichungen. Anschließend planen wir die Einführung von Diagrammen, die historische Daten für jedes Projekt anzeigen. Anschließend wird sich unsere Forschung auf alle zusätzlichen Mechanismen konzentrieren, die berücksichtigt werden müssen, um letztendlich Echtzeitmetriken für die Zeit bis zur Endgültigkeit zu erhalten. Bleiben Sie dran!

Haftungsausschluss:

1. Dieser Artikel wurde von [Medium] nachgedruckt. Alle Urheberrechte liegen beim ursprünglichen Autor [Luca Donno]. 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.