„Die Epochen-und-Slot-Architektur ist offensichtlich die richtige Antwort, aber die Architektur- und Slot-Lösungen müssen noch erforscht werden.“

  • Originalautor |. Vitalik Buterin

  • Zusammenstellung |. Odaily Planet Daily Nan Zhi

Eines der wichtigen Merkmale einer guten Blockchain-Benutzererfahrung ist die schnelle Transaktionsbestätigungszeit. Heute ist Ethereum im Vergleich zu vor fünf Jahren deutlich besser geworden. Dank EIP-1559 und der stabilen Blockzeit nach der Umstellung auf PoS (The Merge) können von Benutzern auf L1 gesendete Transaktionen in der Regel innerhalb von 5–20 Sekunden bestätigt werden, was in etwa dem Erlebnis beim Bezahlen mit Kreditkarte entspricht. Es lohnt sich jedoch, das Benutzererlebnis weiter zu verbessern, und einige Anwendungen erfordern sogar Latenzen von Hunderten von Millisekunden oder weniger. In diesem Artikel werden einige praktische Optionen zur Verbesserung der Transaktionsbestätigungszeiten in Ethereum untersucht.

Überblick über bestehende Ideen und Techniken

Endgültigkeit eines einzelnen Slots

Derzeit verwendet der Gasper-Konsens von Ethereum einen einzelnen Slot (Slot) und eine Epoch-Architektur. Alle 12 Sekunden in einem Slot stimmt eine Untergruppe von Validatoren am Anfang der Kette ab, und alle 32 Slots (6,4 Minuten) haben alle Validatoren die Möglichkeit, einmal abzustimmen. Diese Stimmen werden dann in einem PBFT-ähnlichen Konsensalgorithmus als Nachrichten neu interpretiert, was nach zwei Epochen (12,8 Minuten) eine sehr starke wirtschaftliche Garantie namens Endgültigkeit ergibt.

(Odaily-Hinweis: Einzelheiten zu den spezifischen Prinzipien finden Sie unter „Detaillierte Erläuterung des Funktionsprinzips von Ethereum POS: Epoche, Slot und Beacon-Block“).

In den letzten Jahren sind wir mit unserem derzeitigen Ansatz zunehmend unzufrieden geworden. Dafür gibt es zwei Hauptgründe: Erstens ist die Methode kompliziert und es gibt viele Interaktionsfehler zwischen dem Slot-to-Slot-Abstimmungsmechanismus und dem Epoch-to-Epoch-Finalitätsmechanismus, und zweitens sind 12,8 Minuten zu lang und niemand möchte warte so lange.

Single Slot Finality (SSF) ersetzt diese Architektur durch einen Mechanismus ähnlich dem Tendermint-Konsens, bei dem Block N finalisiert wird, bevor Block N+1 generiert wird. Der Hauptunterschied zu Tendermint besteht darin, dass wir den „Inaktivitätsleck“-Mechanismus beibehalten, der es der Kette ermöglicht, weiterzulaufen und sich wiederherzustellen, wenn mehr als 1/3 der Validatoren offline sind.

(Odaily-Hinweis: Inaktivitätsleck ist ein Mechanismus in PoS, der dazu dient, Validatoren zu bestrafen, die über einen längeren Zeitraum inaktiv waren. Sobald sie als inaktiv markiert sind, wird ihre abgesteckte ETH weiterhin bestraft. Tendermint ist ein effizienter und sicherer byzantinischer Fehlertoleranz-Konsensalgorithmus, der dies ermöglicht für eine schnelle Transaktionsbestätigung und stellt sicher, dass das Blockchain-System auch dann normal funktionieren kann, wenn einige Knoten böswillig oder offline sind.)

