Original author | Vitalik

Kompilieren | Odaily Star Planet Daily Nan Zhi

Eine wichtige Eigenschaft eines guten Benutzererlebnisses auf der Blockchain ist eine schnelle Transaktionsbestätigungszeit. Heutzutage hat sich Ethereum im Vergleich zu vor fünf Jahren erheblich verbessert. Dank der stabilen Blockzeit nach EIP-1559 und der Umstellung auf PoS (The Merge) können Transaktionen, die von Benutzern auf L1 gesendet werden, in der Regel innerhalb von 5-20 Sekunden bestätigt werden, was etwa dem Erlebnis beim Bezahlen mit Kreditkarte entspricht. Eine weitere Verbesserung des Benutzererlebnisses ist jedoch wertvoll, da einige Anwendungen sogar Hunderte von Millisekunden oder noch kürzere Latenzzeiten erfordern. In diesem Artikel werden einige praktische Optionen zur Verbesserung der Bestätigungszeit von Ethereum-Transaktionen untersucht.

Übersicht über bestehende Ideen und Technologien

Einzelsteckplatzendgültigkeit

Derzeit verwendet die Ethereum-Gasper-Konsensmechanismus eine Architektur mit einzelnen Slots und Epochen. Alle 12 Sekunden wird ein Slot aktiviert, und einige Prüfer stimmen über den Kopf der Kette ab. Innerhalb von 32 Slots (6,4 Minuten) haben alle Prüfer die Möglichkeit, einmal abzustimmen. Diese Abstimmungen werden dann als Nachrichten in einem Konsensalgorithmus ähnlich dem PBFT-Algorithmus interpretiert und nach zwei Epochen (12,8 Minuten) wird eine sehr starke wirtschaftliche Gewährleistung namens Finalität gewährt.

In den letzten Jahren waren wir mit der aktuellen Methode immer unzufriedener. Es gibt zwei Hauptgründe dafür: Erstens ist diese Methode sehr komplex und es gibt viele Interaktionsfehler zwischen dem Slot-to-Slot-Abstimmungsmechanismus und dem Epoch-to-Epoch-Finalitätsmechanismus. Zweitens ist 12,8 Minuten zu lang. Niemand möchte so lange warten.

Die Single-Slot-Finality (SSF) ersetzt diese Architektur durch einen Mechanismus ähnlich dem Tendermint-Konsens, bei dem Block N vor der Generierung von Block N+1 endgültig festgelegt wird. Der Hauptunterschied zu Tendermint besteht darin, dass wir den Mechanismus des "Inaktivitätslecks" beibehalten, der es der Kette ermöglicht, weiterhin zu funktionieren und sich zu erholen, wenn mehr als 1/3 der Prüfer offline sind.

Die Hauptherausforderung der Finalität eines einzelnen Slots besteht darin, dass dies bedeutet, dass jeder Ethereum-Staker alle 12 Sekunden zwei Nachrichten veröffentlichen muss, was eine große Belastung für die Kette darstellt. Es gibt einige clevere Ideen, um dieses Problem zu lindern, darunter der kürzlich vorgeschlagene Orbit SSF. Obwohl dies die "Finalität" signifikant beschleunigt, um die Benutzererfahrung zu verbessern, ändert es nicht die Tatsache, dass Benutzer 5-20 Sekunden warten müssen.

Vorläufige Bestätigung von Rollup

In den letzten Jahren hat Ethereum kontinuierlich eine Rollup-zentrierte Roadmap verfolgt, um die Ethereum-Grundschicht (L1) zu entwerfen, um die Datenverfügbarkeit und andere Funktionen zu unterstützen, die dann von L2-Protokollen wie Rollups, Validiums und Plasmas genutzt werden können, um Benutzern auf einer größeren Skala ein gleiches Maß an Sicherheit wie bei Ethereum zu bieten.

Dies hat zu einer Trennung der Fokusse im Ethereum-Ökosystem geführt: Ethereum L1 konzentriert sich auf Unzensierbarkeit, Zuverlässigkeit, Stabilität sowie die Aufrechterhaltung und Verbesserung einer bestimmten Kernfunktionalität der Basischicht, während L2 darauf abzielt, Benutzer auf direkterem Weg durch verschiedene kulturelle und technologische Ansätze zu erreichen. Doch entlang dieses Pfades ergibt sich zwangsläufig ein Problem: L2 strebt nach schnelleren Bestätigungen für Benutzer als 5-20 Sekunden.

