Vitaliks neuer Artikel: Die mögliche Zukunft von Ethereum, der Anstieg

Originaltitel: Mögliche Zukunftsszenarien für das Ethereum-Protokoll, Teil 2: Der Anstieg

Originalautor: Vitalik Buterin

Originalübersetzung: Karen, Foresight News

Besonderer Dank geht an Justin Drake, Francesco, Hsiao-wei Wang, @antonttc und Georgios Konstantopoulos.

Ursprünglich gab es in der Ethereum-Roadmap zwei Skalierungsstrategien. Eine (siehe ein frühes Dokument aus dem Jahr 2015) war „Sharding“: Jeder Knoten muss nur einen kleinen Teil der Transaktionen verifizieren und speichern, anstatt alle Transaktionen in der Kette zu verifizieren und zu speichern. Jedes andere Peer-to-Peer-Netzwerk (wie BitTorrent) funktioniert auf diese Weise, also können wir Blockchain natürlich auf die gleiche Weise funktionieren lassen. Die andere sind Layer2-Protokolle: Diese Netzwerke werden auf Ethereum aufgesetzt, sodass es vollständig von dessen Sicherheit profitieren kann, während die meisten Daten und Berechnungen außerhalb der Hauptkette verbleiben. Layer2-Protokolle beziehen sich auf State Channels im Jahr 2015, Plasma im Jahr 2017 und dann Rollup im Jahr 2019. Rollup ist leistungsfähiger als State Channels oder Plasma, erfordert jedoch eine große Datenbandbreite in der Kette. Glücklicherweise hatte die Sharding-Forschung bis 2019 das Problem der Verifizierung der „Datenverfügbarkeit“ im großen Maßstab gelöst. Infolgedessen wurden die beiden Pfade zusammengeführt und wir erhielten eine Rollup-zentrierte Roadmap, die bis heute die Skalierungsstrategie von Ethereum darstellt.

The Surge, Roadmap-Ausgabe 2023

Die Rollup-zentrierte Roadmap schlägt eine einfache Arbeitsteilung vor: Ethereum L1 konzentriert sich darauf, eine leistungsstarke und dezentrale Basisschicht zu werden, während L2 die Aufgabe übernimmt, das Ökosystem bei der Skalierung zu unterstützen. Dieses Muster ist in der Gesellschaft allgegenwärtig: Das Gerichtssystem (L1) existiert nicht, um superschnell und effizient zu sein, sondern um Verträge und Eigentumsrechte zu schützen, und Unternehmer (L2) bauen auf dieser soliden Grundlage auf, um die Menschheit (buchstäblich und metaphorisch) zum Mars zu führen.

In diesem Jahr hat die Rollup-zentrierte Roadmap wichtige Ergebnisse erzielt: Mit der Einführung von EIP-4844-Blobs hat sich die Datenbandbreite von Ethereum L1 erheblich erhöht, und mehrere Ethereum Virtual Machine (EVM)-Rollups haben die erste Phase erreicht. Jeder L2 existiert als „Shard“ mit seinen eigenen internen Regeln und seiner eigenen Logik, und die Vielfalt und Diversifizierung der Shard-Implementierungen ist nun Realität. Aber wie wir gesehen haben, bringt dieser Weg auch einige einzigartige Herausforderungen mit sich. Daher besteht unsere Aufgabe nun darin, die Rollup-zentrierte Roadmap abzuschließen und diese Probleme zu lösen, während gleichzeitig die Robustheit und Dezentralisierung erhalten bleiben, die für Ethereum L1 einzigartig sind.

Der Aufschwung: Schlüsselziele

1. In Zukunft kann Ethereum durch L2 mehr als 100.000 TPS erreichen;

2. Die Dezentralisierung und Robustheit von L1 aufrechterhalten;

3. Zumindest einige L2s erben vollständig die Kerneigenschaften von Ethereum (Vertrauenslosigkeit, Offenheit und Antizensur);

4. Ethereum sollte sich wie ein einheitliches Ökosystem anfühlen, nicht wie 34 verschiedene Blockchains.

In diesem Kapitel

1. Skalierbarkeitsdreieck-Paradoxon

2. Weitere Fortschritte bei der Stichprobennahme zur Datenverfügbarkeit

3. Datenkomprimierung

4. Generalisiertes Plasma

5. Ausgereiftes L2-Beweissystem

6. Verbesserungen der Cross-L2-Interoperabilität

7. Skalierung der Ausführung auf L1

Paradox des Skalierbarkeitsdreiecks

Das Skalierbarkeitsdreieck-Paradoxon ist eine 2017 vorgeschlagene Idee, die von einem Widerspruch zwischen drei Eigenschaften der Blockchain ausgeht: Dezentralisierung (genauer gesagt: niedrige Kosten für den Betrieb eines Knotens), Skalierbarkeit (hohe Anzahl verarbeiteter Transaktionen) und Sicherheit (ein Angreifer muss einen großen Teil der Knoten im Netzwerk kompromittieren, um eine einzige Transaktion fehlschlagen zu lassen).

Es ist erwähnenswert, dass das Trilemma kein Theorem ist und der Beitrag, der das Trilemma vorstellt, keinen mathematischen Beweis enthält. Er liefert jedoch ein heuristisches mathematisches Argument: Wenn ein dezentralisierungsfreundlicher Knoten (wie ein Verbraucher-Laptop) N Transaktionen pro Sekunde verifizieren kann und Sie eine Kette haben, die k*N Transaktionen pro Sekunde verarbeitet, dann (i) kann jede Transaktion nur von 1/k Knoten gesehen werden, was bedeutet, dass ein Angreifer nur wenige Knoten kompromittieren muss, um eine bösartige Transaktion durchzulassen, oder (ii) Ihre Knoten werden mächtig und Ihre Kette wird nicht dezentralisiert. Der Zweck dieses Beitrags war nie, zu beweisen, dass das Durchbrechen des Trilemmas unmöglich ist; er sollte vielmehr zeigen, dass das Durchbrechen des Trilemmas schwierig ist und ein Denken über den Tellerrand hinaus erfordert, das durch das Argument irgendwie impliziert wird.

Einige Hochleistungsketten haben jahrelang oft behauptet, sie hätten das Trilemma gelöst, ohne ihre Architektur grundlegend zu ändern, normalerweise durch die Anwendung von Software-Engineering-Tricks zur Optimierung der Knoten. Dies war schon immer irreführend, und das Ausführen von Knoten auf diesen Ketten ist viel schwieriger als das Ausführen von Knoten auf Ethereum. In diesem Beitrag wird untersucht, warum dies der Fall ist und warum L1-Client-Software-Engineering allein Ethereum nicht skalieren kann.