Die größte Herausforderung bei der Single-Slot-Finalität besteht darin, dass jeder Ethereum-Staker alle 12 Sekunden zwei Nachrichten veröffentlichen muss, was eine erhebliche Belastung für die Kette darstellt. Es gibt einige clevere Ideen, um dieses Problem zu entschärfen, einschließlich des jüngsten Orbit SSF-Vorschlags. Obwohl dies die „Endgültigkeit“ erheblich beschleunigt und das Benutzererlebnis verbessert, ändert es nichts an der Tatsache, dass Benutzer 5 bis 20 Sekunden warten müssen.

(Odaily-Hinweis: Endgültigkeit und die Transaktion, die in einen Block gepackt und bestätigt wird, sind nicht dasselbe Ereignis. Wenn die Transaktion bestätigt, aber die Endgültigkeit nicht erreicht wird, kann es zu einer Verzweigung oder einem Rollback kommen.)

Rollup-Vorbestätigung

In den letzten Jahren verfolgte Ethereum eine Rollup-zentrierte Roadmap und entwarf die Ethereum-Basisschicht (L1), um die Datenverfügbarkeit und andere Funktionen zu unterstützen, die dann für L2-Protokolle wie Rollups, Validiums und Plasmen verfügbar sind Bietet Benutzern in größerem Maßstab das gleiche Maß an Sicherheit wie Ethereum.

Dadurch entsteht eine Trennung der Anliegen innerhalb des Ethereum-Ökosystems: Ethereum L1 konzentriert sich auf Zensurresistenz, Zuverlässigkeit, Stabilität sowie die Aufrechterhaltung und Verbesserung der Kernfunktionen einer bestimmten Basisschicht, während sich L2 darauf konzentriert, Benutzer direkter über verschiedene Kulturen und Technologien zu erreichen . Doch wenn man diesen Weg geht, entsteht zwangsläufig ein Problem: L2 möchte den Benutzern schnellere Bestätigungen als 5–20 Sekunden ermöglichen.

Bisher lag es, zumindest theoretisch, in der Verantwortung von L2, ein eigenes Netzwerk von „dezentralen Sequenzern“ aufzubauen. Eine kleine Gruppe von Validatoren signiert möglicherweise alle paar hundert Millisekunden Blöcke und steckt ihren Anteil hinter diesen Blöcken. Schließlich werden die Header-Dateien für diese L2-Blöcke auf L1 veröffentlicht.

Aber der L2-Validatorsatz kann „schummeln“: Er kann zuerst Block B 1 signieren und dann einen widersprüchlichen Block B 2 signieren und ihn vor B 1 in die Kette übernehmen. Aber wenn sie es doch tun, werden sie erwischt und verlieren ihr verpfändetes Vermögen. Wir haben tatsächlich praktische Beispiele zentralisierter Versionen gesehen, aber Rollup hat sich bei der Entwicklung eines dezentralen Sortiernetzwerks nur langsam entwickelt. Man könnte argumentieren, dass es unfair ist, eine dezentrale Anordnung aller L2s zu fordern: Wir verlangen vom Rollup, dass es im Wesentlichen die gleiche Aufgabe erfüllt wie die Erstellung eines völlig neuen L1. Aus diesem Grund hat Justin Drake eine Möglichkeit für alle L2 (und damit L1) befürwortet, einen gemeinsamen Ethereum-weiten Vorbestätigungsmechanismus zu verwenden: die Basisvorbestätigung.

Grundlegende Vorbestätigung

Der Ansatz zur basierten Vorbestätigung geht davon aus, dass es sich bei den Ethereum-Antragstellern um hochentwickelte Teilnehmer im Zusammenhang mit MEV handelt. Vorbestätigungsbasierte Ansätze nutzen diese Komplexität aus, indem sie diese komplexen Antragsteller dazu anregen, die Verantwortung für die Bereitstellung von Vorbestätigungsdiensten zu übernehmen.

Die Grundidee dieses Ansatzes besteht darin, ein standardisiertes Protokoll zu erstellen, bei dem Benutzer eine zusätzliche Gebühr erheben können, um eine sofortige Garantie dafür zu gewährleisten, dass eine Transaktion in den nächsten Block aufgenommen wird, sowie einen Anspruch auf die Ergebnisse der Ausführung dieser Transaktion. Wenn ein Antragsteller ein gegenüber einem Benutzer gegebenes Versprechen bricht, kann er gekürzt werden.

