Vitalik: Überblick über die Unterschiede der verschiedenen L2s

L2-Projekte werden zunehmend heterogener.

Originaltitel: 《Different types of layer 2s》

Autor: Vitalik Buterin

Übersetzung: BlockBeats

Das Ökosystem hat sich im vergangenen Jahr rasant erweitert. Das traditionell von StarkNet, Arbitrum, Optimism und Scroll repräsentierte ZK-EVM-Rollup-Ökosystem entwickelt sich schnell weiter und erhöht kontinuierlich seine Sicherheit. Die L2beat-Seite fasst den Status jedes Projekts sehr gut zusammen.

Darüber hinaus sehen wir, dass einige Teams Sidechains aufbauen und gleichzeitig beginnen, Rollup-Lösungen zu entwickeln (wie Polygon), einige L1-Projekte versuchen, in Richtung Validitätsprüfung zu gehen (wie Celo), und es gibt ganz neue Ansätze (wie Linea, Zeth…).

Eines der unvermeidlichen Ergebnisse ist, dass wir sehen, dass L2-Projekte zunehmend heterogen werden (d.h. „heterogenisiert“). Anmerkung des Übersetzers: Im Kryptobereich bedeutet „Heterogenisierung“, dass verschiedene Arten oder unterschiedliche Dinge nebeneinander existieren oder gemischt werden. Dieser Begriff wird häufig verwendet, um verschiedene Blockchains, Protokolle, Technologien oder Vermögenswerte zu beschreiben, die unterschiedliche Eigenschaften, Regeln oder Attribute haben. Ich erwarte, dass dieser Trend aus folgenden Gründen anhalten wird:

Derzeit versuchen einige unabhängige L1-Projekte, enger mit dem Ethereum-Ökosystem zu interagieren und könnten sich zu L2-Projekten entwickeln. Diese Projekte möchten möglicherweise einen schrittweisen Übergang vollziehen. Ein sofortiger Gesamtübergang würde die Nutzbarkeit verringern, da die Technologie noch nicht bereit ist, alles in Rollup-Lösungen zu integrieren. Ein zu später Gesamtübergang könnte jedoch das Momentum opfern und zu spät kommen, um von Bedeutung zu sein.

Einige zentralisierte Projekte möchten ihren Nutzern mehr Sicherheit bieten und erforschen blockchainbasierte Ansätze. In vielen Fällen hätten diese Projekte früher „permissioned consortium chains“ in Betracht gezogen. Tatsächlich benötigen sie möglicherweise nur ein „halbzentralisiertes“ Niveau. Außerdem haben sie in der Regel eine sehr hohe Durchsatzrate und sind zumindest kurzfristig nicht für Rollup-Lösungen geeignet.

Nicht-finanzielle Anwendungen wie Spiele oder soziale Medien wollen dezentralisiert sein, benötigen aber nur ein bestimmtes Maß an Sicherheit.

Im Fall von sozialen Medien geht es tatsächlich darum, verschiedene Teile der Anwendung unterschiedlich zu behandeln: Seltene und wertvolle Aktivitäten wie die Registrierung von Benutzernamen und die Wiederherstellung von Konten sollten in Rollup-Lösungen durchgeführt werden, während häufige und weniger wertvolle Aktivitäten wie Posts und Abstimmungen weniger Sicherheit benötigen. Wenn ein Blockchain-Fehler dazu führt, dass Ihr Post verschwindet, ist das ein akzeptabler Preis; wenn Sie jedoch Ihr Konto verlieren, ist das ein größeres Problem.

Ein wichtiges Thema ist, dass Anwendungen und Nutzer, die derzeit auf Ethereum L1 sind, kurzfristig bereit sind, kleine, aber dennoch sichtbare Rollup-Gebühren zu zahlen. Nutzer aus der Nicht-Blockchain-Welt sind jedoch weniger bereit dazu: Wenn Sie zuvor 1 US-Dollar bezahlt haben, ist es leichter, 0,10 US-Dollar zu akzeptieren, aber wenn Sie zuvor 0 US-Dollar bezahlt haben, ist es schwer zu akzeptieren.

