Ethereum ist ein erlaubnisloser Weltcomputer, der zum Zeitpunkt des Verfassens dieses Artikels (wohl) über das höchste Maß an wirtschaftlicher Sicherheit verfügt und als Abrechnungsbuch für eine große Anzahl von Vermögenswerten, Anwendungen und Diensten fungiert. Ethereum hat seine Grenzen – Blockraum ist eine knappe und teure Ressource auf der ersten Schicht (L1) von Ethereum. Als Lösung für dieses Problem gilt die Layer-Two-Skalierung (L2). In den letzten Jahren kamen zahlreiche Projekte auf den Markt, meist in Form von Rollups. Allerdings ermöglichen Rollups im engeren Sinne des Wortes (d. h. Rollup-Daten befinden sich auf Ethereum L1) keine unbegrenzte Skalierung von Ethereum, sondern ermöglichen nur einige tausend Transaktionen pro Sekunde.

Vertrauensminimiert – (eine Funktion) eines L2-Systems ist vertrauensminimiert, wenn es funktioniert, ohne dass Vertrauen außerhalb des Basis-L1 erforderlich ist.

Horizontale Skalierung – ein System ist horizontal skalierbar, wenn Instanzen hinzugefügt werden können, ohne dass es zu globalen Engpässen kommt.

In diesem Artikel argumentieren wir, dass vertrauensminimierte und horizontal skalierbare Systeme die vielversprechendste Möglichkeit zur Skalierung von Blockchain-Anwendungen sind, sie werden jedoch derzeit noch wenig erforscht. Wir präsentieren das Argument, indem wir drei Fragen untersuchen:

1. Warum sollten Anwendungen vertrauenswürdig minimiert werden?
2. Warum Systeme bauen, die horizontal skalierbar sind?
3. Wie können wir sowohl die Vertrauensminimierung als auch die horizontale Skalierbarkeit maximieren?

(Haftungsausschluss: Obwohl wir uns in diesem Artikel auf Ethereum als Basis-L1 konzentrieren werden, gilt das meiste, was wir hier besprechen, für dezentrale Abwicklungsschichten außerhalb von Ethereum.)

Warum sollten Anwendungen vertrauenswürdig minimiert werden?

Anwendungen können auf vertrauenswürdige Weise mit Ethereum verbunden werden – sie können in die Ethereum-Blockchain schreiben und von ihr lesen, es wird jedoch darauf vertraut, dass die Betreiber die Geschäftslogik korrekt ausführen. Zentralisierte Börsen wie Binance und Coinbase sind großartige Beispiele für vertrauenswürdige Anwendungen. Durch die Verbindung mit Ethereum können Anwendungen auf ein globales Abwicklungsnetzwerk mit vielfältigen Vermögenswerten zugreifen.

Mit vertrauenswürdigen Off-Chain-Diensten sind erhebliche Risiken verbunden. Der Zusammenbruch großer Börsen und Dienste im Jahr 2022 wie FTX und Celsius ist ein großartiges warnendes Beispiel dafür, was passiert, wenn vertrauenswürdige Dienste sich schlecht verhalten und ausfallen.

Andererseits können vertrauensminimierte Anwendungen nachweislich auf Ethereum schreiben und von Ethereum lesen. Beispiele hierfür sind Smart-Contract-Anwendungen wie Uniswap, Rollups wie Arbitrum oder zkSync und Coprozessoren wie Lagrange und Axiom. Im Großen und Ganzen geht das Vertrauen verloren, wenn Anwendungen durch das Ethereum-Netzwerk gesichert werden, da mehr Funktionalitäten (siehe unten) an L1 ausgelagert werden. Dadurch können vertrauensminimierte Finanzdienstleistungen ohne Kontrahenten- oder Depotbankrisiken angeboten werden.

Es gibt drei Schlüsseleigenschaften, die Anwendungen und Dienste haben können und die auf L1 ausgelagert werden können:

1. Lebendigkeit (und Ordnung): Vom Benutzer übermittelte Transaktionen sollten zeitnah einbezogen (ausgeführt und abgewickelt) werden.
2. Gültigkeit: Transaktionen werden nach vorgegebenen Regeln abgewickelt.
3. Verfügbarkeit von Daten (und Status): Historische Daten sowie der aktuelle Anwendungsstatus werden dem Benutzer zugänglich gemacht.

Für jede der oben genannten Eigenschaften können wir uns überlegen, welche Vertrauensannahme erforderlich ist. Insbesondere stellt Eth L1 das Eigentum bereit oder ist externes Vertrauen erforderlich. Die folgende Tabelle kategorisiert dies für verschiedene Architekturparadigmen.

Warum Systeme bauen, die horizontal skalierbar sind?

Unter horizontaler Skalierung versteht man die Skalierung durch das Hinzufügen unabhängiger oder paralleler Instanzen eines Systems, z Anwendung oder Rollup. Dies setzt voraus, dass kein globaler Engpass vorliegt. Die horizontale Skalierung ermöglicht und erleichtert exponentielles Wachstum.