Wie bereits erwähnt, werden L1-Transaktionen auf der Grundlage einer Vorbestätigung garantiert. Wenn Rollups „basiert“ sind, dann sind alle L2-Blöcke L1-Transaktionen, sodass derselbe Mechanismus verwendet werden kann, um eine Vorbestätigung für alle L2 bereitzustellen.

(Odaily-Hinweis: Ethereum-Antragsteller können den Gebührenmechanismus verwenden, um eine Reihe von Transaktionen zu einem Bündel zu bündeln und in einen Block zu packen, um die Ausführung und Reihenfolge der Transaktionen sicherzustellen. Beispielsweise stellt der bekannte Clip sicher, dass vor einer bestimmten Transaktion gekauft und verkauft wird Der hier von Vitalik vorgeschlagene Plan ist konzeptionell derselbe. Verwenden Sie diesen Vorschlag, um die Transaktionsergebnisse im Voraus zu sichern und die Ausführung zu beschleunigen.

Was sehen wir eigentlich?

Angenommen, wir erreichen die Endgültigkeit eines einzelnen Slots. Wir verwenden eine ähnliche Technologie wie Orbit, um die Anzahl der Validatoren, die pro Slot signieren, zu reduzieren, jedoch nicht zu sehr, damit wir auch bei unserem Hauptziel, der Reduzierung des Mindesteinsatzes von 32 ETH, Fortschritte machen können. Die Slot-Zeit kann auf 16 Sekunden erhöht werden. Anschließend verwenden wir die Rollup-Vorbestätigung oder die einfache Vorbestätigung, um den Benutzern eine schnellere Bestätigung zu ermöglichen. Was wir am Ende haben: eine Epochen-Slot-Architektur.

Es gibt einen tiefgreifenden philosophischen Grund, warum die Epochen-und-Slot-Architektur so schwer zu vermeiden scheint: Es dauert weniger Zeit, sich auf etwas zu einigen, das den größtmöglichen Grad an „wirtschaftlicher Endgültigkeit“ aufweist.

Ein einfacher Grund ist die Anzahl der Knoten. Während der alte Kompromiss zwischen linearer Dezentralisierung, Endgültigkeitszeit und Overhead aufgrund der hochoptimierten BLS-Aggregation und der bevorstehenden ZK-STARKs jetzt mild erscheint, können die folgenden Gründe nicht ignoriert werden:

  1. „Annähernder Konsens“ erfordert nur eine kleine Anzahl von Knoten, während für wirtschaftliche Endgültigkeit eine Mehrheit von Knoten erforderlich ist.

  2. Sobald die Anzahl der Knoten eine bestimmte Größe überschreitet, müssen Sie mehr Zeit für das Sammeln von Signaturen aufwenden.

Im heutigen Ethereum ist der 12-Sekunden-Slot in drei Unterslots unterteilt: Blockveröffentlichung und -verteilung, Attestierung und Attestierungsaggregation. Wenn die Anzahl der Prüfer erheblich reduziert wird, können wir sie auf zwei Subslots reduzieren und eine Slotzeit von 8 Sekunden verwenden. Ein weiterer wichtiger Faktor ist die „Qualität“ des Knotens. Wenn wir uns auch auf eine spezialisierte Teilmenge von Knoten verlassen könnten, um eine ungefähre Übereinstimmung zu erzielen (und trotzdem den gesamten Satz von Validatoren verwenden, um die Endgültigkeit zu bestimmen), könnten wir diese Zeit auf etwa 2 Sekunden reduzieren.

Meiner Meinung nach ist die Epochen-und-Slot-Architektur eindeutig richtig, aber nicht alle Epochen-und-Slot-Architekturen sind gleich, und es lohnt sich, den Designraum umfassender zu erkunden. Eine Richtung, die es wert ist, weiter erforscht zu werden, ist nicht so eng gekoppelt wie Gasper, weist aber eine stärkere Trennung der Bedenken zwischen den beiden Mechanismen auf.

Was soll L2 tun?

Meiner Meinung nach verfügt L2 derzeit über drei sinnvolle Strategien:

1. Es ist sowohl technisch als auch spirituell „basiert“. Das heißt, sie optimieren die technischen Eigenschaften der Basisschicht von Ethereum und ihre Werte (hohe Dezentralisierung, Zensurresistenz usw.). In ihrer einfachsten Form kann man sich diese Rollups als „Marken-Shards“ vorstellen, sie können aber auch viel ehrgeiziger sein und intensiv mit neuen Designs virtueller Maschinen und anderen technischen Verbesserungen experimentieren.

2. Werden Sie ein „Server mit Blockchain-Gerüst“ und machen Sie das Beste daraus. Wenn Sie mit einem Server beginnen und dann Beweise für die STARK-Gültigkeit hinzufügen, um sicherzustellen, dass der Server die Regeln befolgt, um das Recht der Benutzer zu gewährleisten, Transaktionen abzuheben oder zu erzwingen, und um die Freiheit der kollektiven Wahl zu gewährleisten, entweder durch koordinierte Massenabhebungen oder durch Eine Abstimmung der Change Orderer, dann haben Sie die meisten Vorteile des On-Chain-Einsatzes erhalten und gleichzeitig die Effizienz des Servers zum größten Teil beibehalten. (Odaily-Hinweis: Scaffolding bezieht sich auf ein Tool oder eine Methode, die automatisch die Grundstruktur und das Code-Framework eines Projekts generiert, damit Entwickler schnell mit dem Codieren beginnen können.)

3. Ein Mittelweg: Ethereum ist eine schnelle Kette mit hundert Knoten und bietet zusätzliche Interoperabilität und Sicherheit. Dies ist derzeit die eigentliche Roadmap für viele L2-Projekte.

Für einige Anwendungen (z. B. ENS, Schlüsselspeicherung, einige Zahlungsprotokolle) ist eine Blockzeit von 12 Sekunden ausreichend. Für Anwendungen, bei denen dies nicht anwendbar ist, ist die einzige Lösung eine Epochen-und-Slot-Architektur. In allen drei Fällen ist die „Epoche“ das SSF von Ethereum, aber der Slot ist in jedem der drei Fälle unterschiedlich:

  1. Eine Ethereum-native Epochen- und Slot-Architektur

  2. Vorabbestätigung des Servers

  3. Vorabbestätigung des Ausschusses

Eine Schlüsselfrage ist: Wie gut können wir in Kategorie 1 sein? Besonders wenn es wirklich gut wird, hat man das Gefühl, dass Kategorie 3 nicht so viel bedeutet. Da nicht alle „basierten“ Lösungen auf Off-Chain-Daten L2 wie Plasmen und Validien anwendbar sind, wird es immer Kategorie 2 geben. Wenn eine in Ethereum native Epochen- und Slot-Architektur auf eine Slot-Zeit von 1 Sekunde reduziert werden könnte, würde der Klasse-3-Raum viel kleiner werden.

Heute sind wir noch lange von endgültigen Antworten auf diese Fragen entfernt. Eine Schlüsselfrage ist, wie komplex Blockvorschlagsberechtigte werden werden, was nach wie vor ein Bereich mit erheblicher Unsicherheit ist. Designs wie Orbit SSF sind sehr neuartig, daher lohnt es sich immer noch, den Designraum für Schemata wie Orbit SSF als Epoche in einem Epochen-und-Slot vollständig zu erkunden. Je mehr Optionen wir haben, desto besser können wir für Benutzer von L1 und L2 sein und das Leben für L2-Entwickler einfacher machen.

Ursprünglicher Link

Dieser Artikel wird mit Genehmigung von Odaily Planet Daily abgedruckt

Quelle