Bislang liegt es zumindest theoretisch in der Verantwortung von L2, ein eigenes 'dezentralisiertes Sorter-Netzwerk' zu erstellen. Eine kleine Gruppe von Prüfern könnte alle paar hundert Millisekunden einen Block signieren und ihre Staking-Assets in diese Blöcke einbringen. Schließlich werden die Header dieser L2-Blöcke auf L1 veröffentlicht.

Aber die L2-Prüfergruppe kann 'Betrug' begehen: Sie können zuerst den Block B1 signieren und dann einen konfliktierenden Block B2 signieren und vor B1 auf die Kette stellen. Wenn sie das tun, werden sie jedoch überprüft und verlieren ihre Staken. Tatsächlich haben wir bereits praktische Fälle der zentralisierten Version gesehen, aber andererseits ist der Fortschritt bei der Entwicklung von Dezentralisierungssortiernetzwerken auf Rollup-Seite langsam. Man kann sagen, dass es unfair ist, von allen L2-Plattformen zu verlangen, eine dezentrale Sortierung durchzuführen: Im Grunde genommen verlangen wir von Rollup, fast die gleiche Arbeit wie bei der Erstellung eines brandneuen L1 zu leisten. Daher hat Justin Drake kontinuierlich eine Methode zur Förderung eines Basis-Vorbestätigungssystems propagiert, das von allen L2- (und L1-)Plattformen innerhalb des Ethereum-Bereichs gemeinsam genutzt werden kann.

Grundlegende Vorabbestätigung

Die Methode der basierten Vorbestätigung geht davon aus, dass Ethereum-Vorschlagende hochkomplexe Teilnehmer mit MEV-Bezug sind. Die basierte Vorbestätigungsmethode nutzt diese Komplexität, indem sie diese komplexen Vorschlagenden dazu anregt, die Verantwortung für die Bereitstellung von Vorbestätigungsdiensten zu übernehmen.

Die grundlegende Idee dieser Methode besteht darin, ein standardisiertes Protokoll zu erstellen, bei dem Benutzer zusätzliche Gebühren zahlen können, um sicherzustellen, dass Transaktionen in einem sofortigen Garantieblock enthalten sind und eine Erklärung zur Ausführung des Transaktionsergebnisses abgeben. Wenn ein Vorschlagender gegen irgendeine Verpflichtung gegenüber einem Benutzer verstößt, kann er bestraft werden.

Wie beschrieben, werden L1-Transaktionen auf der Grundlage einer Vorabbestätigung garantiert. Wenn Rollups "basierend auf" sind, sind alle L2-Blöcke L1-Transaktionen, sodass derselbe Mechanismus verwendet werden kann, um eine Vorabbestätigung für jedes L2 bereitzustellen.

Was sehen wir wirklich?

Angenommen, wir haben die Einzelschlusssicherheit erreicht. Wir verwenden eine Technologie ähnlich wie Orbit, um die Anzahl der Validatoren zu reduzieren, die jedes Schlüsselzeichen unterzeichnen, ohne sie zu stark zu reduzieren, um auch Fortschritte bei der Minimierung der Mindestgrenze von 32 ETH für den Einsatz zu erzielen. Die Schlüsselzeiten (Slot-Zeiten) könnten auf 16 Sekunden erhöht werden, und dann verwenden wir Rollup-Vorbestätigung oder Basiskonfirmation, um den Benutzern schnellere Bestätigungen zu bieten. Schließlich haben wir was bekommen: eine Epoch-Slot-Architektur.

Es gibt einen tiefgreifenden philosophischen Grund, warum die Architektur von Epoch und Slot scheinbar so schwer zu vermeiden ist: Es braucht weniger Zeit, um sich im Wesentlichen zu einigen, im Vergleich zu dem Grad an 'wirtschaftlicher Endgültigkeit', der für etwas erreicht werden muss.

Ein einfacher Grund ist die Anzahl der Knoten. Obwohl sich die alten Kompromisse zwischen linearer Dezentralisierung, finaler Zeit und Kosten aufgrund der hochgradig optimierten BLS-Aggregation und der baldigen Einführung von ZK-STARKs nun mildern, sollten die folgenden Gründe nicht vernachlässigt werden:

• "Nahezu Konsens" erfordert nur wenige Knoten, während die wirtschaftliche Endgültigkeit die Mehrheit der Knoten erfordert.
• Sobald die Anzahl der Nodes eine bestimmte Größe überschreitet, müssen Sie mehr Zeit für die Signatursammlung aufwenden.