Dies gilt für heute noch zentralisierte Anwendungen sowie für kleinere L1-Projekte, die in der Regel sehr niedrige Gebühren haben, solange ihre Nutzerbasis klein ist.

Eine naheliegende Frage ist: Welche dieser komplexen Abwägungen zwischen Rollup-Lösungen, Validiums (Validitätsprüfungen) und anderen Systemen ist für eine bestimmte Anwendung sinnvoll?

Rollups vs Validiums vs Disconnected Systems

Die erste Dimension von Sicherheit und Skalierbarkeit, die wir untersuchen werden, lässt sich wie folgt beschreiben: Wenn Sie einen auf L1 ausgegebenen Vermögenswert besitzen, ihn auf L2 einzahlen und dann auf Ihr Konto übertragen, wie groß ist die Garantie, dass Sie den Vermögenswert auf L1 zurückholen können?

Gleichzeitig gibt es eine verwandte Frage: Welche technischen Entscheidungen führen zu diesem Maß an Garantie, und was sind die Kompromisse dieser Entscheidungen?

Wir können dieses Problem mit einem einfachen Diagramm beschreiben:

Es ist erwähnenswert, dass dies ein vereinfachtes Schema ist, in dem es viele Zwischenoptionen gibt. Zum Beispiel:

Zwischen Rollup und Validium: Bei Validium kann jeder eine On-Chain-Zahlung leisten, um Transaktionsgebühren zu bezahlen. In diesem Fall ist der Betreiber gezwungen, einige Daten On-Chain bereitzustellen, andernfalls verliert er seine Kaution.

Zwischen Plasma und Validium: Ein Plasma-System bietet eine Rollup-ähnliche Sicherheitsgarantie mit Off-Chain-Datenverfügbarkeit, unterstützt jedoch nur eine begrenzte Anzahl von Anwendungen. Ein System kann eine vollständige EVM bereitstellen und für Nutzer, die diese komplexeren Anwendungen nicht nutzen, Plasma-Level-Garantien bieten, während Nutzer, die diese Anwendungen nutzen, Validium-Level-Garantien erhalten.

Diese Zwischenoptionen können als ein Spektrum zwischen Rollup und Validium betrachtet werden. Aber was veranlasst Anwendungen, einen bestimmten Punkt auf diesem Spektrum zu wählen und nicht weiter links oder rechts? Hier gibt es zwei Hauptfaktoren:

1. Die Kosten der nativen Datenverfügbarkeit von Ethereum, die mit dem technologischen Fortschritt im Laufe der Zeit sinken werden. Der nächste Hard Fork von Ethereum, Dencun, führt EIP-4844 (auch „proto-danksharding“ genannt) ein, das etwa 32 kB/s On-Chain-Datenverfügbarkeit bietet.

Es wird erwartet, dass diese Datenverfügbarkeit in den nächsten Jahren mit der Einführung von vollständigem Danksharding schrittweise erhöht wird, mit dem endgültigen Ziel von etwa 1,3 MB/s Datenverfügbarkeit. Gleichzeitig werden Verbesserungen bei der Datenkomprimierung es ermöglichen, mit der gleichen Datenmenge mehr zu erreichen.

2. Die Anforderungen der Anwendung selbst: Wie schwer wiegt der Verlust durch hohe Gebühren im Vergleich zu Problemen mit der Anwendung? Finanzanwendungen erleiden größere Verluste durch Anwendungsfehler; Spiele und soziale Medien beinhalten eine große Menge an Nutzeraktivitäten mit relativ geringem Wert, daher sind für sie unterschiedliche Sicherheitskompromisse sinnvoll.

Diese Abwägung sieht ungefähr wie folgt aus:

Eine weitere erwähnenswerte Art ist die Vorbestätigung (pre-confirmations). Vorbestätigungen sind von einer Gruppe von Teilnehmern in einem Rollup oder Validium unterzeichnete Nachrichten, die besagen: „Wir bestätigen, dass diese Transaktionen in dieser Reihenfolge enthalten sind und der post-state root dieser ist.“ Diese Teilnehmer könnten eine Vorbestätigung unterzeichnen, die nicht der Realität entspricht, aber wenn dies tatsächlich geschieht, wird ihre Kaution zerstört.

Dies ist für Anwendungen mit geringem Wert (wie Verbraucherzahlungen) sehr nützlich, während Anwendungen mit hohem Wert (wie Finanztransfers in Millionenhöhe) möglicherweise auf eine „reguläre“ Bestätigung warten, die durch die vollständige Sicherheit des Systems unterstützt wird.

Vorbestätigungen können als weiteres Beispiel für ein Hybridsystem betrachtet werden, ähnlich wie das oben erwähnte „Plasma/Validium-Hybrid“, aber diesmal als Mischung zwischen einem Rollup (oder Validium) mit vollständiger Sicherheit, aber hoher Latenz, und einem System mit niedrigerer Sicherheit, aber niedriger Latenz. Anwendungen, die eine geringere Latenz benötigen, erhalten eine geringere Sicherheit, können aber im selben Ökosystem mit Anwendungen koexistieren, die bereit sind, für maximale Sicherheit eine höhere Latenz in Kauf zu nehmen.

Vertrauensloses Lesen von Ethereum

Eine weitere, weniger beachtete, aber dennoch sehr wichtige Verbindungsform betrifft die Fähigkeit eines Systems, die Ethereum-Blockchain zu lesen. Insbesondere geht es darum, dass das System in der Lage ist, bei einem Rollback von Ethereum ebenfalls ein Rollback durchzuführen. Um zu verstehen, warum das wertvoll ist, betrachten Sie folgendes Szenario:

Angenommen, wie im Diagramm gezeigt, gibt es einen Rollback der Ethereum-Blockchain. Dies könnte eine vorübergehende Unterbrechung innerhalb einer Epoche sein, in der die Blockchain noch nicht finalisiert ist, oder es könnte eine längere Inaktivitätsphase sein, in der die Blockchain aufgrund zu vieler Offline-Validatoren nicht finalisiert werden kann.

Das schlimmste mögliche Szenario ist wie folgt: Angenommen, der erste Block der oberen Kette (top chain) liest einige Daten aus dem ganz linken Block der Ethereum-Kette. Zum Beispiel hat jemand 100 ETH auf Ethereum in die obere Kette eingezahlt. Dann gibt es einen Rollback auf Ethereum, aber die obere Kette macht keinen Rollback. Das Ergebnis ist, dass die zukünftigen Blöcke der oberen Kette korrekt den neuen, richtigen Ethereum-Blöcken folgen, aber die falsche Transaktion (d.h. die Einzahlung von 100 ETH) bleibt in der oberen Kette bestehen. Diese Schwachstelle könnte zu einer Inflation der Währung führen und das gebrückte ETH auf der oberen Kette in eine Teilreserve verwandeln.

Es gibt zwei Möglichkeiten, dieses Problem zu lösen:

1. Die obere Kette liest nur bereits finalisierte Ethereum-Blöcke, sodass sie niemals einen Rollback durchführen muss;

2. Wenn es einen Rollback auf Ethereum gibt, kann es auch einen Rollback auf der oberen Kette geben. Beide verhindern dieses Problem. Die erste Methode ist einfacher umzusetzen, kann aber bei einer Inaktivitätsphase von Ethereum zu längeren Funktionsausfällen führen. Die zweite Methode ist schwieriger umzusetzen, stellt aber sicher, dass die Funktionalität immer optimal bleibt.

Beachten Sie, dass es bei der ersten Methode einen Sonderfall gibt. Wenn es einen 51%-Angriff auf Ethereum gibt, der zu zwei neuen, inkompatiblen Blöcken führt, die beide als finalisiert erscheinen, könnte die obere Kette den falschen Block wählen (d.h. den Block, der letztlich nicht vom Ethereum-Social-Consensus unterstützt wird) und müsste einen Rollback durchführen, um auf den richtigen Block zu wechseln. Man kann argumentieren, dass es nicht notwendig ist, im Voraus Code für diesen Fall zu schreiben; man kann das Problem durch einen Hard Fork der oberen Kette lösen.

