Repost the original title: Sharded L2? “=nil;” Wie kann eine neue Lösung für die Fragmentierung des L2-Status gegeben werden?

Ethereums Wechsel zu einem rollup-zentrierten Fahrplan hat ein explosives Wachstum in modularen Skalierungsentwürfen ausgelöst. Dieses Wachstum war zunächst ein Erfolg, da es Gasgebühren von über 100 $ beseitigte und völlig neue Anwendungsentwürfe freisetzte. Aber nur wenige Jahre später stehen Ethereum und seine Rollups vor einem neuen, kritischen Problem: der Zustandsfragmentierung.

Grundlegend ist die Fragmentierung des Zustands ein Skalierungsproblem. In letzter Zeit hat die modulare Gemeinschaft Middleware-Lösungen vorangetrieben, die bestehende Rollups in ein einziges System zusammenführen und scheinbar das heilige Gral der Skalierbarkeit von Blockchains - horizontale Skalierbarkeit - erreichen. Diese Lösungen gehen jedoch mit erheblichen Kompromissen einher. Eine neue Generation von Ethereum L2s überdenkt die Skalierbarkeit von Grund auf neu und wendet vertikale und horizontale Techniken an, um eine Endgame-Performance zu liefern.

Zwei Blockchain-Scaling-Richtungen

Es gibt zwei Frameworks zur Skalierung einer Blockchain:

• Vertikales Skalierenerhöht die verfügbaren Ressourcen für einen einzelnen Knoten. Dies ist die Skalierungsphilosophie von Solana, die darauf abzielt, die Hardwareauslastung zu maximieren, sowie die parallelisierte VM (virtuelle Maschine) Bewegung.
• Horizontale Skalierungverteilt die Arbeitslast auf mehrere Server. Dies ist die Skalierungsphilosophie von geschachtelten L1-Blockchains wie Near und Ethereum (Danksharding).

Rollups werden oft fälschlicherweise als eine horizontale Skalierungslösung für Ethereum betrachtet. Jeder Rollup und jede Blockchain ist jedoch durch das Hauptbuch definiert, was bedeutet, dass Rollups separate Systeme von Ethereum sind. Dieses grundlegende Versäumnis der grundlegenden Skalierungsprinzipien von Datenbanken hat das Ethereum-Ökosystem vor die existenzielle Herausforderung gestellt, den Zustandsfragmentierung zu lösen.

Herausforderung voraus

Fragmentierung über verschiedene L2s hinweg ist zu einem großen Problem für Ethereum eskaliert. Fragmentierung wird durch drei neue Probleme definiert.

• Kompromittierte Netzwerkeffekte des globalen Standorts, einschließlich Liquidität und Benutzerverteilung, wurzeln in den zehn (wenn nicht hunderten) von Ethereum angrenzenden L2s, die auf infrastrukturelle Anwendungen drängen.
• Die zunehmende Komplexität der Interoperabilitätsstandards und der sozialen Koordination, die der Katalysator für mehr als 2,8 Milliarden Dollar an Brücken-Hacks war.
• Objektiv verschlechterte Entwickler- und Benutzererfahrungen. Entwickler müssen mit komplizierten Netzwerkabstraktionen arbeiten, um ein nahtloses Benutzererlebnis zu bieten, oderBenutzer werden gezwungen, mit der Komplexität der Interaktion mit Cross-Chain umzugehen, einschließlich Asset-Bridging, Wallet-Netzwerkverwaltung und mehreren Gas-Token.

Und diese Probleme werden von Tag zu Tag schlimmer. Begrenzt durch die bestehende Infrastruktur, werden preissensitive Anwendungen gezwungen, in Isolation zu verbleiben, um zuverlässig niedrige Transaktionsgebühren zu gewährleisten. Da der nächste Zyklus näher rückt, ist ein heimtückischer Schneeballeffekt zu erwarten; mit steigenden L2-Stauungsgebühren werden mehr Entwickler dazu gezwungen, sich für infrastrukturspezifische Anwendungen zu entscheiden, was die ohnehin schon weit verbreiteten Probleme im Zusammenhang mit der Zustandsfragmentierung verschärft. Es wäre keine Überraschung, wenn die Unfähigkeit der L2s, die Zustandsfragmentierung zu lösen, in einigen Jahren zum Niedergang der Anwendungsdominanz im Ethereum-Ökosystem führen würde.

Lösung der Zustandsfragmentierung

Die Fragmentierung des Zustands ist im Wesentlichen ein Skalierungsproblem, bei dem die Verantwortung beim L2 liegt, ohne die Zusammensetzbarkeit zu zerbrechen. Es gibt zwei Ansätze, die L2s zur Lösung der Skalierbarkeit ergreifen können.

• Existierende Rollups in ein einziges System zusammenführen, um so eine "horizontale Skalierbarkeit" zu erreichen.
• Beginnen Sie frisch und entwerfen Sie ein skalierbares L2.

Rückwärts arbeiten