Vertikale Skalierung bezieht sich auf die Skalierung über die Erhöhung des Durchsatzes eines monolithischen Systems, wie z. B. Eth L1 oder einer Datenverfügbarkeitsschicht. Wenn es bei der horizontalen Skalierung bei einer solchen gemeinsam genutzten Ressource zu Engpässen kommt, ist häufig eine vertikale Skalierung erforderlich.

Behauptung 1: (Transaktionsdaten-)Rollups können nicht horizontal skaliert werden, da sie durch die Datenverfügbarkeit (DA) einen Engpass haben können. Vertikal skalierbare DA-Lösungen erfordern Kompromisse bei der Dezentralisierung.

Die Datenverfügbarkeit (DA) bleibt der Engpass für Rollups. Derzeit hat jeder L1-Block ein maximales Größenziel von ~1 MB (85 KB/s). Mit EIP-4844 werden (langfristig) zusätzlich ca. 2 MB (171 KB/s) zur Verfügung gestellt. Mit Danksharding unterstützt Eth L1 möglicherweise bis zu 1,3 MB/s DA-Bandbreite. Eth L1 DA ist eine gemeinsame Ressource, um die viele Anwendungen und Dienste konkurrieren. Daher bietet die Verwendung von L1 für DA zwar die beste Sicherheit, beeinträchtigt jedoch die potenzielle Skalierbarkeit solcher Systeme. Systeme, die L1 für DA nutzen, sind (normalerweise) nicht in der Lage, horizontal zu skalieren und weisen Skalennachteile auf. Alternative DA-Schichten wie Celestia oder EigenDA haben ebenfalls Bandbreitenbeschränkungen (wenn auch größer, nämlich 6,67 MB/s bzw. 15 MB/s). Dies geht jedoch zu Lasten der Verlagerung der Vertrauensannahme von Ethereum auf ein anderes (häufig weniger dezentralisiertes) Netzwerk, was die (wirtschaftliche) Sicherheit beeinträchtigt.

Behauptung 2: Die einzige Möglichkeit, vertrauensminimierte Dienste horizontal zu skalieren, besteht darin, pro Transaktion (nahezu) null marginale L1-Daten zu erhalten. Die beiden bekannten Ansätze sind State-Diff Rollups (SDR) und Validiums.

State-Diff-Rollups (SDRs) sind Rollups, die Statusunterschiede über einen aggregierten Transaktionsstapel hinweg an Ethereum L1 senden. Für die EVM sinken die pro Transaktion an L1 gesendeten Daten auf eine Konstante, die viel kleiner ist als die von Transaktionsdaten-Rollups, wenn die Transaktionsstapel größer werden.

Beispielsweise konnte zkSync während des Stresstest-Ereignisses mit hoher Inskriptionsflut eine Reduzierung der Anrufdaten pro Transaktion auf nur 10 Byte pro Transaktion feststellen. Im Gegensatz dazu werden bei Transaktionsdaten-Rollups wie Arbitrum, Optimism und Polygon zkEVM bei normalem Datenverkehr typischerweise etwa 100 Byte pro Transaktion angezeigt.

Ein Validium ist ein System, das Gültigkeitsnachweise von Zustandsübergängen zu Ethereum veröffentlicht, ohne zugehörige Transaktionsdaten oder Status. Validien sind selbst bei geringem Verkehrsaufkommen hochgradig horizontal skalierbar. Dies gilt insbesondere, da die Abrechnung verschiedener Validien aggregiert werden kann.

Neben der horizontalen Skalierbarkeit kann ein Validium auch On-Chain-Privatsphäre (von öffentlichen Beobachtern) bieten. Ein Validium mit privatem DA verfügt über zentralisierte und geschützte Daten und Statusverfügbarkeit, was bedeutet, dass Benutzer sich vor dem Zugriff auf Daten authentifizieren müssen und der Betreiber gute Datenschutzmaßnahmen durchsetzen kann. Dies ermöglicht ein Benutzererlebnis, das mit herkömmlichen Web- oder Finanzdiensten vergleichbar ist – Benutzeraktivitäten bleiben der öffentlichen Kontrolle verborgen, es gibt jedoch einen vertrauenswürdigen Verwalter der Benutzerdaten, in diesem Fall den Validium-Betreiber.

Was ist mit zentralisierten vs. dezentralen Sequenzern? Um Systeme horizontal skalierbar zu halten, ist es entscheidend, unabhängige Sequenzer zu instanziieren, entweder zentral oder dezentral. Bemerkenswert ist, dass Systeme, die gemeinsam genutzte Sequenzer verwenden, zwar über eine atomare Zusammensetzbarkeit verfügen, jedoch nicht horizontal skalierbar sind, da derSequenzer zu einem Engpass werden kann, wenn weitere Systeme hinzugefügt werden.

Wie sieht es mit der Interoperabilität aus? Horizontal skalierbare Systeme können ohne zusätzliches Vertrauen zusammenarbeiten, wenn sie sich alle auf demselben L1 niederlassen, da Nachrichten über die gemeinsame Abwicklungsschicht von einem System an ein anderes gesendet werden können. Es gibt einen Kompromiss zwischen Betriebskosten und Nachrichtenverzögerung (der möglicherweise auf der Anwendungsebene gelöst werden kann).