Die Fähigkeit einer Blockchain, Ethereum vertrauenslos zu lesen, ist aus zwei wichtigen Gründen entscheidend:

Erstens kann diese Fähigkeit die Sicherheitsprobleme beim Bridging von auf Ethereum (oder anderen Layer-2-Lösungen) ausgegebenen Token auf diese Kette verringern;

Zweitens ermöglicht diese Fähigkeit, dass Account-Abstract-Wallets mit gemeinsam genutzten Schlüsselstrukturen Vermögenswerte auf dieser Kette sicher halten können.

Obwohl umstritten, wird die Bedeutung der ersten Methode weithin anerkannt. Ebenso ist die zweite Methode wichtig, da sie bedeutet, dass Sie eine Wallet haben können, mit der Sie Schlüssel einfach ändern und Vermögenswerte auf vielen verschiedenen Chains halten können.

Kann eine Chain mit Bridge ein Validium sein?

Angenommen, die obere Kette wird zunächst als eigenständige Chain gestartet, und jemand stellt dann einen Bridge-Contract auf Ethereum bereit. Der Bridge-Contract ist einfach ein Contract, der Block-Header der oberen Kette akzeptiert und überprüft, ob jeder eingereichte Block-Header mit einem gültigen Zertifikat versehen ist, das beweist, dass der Block-Header vom Konsens der oberen Kette akzeptiert wurde, und fügt diesen Block-Header der Liste hinzu.

Anwendungen können darauf aufbauend Funktionen wie Ein- und Auszahlungen von Token implementieren. Sobald eine solche Bridge eingerichtet ist, bietet sie dann irgendeine der zuvor erwähnten Sicherheitsgarantien für Vermögenswerte?

Bis jetzt noch nicht! Es gibt zwei Gründe:

1. Wir überprüfen die Signaturen der Blöcke, aber nicht, ob die Statusübergänge korrekt sind. Wenn Sie also einen auf Ethereum ausgegebenen Vermögenswert in die obere Kette einzahlen und die Validatoren der oberen Kette unehrlich werden, können sie einen ungültigen Statusübergang signieren und diese Vermögenswerte stehlen;

2. Die obere Kette kann Ethereum immer noch nicht lesen. Daher können Sie keine nativen Ethereum-Vermögenswerte in die obere Kette einzahlen, es sei denn, Sie verlassen sich auf andere (möglicherweise unsichere) Drittanbieter-Bridges.

Jetzt bauen wir die Bridge als Validierungs-Bridge: Sie überprüft nicht nur den Konsens, sondern auch, ob der Status jedes neuen Blocks mit einem ZK-SNARK-Beweis korrekt berechnet wurde.

Sobald dieser Schritt abgeschlossen ist, können die Validatoren der oberen Kette Ihre Gelder nicht mehr stehlen. Sie können einen Block mit nicht verfügbaren Daten veröffentlichen und so alle Auszahlungen blockieren, aber sie können die Gelder nicht stehlen (es sei denn, sie versuchen, durch Erpressung der Nutzer an die Daten zu kommen, die Auszahlungen ermöglichen). Das entspricht dem Sicherheitsmodell von Validium.

Wir haben jedoch das zweite Problem noch nicht gelöst: Die obere Kette kann Ethereum-Daten nicht lesen. Um dies zu erreichen, müssen wir einen der beiden folgenden Ansätze wählen:

1. Einen Bridge-Contract in der oberen Kette platzieren, der bereits finalisierte Ethereum-Blöcke überprüft;