Allerdings löst Data Availability Sampling in Kombination mit SNARKs das Trilemma: Es ermöglicht Clients, zu überprüfen, ob eine bestimmte Datenmenge verfügbar ist und eine bestimmte Anzahl von Rechenschritten korrekt ausgeführt wurde, während nur eine kleine Datenmenge heruntergeladen und nur sehr wenige Berechnungen durchgeführt werden. SNARKs sind vertrauenslos. Data Availability Sampling hat ein subtiles Few-of-N-Vertrauensmodell, behält aber die grundlegende Eigenschaft nicht skalierbarer Ketten bei, nämlich dass selbst ein 51%-Angriff nicht dazu führen kann, dass fehlerhafte Blöcke vom Netzwerk akzeptiert werden.

Ein weiterer Ansatz zur Lösung des Trilemmas ist die Plasma-Architektur, die clevere Techniken nutzt, um die Verantwortung für die Überwachung der Datenverfügbarkeit auf anreizkompatible Weise auf die Benutzer zu übertragen. In den Jahren 2017 bis 2019, als wir nur Betrugsnachweise als Mittel zur Skalierung der Rechenleistung hatten, war Plasma in Bezug auf die sichere Ausführung sehr eingeschränkt, aber mit der Popularität von SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments) ist die Plasma-Architektur für ein breiteres Spektrum von Anwendungsfällen praktikabler geworden als je zuvor.

Weitere Fortschritte bei der Stichprobennahme zur Datenverfügbarkeit

Welches Problem lösen wir?

Am 13. März 2024, wenn das Dencun-Upgrade live geht, wird die Ethereum-Blockchain 3 ~125 kB Blobs pro 12-Sekunden-Slot oder ~375 kB verfügbare Datenbandbreite pro Slot haben. Unter der Annahme, dass Transaktionsdaten direkt in der Kette veröffentlicht werden, beträgt eine ERC20-Übertragung etwa 180 Bytes, sodass die maximale TPS für Rollup auf Ethereum beträgt: 375.000 / 12 / 180 = 173,6 TPS

Wenn wir Ethereums Calldata hinzufügen (theoretisches Maximum: 30 Millionen Gas pro Slot / 16 Gas pro Byte = 1.875.000 Bytes pro Slot), ergibt das 607 TPS. Mit PeerDAS könnte die Anzahl der Blobs auf 8-16 steigen, was 463-926 TPS für Calldata ergeben würde.

Dies ist eine deutliche Verbesserung gegenüber Ethereum L1, aber nicht genug. Wir wollen mehr Skalierbarkeit. Unser mittelfristiges Ziel sind 16 MB pro Slot, was in Kombination mit Verbesserungen bei der Rollup-Datenkomprimierung ~58.000 TPS ergeben würde.

Was ist das? Wie funktioniert es?

PeerDAS ist eine relativ einfache Implementierung von „1D-Sampling“. In Ethereum ist jeder Blob ein 4096-Grad-Polynom über einem 253-Bit-Primärkörper. Wir senden Anteile des Polynoms, wobei jeder Anteil 16 Auswertungen an 16 benachbarten Koordinaten von insgesamt 8192 Koordinaten enthält. Von diesen 8192 Auswertungen können beliebige 4096 (gemäß den derzeit vorgeschlagenen Parametern: beliebige 64 der 128 möglichen Samples) den Blob wiederherstellen.

PeerDAS funktioniert, indem jeder Client eine kleine Anzahl von Subnetzen abhört, wobei das i-te Subnetz die i-te Probe eines beliebigen Blobs sendet und die benötigten Blobs in anderen Subnetzen anfordert, indem es Peers im globalen P2P-Netzwerk fragt (die verschiedene Subnetze abhören). Eine konservativere Version, SubnetDAS, verwendet nur den Subnetzmechanismus ohne die zusätzliche Ebene der Peer-Anfrage. Der aktuelle Vorschlag sieht vor, dass Knoten, die am Proof of Stake teilnehmen, SubnetDAS verwenden, während andere Knoten (d. h. Clients) PeerDAS verwenden.

Theoretisch können wir 1D-Sampling ziemlich skalieren: Wenn wir die maximale Anzahl von Blobs auf 256 erhöhen (bei einem Ziel von 128), können wir unser 16-MB-Ziel erreichen, mit 16 Samples pro Knoten beim Datenverfügbarkeits-Sampling * 128 Blobs * 512 Bytes pro Sample pro Blob = 1 MB Datenbandbreite pro Slot. Dies liegt gerade noch innerhalb unserer Toleranz: Es ist machbar, bedeutet aber, dass bandbreitenbeschränkte Clients kein Sampling durchführen können. Wir können dies etwas optimieren, indem wir die Anzahl der Blobs reduzieren und die Blob-Größe erhöhen, aber das macht die Rekonstruktion teurer.

Deshalb wollen wir letztendlich noch einen Schritt weitergehen und 2D-Sampling durchführen, bei dem nicht nur innerhalb von Blobs, sondern auch zwischen Blobs zufällige Stichproben entnommen werden. Unter Verwendung der von KZG versprochenen Linearitätseigenschaft wird die Menge der Blobs in einem Block um eine neue Menge virtueller Blobs erweitert, die dieselben Informationen redundant kodieren.

Wir wollen also letztendlich noch einen Schritt weitergehen und 2D-Sampling durchführen, das nicht nur innerhalb eines Blobs, sondern auch zwischen Blobs zufällige Sampling-Vorgänge vornimmt. Die von KZG versprochene lineare Eigenschaft wird verwendet, um die Menge der Blobs in einem Block um eine Liste neuer virtueller Blobs zu erweitern, die dieselben Informationen redundant kodieren.

2D-Sampling. Quelle: a16z crypto

Entscheidend ist, dass für die Skalierung von Rechenleistungsverpflichtungen keine Blobs erforderlich sind, sodass das Schema grundsätzlich für die verteilte Blockkonstruktion geeignet ist. Knoten, die tatsächlich Blöcke erstellen, müssen nur Blob-KZG-Verpflichtungen haben und können sich auf Data Availability Sampling (DAS) verlassen, um die Verfügbarkeit von Datenblöcken zu überprüfen. 1D Data Availability Sampling (1D DAS) ist ebenfalls von Natur aus für die verteilte Blockkonstruktion geeignet.

Welche Bezüge bestehen zur bestehenden Forschung?