Vertrauensminimierung für horizontal skalierbare Systeme

Können wir die Vertrauensanforderungen für Lebendigkeit, Ordnung und Datenverfügbarkeit in horizontal skalierbaren Systemen weiter minimieren?

Bemerkenswert ist, dass wir auf Kosten der horizontalen Skalierbarkeit wissen, wie wir die vertrauenswürdige Lebendigkeit und Datenverfügbarkeit retten können. Beispielsweise können L2-Transaktionen von L1 aus initiiert werden, um eine garantierte Einbeziehung zu gewährleisten. Volition kann Benutzern die Opt-in-Verfügbarkeit des L1-Status anbieten.

Eine andere Lösung besteht darin, einfach zu dezentralisieren (aber sich nicht auf L1 zu verlassen). Anstelle eines einzelnen Sequenzers könnten Systeme durch den Einsatz dezentraler Sequenzer (wie Espresso Systems oder Astria) stärker dezentralisiert werden, wodurch das Vertrauen, das für Lebendigkeit, Ordnung und Datenverfügbarkeit erforderlich ist, minimiert wird. Dadurch ergeben sich Einschränkungen im Vergleich zu Lösungen mit nur einem Betreiber: (1) Die Leistung kann durch die Leistung des verteilten Systems begrenzt sein, und (2) bei Validien mit privatem DA geht die Standard-Datenschutzgarantie verloren, wenn das dezentrale Sequenzer-Netzwerk keine Berechtigung hat.

Wie viel Vertrauen können wir zusätzlich für Single-Operator-Validien oder SDRs minimieren? Hier gibt es einige offene Richtungen.

Offene Richtung 1: Vertrauensminimierte Datenverfügbarkeit in Validien. Plasma löst das Problem der Zustandsverfügbarkeit bis zu einem gewissen Grad – es löst das Problem entweder nur für Auszahlungen für bestimmte Zustandsmodelle (einschließlich des UTXO-Zustandsmodells) oder erfordert, dass Benutzer regelmäßig online sind (Plasma Free).

Offene Richtung 2: Rechenschaftspflichtige Vorbestätigungen in SDRs und Validien. Das Ziel besteht hier darin, Benutzern eine schnelle Vorabbestätigung der Transaktionseinbeziehung durch einen Sequenzer zu ermöglichen, und die Bestätigung sollte es dem Benutzer ermöglichen, den wirtschaftlichen Anteil des Sequenzers anzufechten und zu kürzen, wenn das Einbeziehungsversprechen nicht erfüllt wird. Die Herausforderung hierbei besteht darin, dass der Nachweis der Nichteinbeziehung (notwendig für Slashing) wahrscheinlich zusätzliche Daten für den Benutzer erfordert, die ein Sequenzer einfach zurückhalten kann. Daher ist es vernünftig anzunehmen, dass wir zumindest verlangen, dass SDR oder Validium ein (möglicherweise autorisiertes) Datenverfügbarkeitskomitee für seine vollständigen Anrufdaten oder Transaktionshistorien einsetzen, was es demselben Komitee ermöglicht, den Nachweis der Nichteinbeziehung (von vorab) zu erbringen. bestätigte Transaktionen) auf Benutzeranfrage.

Offene Richtung 3: Schnelle Wiederherstellung nach Liveness-Ausfällen. Systeme mit nur einem Betreiber können unter Liveness-Ausfällen leiden (z. B Arbitrum ging während des Inskriptionsereignisses offline. Können wir in diesem Szenario Systeme entwerfen, die eine minimale Serviceunterbrechung bieten? In gewisser Weise bieten L2s, die Selbstsequenz- und Zustandsvorschläge ermöglichen, Garantien gegen längere Liveness-Ausfälle. Die Entwicklung von Ein-Betreiber-Systemen, die widerstandsfähiger gegen kürzere Betriebsausfälle sind, ist derzeit noch wenig erforscht. Eine mögliche Lösung hierfür besteht darin, Liveness-Fehler zur Rechenschaft zu ziehen, indem man eine Kürzung von Liveness-Fehlern vorsieht. Eine andere mögliche Lösung besteht darin, einfach die Verzögerungszeit (die derzeit bei etwa einer Woche liegt) zu verkürzen, bevor eine Übernahme stattfinden kann.

Abschluss

Die Skalierung eines globalen Abrechnungsbuchs bei gleichzeitiger Wahrung der Vertrauensminimierung ist ein schwieriges Problem. Heutzutage gibt es in der Rollup- und Datenverfügbarkeitswelt keine klare Unterscheidung zwischen vertikaler und horizontaler Skalierung. Um vertrauensminimierte Systeme wirklich für alle Menschen auf der Welt skalierbar zu machen, müssen wir vertrauensminimierte und horizontal skalierbare Systeme aufbauen.

Danksagungen

Vielen Dank an Vitalik Buterin und Terry Chung für Feedback und Diskussion sowie an Diana Biggs für ihre redaktionellen Kommentare.

Antwort:

Haftungsausschluss:

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