Der erste Ansatz ist bei etablierten L2s ziemlich beliebt. Das Verschmelzen von Rollups wird durch die Verwendung von Middleware erreicht, um eine Vorstellung von einem einzigen System zu etablieren. Diese Lösungen erleichtern die Kommunikation über Rollups hinweg durch gemeinsame Konsensgarantien. Zu solchen Lösungen gehören gemeinsame Sequenzer, gemeinsame Beweiser und verschiedene L3-Architekturen.

Während die Teams und Projekte, die an diesen Lösungen arbeiten, stark sind, ist ein mittelwarezentrierter Ansatz zur Lösung der Skalierbarkeit von L2 mit erheblichen Kompromissen verbunden, einschließlich:

• Schwächste Kettenanfälligkeiten: Die Sicherheit und Eigenschaften des Netzwerks werden vom schlechtesten Teil des Stapels geerbt.
• Eine fragmentierte Entwicklerumgebung: Unterschiedliche Umgebungen, die mit Middleware verbunden sind, führen immer noch zu einer zersplitterten Entwicklungserfahrung.
• Globale soziale Koordination von Cross-Rollup-Standards: Um bestehende Rollups zusammenzuführen, müssen Hunderte (potenziell Tausende) von Interessengruppen sich auf bewährte Verfahren einigen.

Viel wichtiger ist, dass es die L2-Teams davon abhält, die offenen Probleme der Gebührenfestlegung bei Überlastung und der Zensur durch Einzelakteure zu lösen, die erhebliche Ingenieurs- und Forschungsbemühungen erfordern.

Ein Neuanfang

Ethereum L2s können vertikal skaliert werden, indem die Ausführungsumgebung eines Rollup-Knotens geändert wird, um die Hardwareauslastung zu erhöhen; solche Projekte umfassen Eclipse und Movement Labs, die Rollups unter Verwendung des SVM bzw. MoveVM aufbauen. Dieser Ansatz birgt hohe Versprechen für kurzfristige Skalierbarkeitsverbesserungen; er erfordert jedoch, dass Ethereum-Entwickler einen neuen Tech-Stack übernehmen.

Alternativ können L2s horizontal skalieren, indem (wieder) Ausführungs-Sharding eingeführt wird, was es dem Netzwerk ermöglichen würde, durch das Hinzufügen neuer Knoten zu skalieren. Dieser Ansatz fördert die Dezentralisierung, hat höhere theoretische Skalierungsgrenzen und ermöglicht vertikale Skalierungsoptimierungen, wenn erforderlich. Angesichts dieser Vorteile hat die =nil; Foundation einen geschichteten L2 namens =nil; entworfen.

=nil; optimiert, um die Kernwerte von Ethereum wie Dezentralisierung, Resistenz gegen Zensur und Erlaubnislosigkeit zu bewahren. =nil; ist die erste nachweisbare Sharding-Architektur, die auf einem neuartigen Design basiert. zkShardingEs ermöglicht die Skalierungseigenschaften der oben genannten nachträglichen horizontalen Skalierungsframeworks mit dem zusätzlichen Vorteil einer einzigen, integrierten Entwicklungsumgebung. Dies gibt Entwicklern Zugang zum Maßstab von 1000er Rollups aus einem einzigen Netzwerk. Noch wichtiger ist, dass =nil; selbst bei Spitzenlast Benutzern zuverlässig niedrige Transaktionsgebühren garantiert.

Darüber hinaus löst =nil; Stauungsgebühren, indem es den Zustand dynamisch aufteilt und fusioniert, basierend auf der Nachfrage nach Zustandszugriff über Scherben. Dieses dynamische Verhalten ermöglicht es =nil;, Transaktionsgebühren zuverlässig niedrig zu halten (<$0.01). Insgesamt hat die =nil;-Stiftung die Mission, einen alternativen Weg für die Ethereum L2-Skalierung anzubieten, der enger mit den Kernwerten von Ethereum und der Nachfrage nach L2-Ausführung übereinstimmt.

Abschließende Gedanken

Trotz der vielen Herausforderungen, die bevorstehen, sieht die Zukunft für Ethereum L2s vielversprechender aus als je zuvor. Mit der Reife der L2-Designs und dem Eintritt in die nächste Generation von Skalierungslösungen gibt es zwei vorherrschende Unterschiede: rückwärts arbeiten gegenüber neu beginnen und horizontale gegenüber vertikale Skalierung.

Sharding ist tot, es lebe Sharding.

Aussage:

1. Dieser Artikel stammt aus [Gateforesightnews], das Urheberrecht liegt beim Originalautor [Avi Zurlo,=nil; Stiftung], wenn Sie Einwände gegen den Nachdruck haben, kontaktieren Sie bitte Gate Learn Team, das Team wird es so schnell wie möglich gemäß den relevanten Verfahren bearbeiten.

2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen stellen nur die persönlichen Ansichten des Autors dar und stellen keine Anlageberatung dar.

3. Andere Sprachversionen des Artikels werden vom Gate Learn-Team übersetzt und nicht erwähnt.Gate.io, der übersetzte Artikel darf nicht vervielfältigt, verteilt oder plagiiert werden.