1. Originalbeitrag zur Einführung in die Datenverfügbarkeit (2018): https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding

2. Folgepapier: https://arxiv.org/abs/1809.09044

3. Erläuterungspapier zu DAS, Paradigma: https://www.paradigm.xyz/2022/08/das

4. 2D-Verfügbarkeit mit KZG-Verpflichtungen: https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081

5. ethresear.ch PeerDAS: https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541 und Papier: https://eprint.iacr.org/2024/1362

6.EIP-7594: https://eips.ethereum.org/EIPS/eip-7594

SubnetDAS auf 7.ethresear.ch: https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169

8. Nuancen der Wiederherstellbarkeit bei 2D-Sampling: https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256

Was muss getan werden? Was sind die Kompromisse?

Als nächstes steht die Fertigstellung der Implementierung und Einführung von PeerDAS an. Danach wird die Anzahl der Blobs auf PeerDAS schrittweise erhöht, während das Netzwerk sorgfältig beobachtet und die Software verbessert wird, um die Sicherheit zu gewährleisten. In der Zwischenzeit erwarten wir mehr akademische Arbeit zur Formalisierung von PeerDAS und anderen DAS-Versionen und ihrer Interaktionen mit Problemen wie der Sicherheit von Fork-Choice-Regeln.

Im weiteren Verlauf wird noch mehr Arbeit nötig sein, um die ideale Version von 2D DAS zu bestimmen und seine Sicherheitseigenschaften zu beweisen. Wir hoffen auch, irgendwann von KZG zu einer Alternative zu wechseln, die quantensicher ist und kein vertrauenswürdiges Setup erfordert. Es ist derzeit nicht klar, welche Kandidaten für den Aufbau einer verteilten Blockchain geeignet sind. Selbst die teure „Brute-Force“-Technik, bei der rekursive STARKs verwendet werden, um Gültigkeitsnachweise für die Rekonstruktion von Zeilen und Spalten zu generieren, reicht nicht aus, da ein STARK zwar technisch gesehen O(log(n) * log(log(n)) Hashes groß ist (unter Verwendung von STIR), in der Praxis jedoch fast so groß ist wie der gesamte Blob.

Der langfristig realistische Weg, den ich sehe, ist:

1. Implementieren Sie ein ideales 2D-DAS;

2. Bleiben Sie bei 1D-DAS, opfern Sie die Effizienz der Abtastbandbreite und akzeptieren Sie eine niedrigere Datenobergrenze zugunsten von Einfachheit und Robustheit

3. (Harte Wende) DA aufgeben und Plasma vollständig als primäre L2-Architektur akzeptieren, auf die wir uns konzentrieren.

Beachten Sie, dass diese Option auch dann besteht, wenn wir uns entscheiden, die Ausführung direkt auf der L1-Ebene zu skalieren. Dies liegt daran, dass L1-Blöcke sehr groß werden, wenn die L1-Ebene eine große Anzahl von TPS verarbeiten kann, und Clients eine effiziente Möglichkeit wünschen, ihre Richtigkeit zu überprüfen. Daher müssen wir auf der L1-Ebene dieselben Techniken wie Rollup (z. B. ZK-EVM und DAS) verwenden.

Wie interagiert es mit dem Rest der Roadmap?

Wenn Datenkomprimierung implementiert wird, wird der Bedarf an 2D-DAS reduziert oder zumindest verzögert, und wenn Plasma weit verbreitet ist, wird der Bedarf weiter reduziert. DAS stellt auch Herausforderungen für Protokolle und Mechanismen zur verteilten Blockkonstruktion dar: Während DAS theoretisch für die verteilte Rekonstruktion geeignet ist, muss dies in der Praxis mit dem Vorschlag für eine Einschlussliste und dem ihn umgebenden Fork-Auswahlmechanismus kombiniert werden.

Datenkomprimierung

Welches Problem lösen wir?

Jede Transaktion in einem Rollup nimmt eine erhebliche Menge an Datenspeicherplatz in der Kette ein: Eine ERC20-Übertragung benötigt etwa 180 Byte. Dies begrenzt die Skalierbarkeit des Layer-Protokolls selbst bei idealer Datenverfügbarkeitsstichprobe. Bei 16 MB pro Slot erhalten wir:

16000000 / 12 / 180 = 7407 TPS

Was wäre, wenn wir nicht nur den Zähler, sondern auch den Nenner lösen könnten, sodass jede Transaktion in einem Rollup weniger Bytes in der Kette beansprucht?

Was ist das und wie funktioniert es?

Die beste Erklärung ist meiner Meinung nach dieses Bild von vor zwei Jahren:

Bei der Nullbyte-Komprimierung wird jede lange Folge von Nullbytes durch zwei Bytes ersetzt, die angeben, wie viele Nullbytes vorhanden sind. Wir gehen noch einen Schritt weiter und nutzen bestimmte Eigenschaften von Transaktionen aus:

Signaturaggregation: Wir wechseln von ECDSA-Signaturen zu BLS-Signaturen, die die Eigenschaft haben, dass mehrere Signaturen zu einer einzigen Signatur kombiniert werden können, die die Gültigkeit aller Originalsignaturen beweisen kann. In L1 werden BLS-Signaturen aufgrund des hohen Rechenaufwands der Überprüfung selbst mit Aggregation nicht berücksichtigt. In einer Umgebung wie L2, in der Daten knapp sind, ist es jedoch sinnvoll, BLS-Signaturen zu verwenden. Die Aggregationseigenschaft von ERC-4337 bietet eine Möglichkeit, diese Funktionalität zu erreichen.

Adressen durch Zeiger ersetzen: Wenn eine Adresse bereits verwendet wurde, können wir die 20-Byte-Adresse durch einen 4-Byte-Zeiger auf einen Speicherort im Verlauf ersetzen.

Benutzerdefinierte Serialisierung von Transaktionswerten – Die meisten Transaktionswerte haben sehr wenige Bits, beispielsweise werden 0,25 ETH als 250.000.000.000.000.000 Wei dargestellt. Dasselbe gilt für die maximale Grundgebühr und die Prioritätsgebühr. Daher können wir ein benutzerdefiniertes Dezimal-Gleitkommaformat verwenden, um die meisten Geldwerte darzustellen.

Welche Bezüge bestehen zur bestehenden Forschung?

1. Erkunden Sie sequence.xyz: https://sequence.xyz/blog/compressing-calldata

2. L2-Anrufdatenoptimierungsvertrag: https://github.com/ScopeLift/l2-optimizoooors

3. Rollups basierend auf Gültigkeitsnachweisen (auch bekannt als ZK-Rollups) veröffentlichen Zustandsunterschiede statt Transaktionen: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975

4. BLS Wallet – BLS-Aggregation über ERC-4337: https://github.com/getwax/bls-wallet

Was muss sonst noch getan werden und was sind die Kompromisse?

Als nächstes müssen wir vor allem das obige Schema tatsächlich umsetzen. Die wichtigsten Kompromisse sind:

1. Die Umstellung auf BLS-Signaturen erfordert viel Aufwand und verringert die Kompatibilität mit vertrauenswürdigen Hardwarechips, die die Sicherheit erhöhen können. Stattdessen können ZK-SNARK-Wrapper anderer Signaturschemata verwendet werden.

2. Dynamische Komprimierung (z. B. Ersetzen von Adressen durch Zeiger) komplizierteren Clientcode.

3. Die Veröffentlichung von Zustandsunterschieden in der Kette anstelle von Transaktionen verringert die Überprüfbarkeit und macht viele Softwareprogramme (z. B. Blockbrowser) funktionsunfähig.

Wie interagiert es mit anderen Teilen der Roadmap?

Die Einführung von ERC-4337 und die spätere Integration von Teilen davon in das L2-EVM kann die Bereitstellung der Aggregationstechnologie erheblich beschleunigen. Die Platzierung von Teilen von ERC-4337 auf L1 kann die Bereitstellung auf L2 beschleunigen.

Generalisiertes Plasma

Welches Problem lösen wir?

Selbst mit 16-MB-Blobs und Datenkomprimierung reichen 58.000 TPS möglicherweise nicht aus, um die Anforderungen von Verbraucherzahlungen, dezentralen sozialen Netzwerken oder anderen Bereichen mit hoher Bandbreite vollständig zu erfüllen, insbesondere wenn wir Datenschutzfaktoren berücksichtigen, die die Skalierbarkeit um das Drei- bis Achtfache reduzieren können. Für Anwendungsfälle mit hohem Transaktionsvolumen und geringem Wert besteht eine aktuelle Option darin, Validium zu verwenden, das Daten außerhalb der Kette speichert und ein interessantes Sicherheitsmodell anwendet: Betreiber können die Gelder der Benutzer nicht stehlen, aber sie können die Gelder aller Benutzer vorübergehend oder dauerhaft einfrieren. Aber wir können es besser machen.

Was ist das und wie funktioniert es?

Plasma ist eine Skalierungslösung, bei der ein Betreiber Blöcke außerhalb der Blockchain veröffentlicht und die Merkle-Wurzeln dieser Blöcke in die Blockchain einfügt (im Gegensatz zu Rollup, das die vollständigen Blöcke in die Blockchain einfügt). Für jeden Block sendet der Betreiber jedem Benutzer einen Merkle-Zweig, um nachzuweisen, was sich an den Assets dieses Benutzers geändert hat oder nicht. Benutzer können ihre Assets abheben, indem sie einen Merkle-Zweig bereitstellen. Wichtig ist, dass dieser Zweig nicht auf dem neuesten Stand verwurzelt sein muss. Daher können Benutzer auch bei einem Problem mit der Datenverfügbarkeit ihre Assets wiederherstellen, indem sie den neuesten ihnen verfügbaren Stand extrahieren. Wenn ein Benutzer einen ungültigen Zweig übermittelt (z. B. einen Asset abhebt, den er bereits an jemand anderen gesendet hat, oder der Betreiber ein Asset aus dem Nichts erstellt), kann das rechtliche Eigentum an dem Asset durch einen On-Chain-Challenge-Mechanismus bestimmt werden.

Plasma Cash-Kettendiagramm. Eine Transaktion, die Münze i ausgibt, wird an der i-ten Position im Baum platziert. In diesem Beispiel wissen wir, vorausgesetzt, dass alle vorherigen Bäume gültig sind, dass Eve derzeit Token 1 besitzt, David Token 4 und George Token 6.

Frühe Versionen von Plasma konnten nur den Anwendungsfall Zahlungen verarbeiten und konnten nicht effektiv weiter verallgemeinert werden. Wenn wir jedoch verlangen, dass jede Wurzel mit einem SNARK verifiziert wird, wird Plasma viel leistungsfähiger. Jedes Herausforderungsspiel kann erheblich vereinfacht werden, da wir die meisten möglichen Wege für den Betreiber ausschließen, zu betrügen. Gleichzeitig werden neue Wege eröffnet, die es der Plasma-Technologie ermöglichen, auf eine größere Bandbreite von Anlageklassen zu skalieren. Und schließlich können Benutzer, falls der Betreiber nicht betrügt, ihr Geld sofort abheben, ohne auf eine einwöchige Herausforderungsphase warten zu müssen.

Eine Möglichkeit, eine EVM-Plasmakette zu erstellen (nicht die einzige): Verwenden Sie ZK-SNARK, um einen parallelen UTXO-Baum zu erstellen, der die vom EVM vorgenommenen Balanceänderungen widerspiegelt und eine eindeutige Zuordnung des „gleichen Tokens“ zu verschiedenen Zeitpunkten im Verlauf definiert. Anschließend können Sie darauf eine Plasmastruktur aufbauen.

Eine wichtige Erkenntnis ist, dass Plasmasysteme nicht perfekt sein müssen. Selbst wenn Sie nur eine Teilmenge von Vermögenswerten schützen können (z. B. nur Token, die in der letzten Woche nicht bewegt wurden), haben Sie den Status quo des aktuellen hyperskalierbaren EVM (d. h. Validium) erheblich verbessert.

Eine weitere Klasse von Strukturen ist ein hybrides Plasma/Rollup, wie beispielsweise Intmax. Diese Konstruktionen speichern sehr kleine Datenmengen pro Benutzer in der Kette (z. B. 5 Bytes) und erreichen dabei Eigenschaften, die irgendwo zwischen Plasma und Rollup liegen: Im Fall von Intmax erhalten Sie eine sehr hohe Skalierbarkeit und Privatsphäre, obwohl Sie selbst bei 16 MB theoretisch auf etwa 16.000.000 / 12 / 5 = 266.667 TPS beschränkt sind.

Welche Links gibt es zu bestehenden Forschungsarbeiten?

1. Original-Plasma-Papier: https://plasma.io/plasma-deprecated.pdf

2. Plasma-Bargeld: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298

3. Plasma-Cashflow: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#-Exit

4. Intmax (2023): https://eprint.iacr.org/2023/1082

Was muss noch getan werden? Was sind die Kompromisse?

Die verbleibende Hauptaufgabe besteht darin, Plasmasysteme in tatsächliche Produktionsanwendungen zu integrieren. Wie oben erwähnt, ist „Plasma vs. Validium“ keine Entweder-oder-Entscheidung: Jedes Validium kann seine Sicherheitseigenschaften zumindest bis zu einem gewissen Grad verbessern, indem es Plasmafunktionen in seinen Exit-Mechanismus integriert. Die Forschung konzentriert sich darauf, die besten Eigenschaften für das EVM zu erhalten (in Bezug auf Vertrauensanforderungen, L1-Gaskosten im schlimmsten Fall und die Fähigkeit, DoS-Angriffen zu widerstehen) sowie alternative anwendungsspezifische Strukturen. Darüber hinaus weist Plasma im Vergleich zu Rollup eine höhere konzeptionelle Komplexität auf, die direkt durch die Erforschung und Entwicklung besserer allgemeiner Rahmenbedingungen angegangen werden muss.

Der Hauptnachteil von Plasmadesigns besteht darin, dass sie stärker vom Bediener abhängig und schwieriger zu erstellen sind, obwohl hybride Plasma/Rollup-Designs diese Schwäche im Allgemeinen vermeiden können.

Wie interagiert es mit anderen Teilen der Roadmap?

Je effektiver die Plasma-Lösung ist, desto weniger Druck besteht auf L1, über hochleistungsfähige Datenverfügbarkeitsfunktionen zu verfügen. Das Verschieben von Aktivitäten auf L2 kann auch den MEV-Druck auf L1 verringern.

Ausgereifte L2-Proof-Systeme

Welches Problem lösen wir?

Derzeit sind die meisten Rollups nicht wirklich vertrauenslos. Es gibt ein Sicherheitskomitee, das das Verhalten des Beweissystems (optimistisch oder gültig) außer Kraft setzen kann. In einigen Fällen läuft das Beweissystem überhaupt nicht, oder selbst wenn, hat es nur eine „beratende“ Funktion. Zu den fortschrittlichsten Rollups gehören: (i) einige vertrauenslose anwendungsspezifische Rollups wie Fuel; (ii) zum Zeitpunkt dieses Schreibens sind Optimism und Arbitrum zwei Rollups mit vollem EVM, die einen teilweise vertrauenslosen Meilenstein erreicht haben, der als „Phase 1“ bezeichnet wird. Der Grund, warum Rollups keine weiteren Fortschritte gemacht haben, ist die Angst vor Fehlern im Code. Wir brauchen vertrauenslose Rollups, also müssen wir uns diesem Problem stellen und es lösen.

Was ist das und wie funktioniert es?

Lassen Sie uns zunächst das ursprünglich in diesem Artikel vorgestellte „Stage“-System noch einmal zusammenfassen.

Phase 0: Benutzer müssen in der Lage sein, einen Knoten auszuführen und die Kette zu synchronisieren. Dabei spielt es keine Rolle, ob die Validierung vollständig vertrauenswürdig/zentralisiert ist.

Phase 1: Es muss ein (vertrauensloses) Nachweissystem geben, das sicherstellt, dass nur gültige Transaktionen akzeptiert werden. Es ist zulässig, ein Sicherheitskomitee zu haben, das das Nachweissystem aufheben kann, aber es muss eine Mindestabstimmungsschwelle von 75 % geben. Darüber hinaus muss der Quorum-blockierende Teil des Komitees (d. h. 26 %+) außerhalb des Hauptunternehmens liegen, das das Rollup erstellt. Ein weniger leistungsfähiger Upgrade-Mechanismus (wie z. B. ein DAO) ist zulässig, aber er muss eine ausreichend lange Verzögerung haben, damit Benutzer, wenn er ein böswilliges Upgrade genehmigt, ihre Gelder abheben können, bevor die Gelder verfügbar sind.

Stufe 2: Es muss ein (vertrauenswürdiges) Beweissystem geben, das sicherstellt, dass nur gültige Transaktionen akzeptiert werden. Das Sicherheitskomitee darf nur eingreifen, wenn ein nachweisbarer Fehler im Code vorliegt, z. B. wenn zwei redundante Beweissysteme nicht übereinstimmen oder wenn ein Beweissystem zwei verschiedene Post-State-Roots für denselben Block akzeptiert (oder über einen ausreichend langen Zeitraum, z. B. eine Woche, nichts akzeptiert). Upgrade-Mechanismen sind zulässig, müssen aber sehr lange Verzögerungen aufweisen.

Unser Ziel ist es, Stufe 2 zu erreichen. Die größte Herausforderung dabei ist, genügend Vertrauen zu gewinnen, dass das Beweissystem tatsächlich vertrauenswürdig genug ist. Dafür gibt es zwei Möglichkeiten:

1. Formale Verifizierung: Wir können moderne mathematische und rechnergestützte Techniken verwenden, um (optimistisch und valide) zu beweisen, dass das Beweissystem nur Blöcke akzeptiert, die die EVM-Spezifikation erfüllen. Diese Techniken gibt es schon seit Jahrzehnten, aber jüngste Fortschritte (wie Lean 4) haben sie praktischer gemacht, und Fortschritte bei KI-gestützten Beweisen könnten diesen Trend weiter beschleunigen.

2. Mehrere Beweismittel: Erstellen Sie mehrere Beweissysteme und investieren Sie in diese Beweissysteme mit einem Sicherheitsausschuss (oder anderen Geräten mit Vertrauensannahmen, wie z. B. TEE). Wenn die Beweissysteme übereinstimmen, hat der Sicherheitsausschuss keine Macht; wenn sie nicht übereinstimmen, kann der Sicherheitsausschuss nur zwischen einem von ihnen wählen und kann nicht einseitig seine eigene Antwort aufzwingen.

Stilisiertes Diagramm eines Mehrfachbeweisers, der ein optimistisches Beweissystem, ein Gültigkeitsbeweissystem und ein Sicherheitskomitee kombiniert.

Welche Links gibt es zu bestehenden Forschungsarbeiten?

1. EVM K Semantics (formale Verifizierungsarbeit von 2017): https://github.com/runtimeverification/evm-semantics

2. Vortrag zur Idee von Multi-Proofs (2022): https://www.youtube.com/watch?v=6hfVzCWT6YITaiko

3. Pläne zur Verwendung mehrerer Beweise: https://docs.taiko.xyz/core-concepts/multi-proofs/

Was muss noch getan werden? Was sind die Kompromisse?

Für die formale Verifizierung ist der Arbeitsaufwand groß. Wir müssen eine formal verifizierte Version des gesamten SNARK-Provers für die EVM erstellen. Dies ist ein äußerst komplexes Projekt, obwohl wir bereits damit begonnen haben. Es gibt einen Trick, der diese Aufgabe erheblich vereinfacht: Wir können einen formal verifizierten SNARK-Prover für eine minimale VM (wie RISC-V oder Cairo) erstellen und dann die EVM in dieser minimalen VM implementieren (und ihre Äquivalenz mit anderen Ethereum-VM-Spezifikationen formal beweisen).

Es gibt zwei wichtige Teile des Multi-Proof, die noch nicht fertig sind. Erstens müssen wir genug Vertrauen in mindestens zwei verschiedene Beweissysteme haben, sowohl dass sie für sich genommen einigermaßen sicher sind, als auch dass, wenn sie ausfallen, diese Probleme unterschiedlich und unabhängig voneinander sind (also nicht gleichzeitig ausfallen). Zweitens müssen wir sehr großes Vertrauen in die zugrunde liegende Logik des kombinierten Beweissystems haben. Dieser Teil des Codes ist viel kleiner. Es gibt Möglichkeiten, ihn sehr klein zu machen, indem man die Gelder einfach in einem sicheren Multisig-Vertrag speichert, der von den Verträgen unterzeichnet wird, die die einzelnen Beweissysteme darstellen, aber das wird die Gaskosten in der Kette erhöhen. Wir müssen ein Gleichgewicht zwischen Effizienz und Sicherheit finden.

Wie interagiert dies mit dem Rest der Roadmap?

Durch die Verlagerung der Aktivität auf L2 wird der MEV-Druck auf L1 reduziert.

Verbesserungen der Cross-L2-Interoperabilität

Welches Problem lösen wir?

Eine große Herausforderung für das L2-Ökosystem besteht heute darin, dass es für Benutzer schwierig zu navigieren ist. Darüber hinaus führt der einfachste Ansatz oft Vertrauensannahmen wieder ein: zentralisierte Cross-Chain, RPC-Clients usw. Wir müssen dafür sorgen, dass sich die Nutzung des L2-Ökosystems wie die Nutzung eines einheitlichen Ethereum-Ökosystems anfühlt.

Was ist das? Wie funktioniert es?

Es gibt viele Kategorien von Verbesserungen der Interoperabilität zwischen L2. Theoretisch ist Ethereum, das sich auf Rollup konzentriert, dasselbe wie die Ausführung von Sharded L1. Das aktuelle Ethereum L2-Ökosystem ist in der Praxis noch weit vom Idealzustand entfernt:

1. Kettenspezifische Adressen: Die Adresse sollte Ketteninformationen enthalten (L1, Optimism, Arbitrum …). Sobald dies erreicht ist, kann der Cross-L2-Sendevorgang implementiert werden, indem die Adresse einfach in das Feld „Senden“ eingetragen wird, und die Brieftasche kann im Hintergrund den Sendevorgang handhaben (einschließlich der Verwendung von Cross-Chain-Protokollen).

2. Kettenspezifische Zahlungsanforderungen: Es sollte einfach und standardisiert sein, Nachrichten der Form „Senden Sie mir X-Anzahl von Y-Typ-Generationen auf Kette Z“ zu erstellen. Dies hat zwei Hauptanwendungsszenarien: (i) ob es sich um Zahlungen zwischen Personen oder Zahlungen zwischen Personen und Händlerdiensten handelt; (ii) DApps, die Gelder anfordern.

3. Cross-Chain-Austausch und Gaszahlung: Es sollte ein standardisiertes offenes Protokoll geben, um Cross-Chain-Operationen auszudrücken, wie etwa „Ich werde 1 Ether (auf Optimism) an denjenigen senden, der mir 0,9999 Ether auf Arbitrum gesendet hat“ und „Ich werde 0,0001 Ether (auf Optimism) an denjenigen senden, der diese Transaktion auf Arbitrum einschließt“. ERC-7683 ist ein Versuch des ersteren und RIP-7755 ist ein Versuch des letzteren, obwohl beide breitere Anwendungsmöglichkeiten haben als diese spezifischen Anwendungsfälle.

4. Light Client: Benutzer sollten in der Lage sein, die Kette, mit der sie interagieren, tatsächlich zu überprüfen, anstatt nur dem RPC-Anbieter zu vertrauen. Helios von a16z crypto kann dies tun (für Ethereum selbst), aber wir müssen diese Vertrauenslosigkeit auf L2 ausweiten. ERC-3668 (CCIP-read) ist eine Strategie, um dieses Ziel zu erreichen.

So aktualisiert ein Light-Client seine Ansicht der Ethereum-Headerkette. Sobald Sie die Headerkette haben, können Sie Merkle-Beweise verwenden, um jedes Statusobjekt zu verifizieren. Sobald Sie das richtige L1-Statusobjekt haben, können Sie Merkle-Beweise (und Signaturen, wenn Sie Vorbestätigungen überprüfen möchten) verwenden, um jedes Statusobjekt auf L2 zu verifizieren. Helios macht Ersteres bereits. Die Ausweitung auf Letzteres ist eine Standardisierungsherausforderung.

1. Keystore-Wallet: Wenn Sie heute den Schlüssel aktualisieren möchten, der Ihr Smart-Contract-Wallet steuert, müssen Sie ihn auf allen N-Ketten aktualisieren, auf denen dieses Wallet vorhanden ist. Keystore-Wallets sind eine Technologie, die es ermöglicht, dass Schlüssel nur an einem Ort vorhanden sind (entweder auf L1 oder möglicherweise in Zukunft auf L2), und dann kann jeder L2, der eine Kopie des Wallets hat, den Schlüssel daraus lesen. Das bedeutet, dass Aktualisierungen nur einmal durchgeführt werden müssen. Um die Effizienz zu verbessern, erfordert das Keystore-Wallet, dass L2 über eine standardisierte Möglichkeit verfügt, Informationen auf L1 kostenlos zu lesen; hierfür gibt es zwei Vorschläge, nämlich L1SLOAD und REMOTESTATICALL.

Funktionsprinzip der Keystore-Wallet

2. Ein radikaleres Konzept einer „Shared Token Bridge“: Stellen Sie sich eine Welt vor, in der alle L2s Rollups mit Gültigkeitsnachweis sind und jeder Slot an Ethereum übermittelt wird. Selbst in einer solchen Welt sind zum Übertragen von Vermögenswerten von einem L2 zu einem anderen L2 in einem nativen Zustand immer noch Abhebungen und Einzahlungen erforderlich, was die Zahlung einer Menge L1-Gasgebühren erfordert. Eine Möglichkeit, dieses Problem zu lösen, besteht darin, ein gemeinsam genutztes minimalistisches Rollup zu erstellen, dessen einzige Funktion darin besteht, beizubehalten, welches L2 welche Art von Token besitzt und wie viel Guthaben jedes hat, und die Aktualisierung dieser Guthaben in Stapeln durch eine Reihe von Cross-L2-Sendevorgängen zu ermöglichen, die von jedem L2 initiiert werden. Dadurch werden Cross-L2-Übertragungen möglich, ohne dass für jede Übertragung L1-Gasgebühren gezahlt werden müssen und ohne dass auf Liquiditätsanbietern basierende Technologien wie ERC-7683 verwendet werden müssen.

3. Synchrone Zusammensetzbarkeit: Ermöglicht synchrone Aufrufe zwischen einem bestimmten L2 und L1 oder zwischen mehreren L2s. Dies trägt dazu bei, die finanzielle Effizienz von DeFi-Protokollen zu verbessern. Ersteres kann ohne übergreifende L2-Koordination erreicht werden; Letzteres erfordert eine gemeinsame Reihenfolge. Rollup-basierte Technologien gelten automatisch für alle.

Welche Bezüge bestehen zur bestehenden Forschung?

1. Kettenspezifische Adresse: ERC-3770: https://eips.ethereum.org/EIPS/eip-3770

2. ERC-7683: https://eips.ethereum.org/EIPS/eip-7683

3. RIP-7755: https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md

4. Scrollen Sie durch das Keystore-Wallet-Design: https://hackmd.io/@haichen/keystore

5. Helios: https://github.com/a16z/helios

6. ERC-3668 (manchmal auch CCIP Read genannt): https://eips.ethereum.org/EIPS/eip-3668

7. Justin Drakes Vorschlag für „basierte (gemeinsame) Vorbestätigungen“: https://ethresear.ch/t/based-preconfirmations/17353 8. L1SLOAD (RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388 9. REMOTESTATICCALL in Optimism: https://github.com/ethereum-optimism/ecosystem-contributions/issues/76 10. AggLayer, das die Idee einer gemeinsamen Token-Brücke enthält: https://github.com/AggLayer Was muss noch getan werden? Was sind die Kompromisse? Viele der oben genannten Beispiele stehen vor dem Standardisierungsdilemma, wann und welche Schichten standardisiert werden sollen. Wenn die Standardisierung zu früh erfolgt, kann sich eine schlechte Lösung festsetzen. Wenn die Standardisierung zu spät erfolgt, kann eine unnötige Fragmentierung die Folge sein. In manchen Fällen gibt es sowohl eine kurzfristige Lösung mit schwächeren Eigenschaften, die aber leichter umzusetzen ist, als auch eine langfristige Lösung, die „letztlich richtig“ ist, deren Umsetzung jedoch Jahre dauern wird.

Bei diesen Aufgaben handelt es sich nicht nur um technische Probleme, sondern auch (vielleicht sogar in erster Linie) um soziale Probleme, die neben L1 auch die Zusammenarbeit von L2 und Wallets erfordern.

Wie interagieren sie mit dem Rest der Roadmap?

Die meisten dieser Vorschläge sind Konstrukte der „höheren Ebene“ und haben daher nur geringe Auswirkungen auf L1-Überlegungen. Eine Ausnahme ist die gemeinsame Ordnung, die erhebliche Auswirkungen auf den maximal extrahierbaren Wert (MEV) hat.

Skalierung der Ausführung auf L1

Welches Problem lösen wir?

Wenn L2 sehr skalierbar und erfolgreich wird, L1 aber weiterhin nur eine sehr geringe Anzahl von Transaktionen verarbeiten kann, dann drohen für Ethereum möglicherweise viele Risiken:

1. Die wirtschaftlichen Bedingungen der ETH-Vermögenswerte werden instabiler, was wiederum die langfristige Sicherheit des Netzwerks beeinträchtigen wird.

2. Viele L2s profitieren von engen Verbindungen zum hochentwickelten Finanzökosystem auf L1. Wenn dieses Ökosystem stark geschwächt wird, wird auch der Anreiz, L2 zu werden (anstatt ein unabhängiges L1 zu werden), geschwächt.

3. Es wird lange dauern, bis L2 genau die gleichen Sicherheitsgarantien wie L1 erreicht.

4. Wenn L2 ausfällt (beispielsweise aufgrund böswilligen Verhaltens oder des Verschwindens des Betreibers), müssen Benutzer dennoch L1 durchlaufen, um ihre Vermögenswerte wiederherzustellen. Daher muss L1 leistungsstark genug sein, um die hochkomplexe und chaotische Endarbeit von L2 zumindest gelegentlich tatsächlich bewältigen zu können.

Aus diesen Gründen ist es sehr wichtig, L1 selbst weiter auszubauen und sicherzustellen, dass es auch in Zukunft für immer mehr Anwendungsfälle geeignet ist.

Was ist das? Wie funktioniert es?

Die einfachste Möglichkeit zur Erweiterung besteht darin, das Gaslimit direkt zu erhöhen. Dies kann jedoch L1 stärker zentralisieren und damit ein weiteres wichtiges und leistungsstarkes Merkmal von Ethereum L1 schwächen: seine Glaubwürdigkeit als robuste Basisschicht. Es wird immer noch darüber diskutiert, inwieweit eine einfache Erhöhung des Gaslimits nachhaltig ist, und dies wird davon abhängen, welche anderen Techniken implementiert werden, um die Überprüfung größerer Blöcke zu erleichtern (z. B. Ablauf des Verlaufs, Zustandslosigkeit, L1 EVM-Gültigkeitsnachweise). Ein weiterer wichtiger Punkt, der kontinuierlich verbessert werden muss, ist die Effizienz der Ethereum-Client-Software, die heute viel effizienter ist als vor fünf Jahren. Eine wirksame Strategie zur Erhöhung des L1-Gaslimits wird die Beschleunigung der Entwicklung dieser Überprüfungstechniken beinhalten.

1.EOF: Ein neues EVM-Bytecode-Format, das sich besser für statische Analysen eignet und schnellere Implementierungen ermöglicht. Aufgrund dieser Effizienzgewinne können mit EOF-Bytecode niedrigere Gasgebühren erzielt werden.

2. Mehrdimensionale Gaspreisgestaltung: Durch die Festlegung unterschiedlicher Grundgebühren und Grenzwerte für Rechenleistung, Daten und Speicherung kann die durchschnittliche Kapazität von Ethereum L1 erhöht werden, ohne die maximale Kapazität zu erhöhen (und so die Entstehung neuer Sicherheitsrisiken zu vermeiden).

3. Reduzieren Sie die Gaskosten für bestimmte Opcodes und Vorkompilierungen – In der Vergangenheit haben wir die Gaskosten bestimmter unterbewerteter Operationen mehrmals erhöht, um Denial-of-Service-Angriffe zu vermeiden. Eine Sache, die noch mehr getan werden könnte, ist die Reduzierung der Gaskosten überteuerter Opcodes. Beispielsweise ist die Addition viel billiger als die Multiplikation, aber derzeit haben die Opcodes ADD und MUL die gleichen Kosten. Wir können die Kosten von ADD reduzieren und sogar einfachere Opcodes wie PUSH noch billiger machen. EOF ist in dieser Hinsicht insgesamt besser optimiert.

4. EVM-MAX und SIMD: EVM-MAX ist ein Vorschlag, der effizientere native analoge Mathematik mit großen Zahlen als separates Modul des EVM ermöglichen soll. Sofern sie nicht absichtlich exportiert werden, können die durch EVM-MAX-Berechnungen berechneten Werte nur von anderen EVM-MAX-Opcodes abgerufen werden. Dadurch steht mehr Platz zur Verfügung, um diese Werte in einem optimierten Format zu speichern. SIMD (Single Instruction Multiple Data) ist ein Vorschlag, der die effiziente Ausführung derselben Anweisung auf Wertearrays ermöglicht. Zusammen können die beiden einen leistungsstarken Coprozessor neben dem EVM erstellen, mit dem kryptografische Operationen effizienter implementiert werden können. Dies ist besonders nützlich für Datenschutzprotokolle und L2-Guard-Systeme und hilft daher sowohl bei der L1- als auch bei der L2-Skalierung.

Diese Verbesserungen werden in zukünftigen Splurge-Artikeln ausführlicher besprochen.

Schließlich besteht die dritte Strategie aus nativen Rollups (oder verankerten Rollups): Dabei werden im Wesentlichen viele parallel ausgeführte Kopien des EVM erstellt, wodurch ein Modell entsteht, das dem von Rollup bereitgestellten Modell entspricht, jedoch stärker native in das Protokoll integriert ist.

Welche Bezüge bestehen zur bestehenden Forschung?

1. Polynyas Ethereum L1-Erweiterungs-Roadmap: https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ

2. Mehrdimensionale Gaspreisgestaltung: https://vitalik.eth.limo/general/2024/05/09/multidim.html

3. EIP-7706: https://eips.ethereum.org/EIPS/eip-7706

4. EOF: https://evmobjectformat.org/

5. EVM-MAX: https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168

6. SIMD: https://eips.ethereum.org/EIPS/eip-616

7. Native Rollups: https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE

8. Max Resnick über den Wert der Erweiterung von L1 in einem Interview: https://x.com/BanklessHQ/status/1831319419739361321

9. Justin Drake zur Verwendung von SNARKs und nativen Rollups. Zum Erweitern: https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/

Was muss sonst noch getan werden und was sind die Kompromisse?

Für die L1-Skalierung gibt es drei Strategien, die einzeln oder parallel verfolgt werden können:

1. Verbessern Sie die Technologie (z. B. Clientcode, zustandslose Clients, Ablauf des Verlaufs), um die Überprüfung von L1 zu vereinfachen, und erhöhen Sie anschließend das Gaslimit.

2. Reduzieren Sie die Kosten bestimmter Vorgänge und erhöhen Sie die durchschnittliche Kapazität, ohne das Worst-Case-Risiko zu erhöhen.

3. Native Rollups (d. h. Erstellen von N parallelen Kopien des EVM).

Wenn wir diese verschiedenen Techniken verstehen, werden wir feststellen, dass jede unterschiedliche Vor- und Nachteile mit sich bringt. Beispielsweise haben native Rollups viele der gleichen Schwächen wie gewöhnliche Rollups in Bezug auf die Zusammensetzbarkeit: Sie können keine einzelne Transaktion senden, um Vorgänge über mehrere Rollups hinweg synchron auszuführen, wie Sie es in Verträgen auf demselben L1 (oder L2) tun können. Eine Erhöhung des Gaslimits würde andere Vorteile untergraben, die durch eine Vereinfachung der L1-Validierung erzielt werden könnten, wie z. B. eine Erhöhung des Prozentsatzes der Benutzer, die Validierungsknoten ausführen, und eine Erhöhung der Anzahl der Solo-Staker. Je nach Implementierung könnte die Verbilligung bestimmter Vorgänge in der EVM (Ethereum Virtual Machine) die Gesamtkomplexität der EVM erhöhen.

Eine große Frage, die jede Roadmap zur Skalierung von L1 beantworten muss, lautet: Was ist die ultimative Vision für L1 und L2? Natürlich wäre es lächerlich, alles auf L1 zu setzen: Mögliche Anwendungsfälle könnten Hunderttausende Transaktionen pro Sekunde umfassen, was L1 völlig unüberprüfbar machen würde (es sei denn, wir gehen den nativen Rollup-Weg). Aber wir brauchen einige Leitprinzipien, um sicherzustellen, dass wir nicht in eine Situation geraten, in der eine 10-fache Erhöhung des Gaslimits die Dezentralisierung von Ethereum L1 ernsthaft beeinträchtigt.

Ein Blick auf die Arbeitsteilung zwischen L1 und L2

Wie interagiert dies mit dem Rest der Roadmap?

Mehr Benutzer auf L1 zu bringen bedeutet nicht nur, die Skalierung zu verbessern, sondern auch andere Aspekte von L1 zu verbessern. Das bedeutet, dass mehr MEV auf L1 bleiben wird (anstatt nur ein Problem für L2 zu sein), sodass die Notwendigkeit, sich explizit mit MEV zu befassen, dringlicher wird. Dies wird den Wert schneller Slot-Zeiten auf L1 erheblich steigern. Gleichzeitig hängt dies auch stark vom reibungslosen Ablauf der L1-Verifizierung (der Verge) ab.

Weiterführende Literatur: Vitaliks neuer Artikel: Wo kann Ethereum PoS noch verbessert werden? Wie erreicht man das?

Ursprünglicher Link