2. In jedem Block der oberen Kette einen Hash eines aktuellen Ethereum-Blocks einfügen und eine Fork-Choice-Regel anwenden, um die Hash-Verknüpfung zu erzwingen. Das heißt, ein Block der oberen Kette, der mit einem Ethereum-Block außerhalb der Hauptkette verknüpft ist, ist selbst außerhalb der Hauptkette. Wenn der Ethereum-Block, mit dem ein Block der oberen Kette verknüpft ist, zunächst auf der Hauptkette ist, später aber nicht mehr, muss auch der Block der oberen Kette außerhalb der Hauptkette sein.

Diese violetten Verbindungen können Hash-Verknüpfungen oder Bridge-Contracts sein, die den Ethereum-Konsens überprüfen

Reicht das aus? Tatsächlich noch nicht, denn es gibt einige kleine Randfälle:

1. Was passiert, wenn Ethereum einen 51%-Angriff erleidet?

2. Wie geht man mit Hard Fork Upgrades von Ethereum um?

3. Wie geht man mit Hard Fork Upgrades Ihrer eigenen Chain um?

Ein 51%-Angriff auf Ethereum hätte ähnliche Folgen wie ein 51%-Angriff auf die obere Kette, aber umgekehrt. Ein Hard Fork von Ethereum könnte die Ethereum-Bridge innerhalb der oberen Kette unbrauchbar machen. Eine soziale Verpflichtung, d.h. wenn Ethereum einen bereits finalisierten Block zurücksetzt, wird auch zurückgesetzt, und wenn Ethereum einen Hard Fork durchführt, wird auch ein Hard Fork durchgeführt, ist die sauberste Lösung für dieses Problem.

Eine solche Verpflichtung muss in der Praxis möglicherweise nie wirklich umgesetzt werden: Wenn die Governance der oberen Kette Beweise für einen möglichen Angriff oder Hard Fork findet, kann sie aktiviert werden, und nur wenn die Governance versagt, muss ein Hard Fork der oberen Kette durchgeführt werden.

Für das dritte Problem ist die einzige praktikable Antwort, eine Art Governance auf Ethereum einzurichten, die es dem Bridge-Contract auf Ethereum ermöglicht, über Hard Fork Upgrades der oberen Kette informiert zu werden.

Zusammenfassung: Eine bidirektionale Validierungs-Bridge reicht fast aus, um eine Blockchain zu einem Validium zu machen. Das wichtigste verbleibende Element ist eine soziale Verpflichtung, dass im Falle von Anomalien bei Ethereum, die dazu führen, dass der Bridge-Contract nicht mehr funktioniert, die andere Blockchain mit einem Hard Fork reagiert.

Fazit

„Verbindung zu Ethereum“ hat zwei entscheidende Dimensionen:

1. Sicherheit bei der Auszahlung auf Ethereum;

2. Sicherheit beim Lesen von Ethereum.

Beide sind sehr wichtig und haben unterschiedliche Überlegungen. In beiden Fällen gibt es ein Kontinuum:

Beachten Sie, dass jede Dimension zwei verschiedene Messgrößen hat (tatsächlich gibt es vier Dimensionen): Die Auszahlungssicherheit kann gemessen werden durch (i) das Sicherheitsniveau und (ii) wie viele Nutzer oder Anwendungsfälle vom höchsten Sicherheitsniveau profitieren;

Die Lesesicherheit kann gemessen werden durch (i) wie schnell die Verbindung Ethereum-Blöcke lesen kann, insbesondere den Unterschied zwischen finalisierten und beliebigen Blöcken, und (ii) das Maß an sozialer Verpflichtung der Verbindung bei der Behandlung von Randfällen wie 51%-Angriffen und Hard Forks.

In vielen Bereichen dieses Designraums gibt es wertvolle Projekte. Für einige Anwendungen sind hohe Sicherheit und enge Verbindung entscheidend. Für andere Anwendungen kann man zugunsten größerer Skalierbarkeit lockerere Bedingungen akzeptieren. In vielen Fällen ist es optimal, heute mit lockereren Bedingungen zu beginnen und im Laufe des nächsten Jahrzehnts mit dem technologischen Fortschritt schrittweise zu einer engeren Kopplung überzugehen.