In der heutigen Ethereum dauert ein 12-Sekunden-Slot drei Untersteckplätze: Blockveröffentlichung und -verteilung, Nachweis, Nachweisaggregation. Wenn die Anzahl der Proof-Verfahren erheblich reduziert wird, können wir auf zwei Untersteckplätze und eine 8-Sekunden-Slot-Zeit reduzieren. Ein weiterer, praktischerer und wichtigerer Faktor ist die „Qualität“ der Knoten. Ein weiterer wichtigerer Faktor ist die „Qualität“ der Knoten. Wenn wir uns auch auf eine spezialisierte Teilmenge von Knoten verlassen können, um eine annähernde Vereinbarung zu erzielen (und weiterhin die vollständige Validatorengruppe verwenden, um die Endgültigkeit festzustellen), können wir dies auf etwa 2 Sekunden reduzieren.

Daher scheint die Epoch-and-Slot-Architektur aus meiner Sicht offensichtlich richtig zu sein, aber nicht alle Epoch-and-Slot-Architekturen sind gleich und es ist wertvoll, den Designraum weiter zu erkunden. Der lohnenswerte Forschungsansatz liegt nicht darin, wie eng Gasper miteinander verknüpft ist, sondern in einer stärkeren Fokussierung auf die Trennung der beiden Mechanismen.

Wie soll L2 vorgehen?

Aus meiner Sicht gibt es derzeit drei vernünftige Strategien für L2:

• Technisch und geistig gesehen sind sie 'basiert'. Das bedeutet, dass sie die technischen Eigenschaften und Werte der Ethereum-Grundschicht optimieren (hochgradig dezentralisiert, zensurresistent usw.). In ihrer einfachsten Form können Sie diese Rollups als 'Marken-Sharding' betrachten, aber sie können auch größere Ambitionen haben und viele Experimente mit der Gestaltung einer neuen virtuellen Maschine und anderen technischen Verbesserungen durchführen.
• Werden Sie ein "Server mit Blockchain Gerüst" und machen Sie das Beste daraus. Wenn Sie mit dem Server beginnen, fügen Sie einen STARK-Gültigkeitsnachweis hinzu, um sicherzustellen, dass der Server die Regeln befolgt. um das Recht des Nutzers zu gewährleisten, die Transaktion zurückzuziehen oder zu erzwingen; Mit der Freiheit der kollektiven Wahl, durch koordinierte Massenausstiege oder durch Änderung der Stimme der Sequenzer, dann haben Sie die meisten Vorteile von On-Chain geerntet, während Sie den größten Teil der Effizienz des Servers beibehalten haben.
• Kompromissmethode: Ein schnelles Netzwerk mit hundert Knotenpunkten bietet Ethereum zusätzliche Interoperabilität und Sicherheit. Dies ist derzeit die praktische Roadmap vieler L2-Projekte.

Für einige Anwendungen (z.B. ENS, Schlüsselspeicher, einige Zahlungsprotokolle) reicht eine Blockzeit von 12 Sekunden bereits aus. Für Anwendungen, die nicht geeignet sind, ist die einzige Lösung die Epoch-and-Slot-Architektur. In drei Fällen ist die "Epoch" das SSF von Ethereum, aber das Slot ist in den oben genannten drei Fällen jeweils unterschiedlich:

• Eine Ethereum-native Epoch-and-Slot-Architektur
• Server-Vorbestätigung
• Ausschussvorabbestätigung

Eine wichtige Frage ist, wie gut wir in Klasse 1 abschneiden können? Insbesondere, wenn es sehr gut wird, erscheint die Bedeutung von Klasse 3 nicht mehr so groß zu sein. Da alle "basierten" Lösungen nicht für Off-Chain-Daten wie Plasmen und Validiums geeignet sind, wird Klasse 2 immer existieren. Wenn eine Ethereum-native Epochen- und Slot-Struktur auf eine Slot-Zeit von 1 Sekunde reduziert werden kann, wird der Raum für Klasse 3 deutlich kleiner.

Heute sind wir noch weit von den endgültigen Antworten auf diese Fragen entfernt. Eine Schlüsselfrage ist, wie komplex die Blockvorschläge werden, und dies ist immer noch ein Bereich mit erheblicher Unsicherheit. Neuartige Designs wie Orbit SSF sind daher immer noch einen ausgiebigen Erkundungsraum wert, beispielsweise als Designraum für Vorschläge wie Orbit SSF als Epoche in epoch-and-slot. Je mehr Optionen wir haben, desto besser können wir für die Benutzer von L1 und L2 arbeiten und die Arbeit der L2-Entwickler vereinfachen.