Autor: Vitalik Buterin
Zusammengestellt von: Peng Sun, Foresight News
Ursprünglicher Link: https://vitalik.eth.limo/general/2024/05/23/l2exec.html
Vor zweieinhalb Jahren habe ich im Artikel „Endgame“ erwähnt, dass die verschiedenen Entwicklungspfade der Blockchain in der Zukunft zumindest technisch sehr ähnlich aussehen. In beiden Fällen gibt es eine große Anzahl von Transaktionen in der Kette, und die Verarbeitung dieser Transaktionen erfordert: (1) viel Rechenaufwand; (2) viel Datenbandbreite. Gewöhnliche Ethereum-Knoten (wie der 2-TB-Reth-Archivknoten, der jetzt auf meinem Computer läuft) reichen selbst mit leistungsstarker Software-Engineering-Leistung und Verkle-Bäumen nicht aus, um die riesige Datenmenge und Berechnung direkt zu überprüfen. Im Gegensatz dazu wird in den beiden Schemata „L1-Sharding“ und Rollup-zentriert ZK-SNARK zur Überprüfung der Berechnungen und DAS zur Überprüfung der Datenverfügbarkeit verwendet. Ob L2-Sharding oder Rollup, das DAS ist dasselbe und die ZK-SNARKs-Technologie ist dieselbe. Sie sind sowohl intelligenter Vertragscode als auch eine Funktion des Protokolls. Im eigentlichen technischen Sinne ist Ethereum Sharding und Rollup ist Sharding.
Da stellt sich natürlich die Frage: Was ist der Unterschied zwischen den beiden? Eine davon ist, dass die Folgen von Code-Schwachstellen unterschiedlich sind: Beim Rollup werden Token gestohlen, beim Sharding wird der Konsens gebrochen. Ich erwarte jedoch, dass mit der Stabilisierung des Protokolls und der Verbesserung der formalen Verifizierungstechniken die Auswirkungen von Code-Schwachstellen immer geringer werden. Welche weiteren Unterschiede bestehen zwischen diesen beiden potenziell langfristigen Optionen?
Vielfalt in Ausführungsumgebungen
Eine Idee, die wir 2019 in Ethereum kurz besprochen haben, waren Ausführungsumgebungen. Im Wesentlichen wird Ethereum verschiedene „Zonen“ haben, die unterschiedliche Regeln für Konten (einschließlich völlig unterschiedlicher Methoden wie UTXO), die Funktionsweise der virtuellen Maschine und andere Funktionen haben können. Dies ermöglicht eine Methodenvielfalt in verschiedenen Teilen des Stapels, die schwer zu erreichen wäre, wenn Ethereum versuchen würde, mehrere Funktionen in einer zusammenzufassen.
Am Ende haben wir einige der ehrgeizigeren Pläne aufgegeben und nur das EVM behalten. Man kann jedoch sagen, dass Ethereum L2 (einschließlich Rollups, Valdiums und Plasmas) letztendlich als Ausführungsumgebung fungiert. Derzeit konzentrieren wir uns häufig auf das EVM-Äquivalent L2, ignorieren jedoch die Vielfalt, die viele andere Methoden mit sich bringen:
● Arbitrum Stylus, das zusätzlich zu EVM ein zweites WASM-basiertes Oracle hinzufügt;
● Fuel, das eine UTXO-basierte Architektur ähnlich wie Bitcoin verwendet (jedoch vollständiger);
● Aztec, das ein neues Sprach- und Programmierparadigma einführt, das auf datenschutzschützenden Smart Contracts basiert, die auf ZK-SNARKs basieren.
UTXO-basierte Architektur, Quelle: Fuel-Dokumentation
Wir können versuchen, die EVM in eine supervirtuelle Maschine zu integrieren, die alle möglichen Paradigmen abdeckt, aber dadurch wird die Effizienz jeder Funktion erheblich verringert. Es ist besser, diese Plattformen ihre professionellen Aufgaben erledigen zu lassen.
Sicherheitskompromiss: Skalierung und Transaktionsgeschwindigkeit
Ethereum L1 bietet eine sehr starke Sicherheit. Wenn der letzte abgeschlossene Block auf L1 bestimmte Daten enthält, wird der gesamte Konsens (einschließlich des sozialen Konsenses im Extremfall) hart daran arbeiten, sicherzustellen, dass diese Daten nicht geändert werden und dass eine durch diese Daten ausgelöste Ausführung nicht rückgängig gemacht wird weiterhin Zugriff auf die Daten haben. Um diese Sicherheitsgarantie zu erreichen, ist Ethereum L1 bereit, einen hohen Aufwand in Kauf zu nehmen. Zum Zeitpunkt des Schreibens sind die Transaktionsgebühren relativ niedrig: Layer2 berechnet weniger als 1 Cent pro Transaktion, und selbst auf L1 kostet eine einfache ETH-Überweisung weniger als 1 US-Dollar. Wenn die Technologie schnell genug voranschreitet und das Wachstum des verfügbaren Blockraums mit der Nachfrage Schritt hält, können diese Gebühren in Zukunft niedrig bleiben, aber möglicherweise nicht. Selbst 0,01 US-Dollar pro Transaktion sind für viele nichtfinanzielle Anwendungen wie soziale Medien oder Spiele zu hoch.
Aber Social Media und Gaming erfordern nicht dasselbe Sicherheitsmodell wie L1. Wenn jemand eine Million Dollar bezahlen kann, um seinen Rekord, eine Schachpartie verloren zu haben, rückgängig zu machen oder den Eindruck zu erwecken, dass einer Ihrer Tweets drei Tage nach seiner tatsächlichen Veröffentlichung gepostet wurde, ist das in Ordnung. Daher sollten diese Apps nicht die gleichen Sicherheitskosten zahlen. L2-Lösungen erreichen dies, indem sie eine Reihe von Datenverfügbarkeitsmethoden unterstützen, von Rollups über Plasma bis hin zu Validien.
Ein weiterer Kompromiss entsteht bei der Frage der Vermögensübertragung von L2 auf L2. Ich gehe davon aus, dass in den nächsten 5 bis 10 Jahren alle Rollups ZK-Rollups sein werden und hocheffiziente Proof-Systeme wie Binius und Circle STARKs mit Lookups, gepaart mit einer Proof-Aggregationsschicht, es L2 ermöglichen werden, in jedem Rollup den endgültigen Zustandsstamm bereitzustellen Slot möglich werden. Derzeit können wir Optimistic Rollup und ZK Rollup jedoch nur kompliziert kombinieren und unterschiedliche Proof-Zeitfenster verwenden. Wenn wir Ausführungs-Sharding im Jahr 2021 implementieren, wird das Sicherheitsmodell, um die Shards ehrlich zu halten, Optimitic Rollup und nicht ZK sein, sodass L1 die komplexe betrugssichere Logik des On-Chain-Systems verwalten muss und die Auszahlungszeiten bis zu a betragen werden Woche, um Vermögenswerte zwischen Shards zu übertragen. Aber wie Codefehler denke ich, dass dieses Problem letztendlich vorübergehender Natur ist.
Die Transaktionsgeschwindigkeit ist der dritte und dauerhaftere Aspekt des Sicherheitskompromisses. Ethereum produziert alle 12 Sekunden Blöcke und kann nicht schneller sein, sonst ist es zu zentralisiert. Viele L2s erwägen jedoch die Komprimierung der Blockzeiten auf Hunderte von Millisekunden. 12 Sekunden sind nicht schlecht: Im Durchschnitt müssen Benutzer nach dem Absenden einer Transaktion etwa 6 bis 7 Sekunden warten, um in einen Block aufgenommen zu werden (und nicht nur 6 Sekunden, da sie im nächsten Block möglicherweise nicht enthalten sind). Dies ist vergleichbar mit der Wartezeit, die ich beim Bezahlen mit Kreditkarte abwarten muss. Viele Anwendungen erfordern jedoch höhere Geschwindigkeiten, und L2 kann diese liefern.
Um es schneller zu machen, verfügt L2 über einen Vorbestätigungsmechanismus: Die eigenen Validatoren von L2 versprechen digital, eine Transaktion zu einem bestimmten Zeitpunkt einzuschließen, und sie werden bestraft, wenn die Transaktion nicht einbezogen wird. Der StakeSure-Mechanismus fördert diesen Mechanismus weiter.
L2-Vorbestätigung
Jetzt können wir versuchen, alle diese Funktionen in L1 zu implementieren. L1 kann ein System mit „schneller Vorbestätigung“ und „langsamer Endbestätigung“ umfassen. Es kann verschiedene Shards mit unterschiedlichen Sicherheitsstufen enthalten. Allerdings erhöht sich dadurch die Komplexität des Protokolls. Darüber hinaus besteht bei der Ausführung der gesamten Arbeit in L1 die Gefahr, dass der Konsens überlastet wird, da viele Ansätze mit größerem Maßstab oder höherem Durchsatz ein höheres Zentralisierungsrisiko bergen oder stärkere Formen der „Governance“ erfordern, wenn sie in L1 durchgeführt werden. Die Auswirkungen dieser stärkeren Anforderungen werden sich durchsetzen sonstige Vertragsbestandteile. Ethereum kann diese Risiken weitgehend vermeiden, indem es einen Kompromiss mit L2 bietet.
Vorteile von Layer 2 für Organisationen und Kultur
Stellen Sie sich ein Land vor, das in zwei Teile geteilt wird, wobei die eine Hälfte zu einem kapitalistischen Land und die andere Hälfte zu einem stark von der Regierung dominierten Land wird (im Gegensatz zu dem, was in der Realität geschieht, nehmen wir in diesem Gedankenexperiment an, dass dies nicht das Ergebnis eines traumatischen Krieges ist). Aber eines Tages erscheint die Grenze natürlich und das war's. Im kapitalistischen Teil bestehen Restaurants alle aus unterschiedlichen dezentralen Eigentumsverhältnissen, Blockchain und Stimmrechten. In einem von der Regierung dominierten Land sind sie alle Zweige der Regierung, genau wie die Polizei. Am ersten Tag wird sich nicht viel ändern. Die Menschen werden weitgehend bestehenden Gewohnheiten folgen, und was funktioniert und was nicht, hängt von technischen Gegebenheiten wie Arbeitsfähigkeiten und Infrastruktur ab. Nach einem Jahr sieht man jedoch enorme Veränderungen, da unterschiedliche Anreiz- und Kontrollstrukturen zu enormen Verhaltensänderungen führen, die sich darauf auswirken, wer kommt und bleibt, was gebaut wird, was instandgehalten wird und was aufgegeben wird.
Die Theorie der industriellen Organisation hat zu diesen Unterscheidungen viel zu sagen: Sie spricht nicht nur über den Unterschied zwischen einer staatlich geführten Wirtschaft und einer kapitalistischen Wirtschaft, sondern auch über eine Wirtschaft, die von großen Franchise-Unternehmen dominiert wird, und eine Wirtschaft, in der jeder Supermarkt von einem geführt wird unabhängiger Unternehmer. Ich denke, der Unterschied zwischen einem L1-zentrierten Ökosystem und einem L2-zentrierten Ökosystem ist ähnlich.
Es gibt ein großes Problem mit der „Kernentwickler verwalten alles“-Architektur
Als L2-zentriertes Ökosystem glaube ich, dass die Hauptvorteile von Ethereum folgende sind:
Da es sich bei Ethereum um ein L2-zentriertes Ökosystem handelt, haben Sie die Freiheit, unabhängig ein Sub-Ökosystem mit eigenen einzigartigen Merkmalen aufzubauen und gleichzeitig Teil des größeren Ethereum zu sein.
Wenn Sie gerade einen Ethereum-Client erstellen, sind Sie Teil des größeren Ethereum, und obwohl Sie Raum für Innovationen haben, ist dieser bei weitem nicht so gut wie L2. Und wenn Sie eine völlig unabhängige Kette aufbauen, haben Sie viel Raum für Kreativität, verlieren aber auch die Vorteile gemeinsamer Sicherheit und gemeinsamer Netzwerkeffekte. L2 ist eine gute Balance.
Es bietet nicht nur technische Möglichkeiten zum Ausprobieren neuer Ausführungsumgebungen und Sicherheitskompromisse, die Skalierung, Flexibilität und Geschwindigkeit ermöglichen, sondern bietet auch einen Anreizmechanismus, der sowohl Entwickler zum Erstellen und Warten anregt, als auch Community-Unterstützung.
Die Tatsache, dass jedes L2 isoliert ist, bedeutet auch, dass die Bereitstellung neuer Methoden ohne Erlaubnis erfolgt: Es besteht keine Notwendigkeit, alle Kernentwickler davon zu überzeugen, dass Ihre neue Methode für den Rest der Kette „sicher“ ist. Wenn Ihr L2 ausfällt, liegt das in Ihrer Verantwortung. Jeder kann auf eine seltsame Idee kommen (z. B. den Plasma-Ansatz von Intmax), und selbst wenn die Kernentwickler von Ethereum überhaupt nicht darauf achten, können sie weiter daran arbeiten und sie schließlich einsetzen. Dies ist bei L1-Funktionen und der Vorkompilierung nicht der Fall, und selbst in Ethereum ist der Erfolg oder Misserfolg der L1-Entwicklung oft in größerem Maße politisch, als uns lieb ist. Unabhängig davon, was theoretisch gebaut werden kann, werden die unterschiedlichen Anreize, die ein L1-zentriertes Ökosystem und ein L2-zentriertes Ökosystem schaffen, letztendlich einen gravierenden Einfluss darauf haben, was tatsächlich gebaut wird, das Qualitätsniveau und die Reihenfolge, in der es gebaut wird .
Vor welchen Herausforderungen steht das L2-zentrierte Ökosystem von Ethereum?
Mit der L1 + L2-Architektur stimmt etwas furchtbar nicht. Bildquelle: Reddit
Dieser L2-zentrierte Ansatz steht vor einer zentralen Herausforderung, mit der L1-zentrierte Ökosysteme selten konfrontiert sind: Koordination. Mit anderen Worten: Obwohl Ethereum über viele L2s verfügt, besteht die Herausforderung darin, dafür zu sorgen, dass es sich immer noch wie „Ethereum“ anfühlt und die Netzwerkeffekte von Ethereum anstelle von N unabhängigen Ketten aufweist. Heute ist diese Situation in vielerlei Hinsicht unbefriedigend:
● Cross-Chains zwischen L2 erfordern normalerweise eine zentralisierte Cross-Chain-Brücke, was für normale Benutzer sehr kompliziert ist. Wenn Sie über Optimism-Tokens verfügen, können Sie die Arbitrum-Adresse einer anderen Person nicht in Ihr Wallet einfügen, um Geld zu senden.
● Sowohl für persönliche Smart-Contract-Wallets als auch für Organisations-Wallets (einschließlich DAO) ist die Unterstützung für kettenübergreifende Smart-Contract-Wallets nicht sehr gut. Wenn Sie den Schlüssel auf einem L2 ändern, müssen Sie auch den Schlüssel auf jedem anderen L2 ändern.
● Eine dezentrale Verifizierungsinfrastruktur fehlt oft. Ethereum fängt endlich an, anständige Light-Kunden wie Helios zu bekommen. Es macht jedoch keinen Sinn, wenn alle Aktivitäten in L2 stattfinden und ein eigenes zentralisiertes RPC erforderlich ist. Im Prinzip ist es nicht schwierig, einen Light-Client für L2 zu erstellen, sobald man den Ethereum-Blockheader hat, aber in der Praxis wird diesem Punkt zu wenig Aufmerksamkeit geschenkt;
Die Community arbeitet hart daran, diese drei Bereiche zu verbessern. Für den kettenübergreifenden Token-Austausch ist der ERC-7683-Standard eine neue Lösung. Im Gegensatz zu bestehenden „zentralisierten kettenübergreifenden Brücken“ gibt es keine festen zentralisierten Knoten, Token oder Governance. Bei Cross-Chain-Konten besteht der Ansatz der meisten Wallets darin, Cross-Chain-Wiedergabenachrichten zu verwenden, um Schlüssel kurzfristig und Keystore-Rollups langfristig zu aktualisieren. Es tauchen zunehmend Light-Clients für L2 auf, beispielsweise Beerus für Starknet. Darüber hinaus haben die jüngsten Verbesserungen des Benutzererlebnisses durch Wallets der nächsten Generation grundlegendere Probleme gelöst, z. B. dass Benutzer das Netzwerk nicht manuell wechseln müssen, um auf DApps zuzugreifen.
Rabby hat einen umfassenden Überblick über die Vermögensbestände mehrerer Ketten, was mit früheren Wallets nicht möglich war!
Es ist jedoch wichtig zu erkennen, dass es L2-zentrierten Ökosystemen schwer fällt, sich einigermaßen zu koordinieren. Weil es für eine einzelne L2 keinen natürlichen wirtschaftlichen Anreiz gibt, die Infrastruktur für die Koordinierung aufzubauen: Kleine L2s werden dies nicht tun, weil sie nur einen kleinen Teil der Vorteile erhalten wollen, und große L2s werden es auch nicht tun, weil sie es können Profitieren Sie von der Stärkung ihrer eigenen lokalen Netzwerkeffekte. Wenn jeder L2 nur an sich selbst denkt und niemand darüber nachdenkt, wie er in das breitere Ethereum-System passt, dann werden wir scheitern, genau wie die städtische Utopie in den Bildern ein paar Absätze oben.
Es ist schwer zu sagen, dass es eine perfekte Lösung für dieses Problem gibt. Ich kann nur sagen, dass das Ökosystem besser erkennen muss, dass die Cross-L2-Infrastruktur ebenso eine Art Ethereum-Infrastruktur ist wie L1-Clients, Entwicklungstools und Programmiersprachen und daher wertgeschätzt und finanziert werden sollte. Wir haben die Protocol Guild, vielleicht brauchen wir die Basic Infrastructure Guild.
Zusammenfassen
In verschiedenen öffentlichen Diskussionen werden „L2“ und „Sharding“ oft als zwei gegensätzliche Strategien für den Blockchain-Ausbau angesehen. Wenn Sie sich jedoch die zugrunde liegende Technologie ansehen, werden Sie auf ein Rätsel stoßen: Die tatsächlich zugrunde liegenden Skalierungsmethoden sind genau die gleichen. Ob es sich um Daten-Sharding, Betrugsvalidatoren oder ZK-SNARK-Validatoren handelt oder um Lösungen, die über „Rollups, Shards“ kommunizieren, der Hauptunterschied besteht darin: Wer ist für den Aufbau und die Aktualisierung dieser Komponenten verantwortlich und wie viel Autonomie haben sie?
Ein L2-zentriertes Ökosystem ist Sharding im eigentlichen technischen Sinne, aber innerhalb des Shardings können Sie Ihre eigenen Shards mit Ihren eigenen Regeln erstellen. Dies ist sehr kraftvoll, unbegrenzte Kreativität und kann viele unabhängige Innovationen bewirken. Es bringt aber auch einige zentrale Herausforderungen mit sich, insbesondere im Hinblick auf die Koordination. Damit ein L2-zentriertes Ökosystem wie Ethereum erfolgreich sein kann, muss es diese Herausforderungen verstehen und sie direkt angehen, um möglichst viele Vorteile eines L1-zentrierten Ökosystems zu nutzen und das Beste aus beiden zu erreichen.