*Weiterleitung des Originaltitels 'Epochs and slots all the way down: Wege, um Ethereum-Benutzern schnellere Transaktionsbestätigungszeiten zu bieten'

Eine der wichtigen Eigenschaften eines guten Benutzererlebnisses in der Blockchain ist die schnelle Bestätigungszeit für Transaktionen. Heute hat sich Ethereum im Vergleich zu vor fünf Jahren bereits stark verbessert. Dies ist auf die Kombination vonEIP-1559und gleichmäßige Blockzeiten nachdie Fusion, Transaktionen, die von Benutzern auf L1 gesendet werden, bestätigen zuverlässig innerhalb von 5-20 Sekunden. Dies ist ungefähr wettbewerbsfähig mit der Erfahrung, mit einer Kreditkarte zu bezahlen. Es gibt jedoch einen Mehrwert darin, die Benutzererfahrung weiter zu verbessern, und es gibt einige Anwendungen, die Latenzzeiten im Bereich von Hunderten von Millisekunden oder sogar weniger erfordern. In diesem Beitrag werden einige praktische Optionen erläutert, die Ethereum hat.

Überblick über bestehende Ideen und Techniken

Einzelslot-Endgültigkeit

Heute, Ethereum’s GasperDer Konsens verwendet eine Slot- und Epoch-Architektur. In jedem 12-Sekunden-Slot veröffentlicht eine Teilmenge der Validatoren eine Abstimmung über den Kopf der Kette und im Laufe von 32 Slots (6,4 min) haben alle Validatoren einmal die Chance zu wählen. Diese Stimmen werden dann als Nachrichten in einem vagen Sinne neu interpretiert. PBFT-ähnlichKonsensalgorithmus, der nach zwei Epochen (12,8 Minuten) eine sehr hohe wirtschaftliche Sicherheit namens Endgültigkeit bietet.

In den letzten Jahren sind wir mit dem aktuellen Ansatz immer unzufriedener geworden. Die Hauptgründe dafür sind, dass (i) es kompliziert ist und es viele Interaktionsfehler zwischen dem Slot-für-Slot-Abstimmungsmechanismus und dem Epoch-für-Epoch-Endgültigkeitsmechanismus gibt und (ii) 12,8 Minuten viel zu lange sind und sich niemand die Mühe machen will, so lange zu warten.

Einzelschlitzzuverlässigkeit ersetzt diese Architektur durch einen Mechanismus, der dem viel ähnlicher istTendermint-Konsens, bei dem der Block N vor der Erstellung des Blocks N+1 finalisiert wird. Der Hauptunterschied zu Tendermint besteht darin, dass wir die " Inaktivitätsleck„Mechanismus, der es der Kette ermöglicht, weiterzulaufen und sich zu erholen, wenn mehr als 1/3 der Validatoren offline gehen.“

Ein Diagramm des führenden vorgeschlagenen Design mit Einzel-Slot-Endgültigkeit_

Die Hauptherausforderung bei SSF besteht darin, dass es auf den ersten Blick nahelegt, dass jeder einzelne Ethereum-Staker alle 12 Sekunden zwei Nachrichten veröffentlichen müsste, was für die Chain eine große Belastung wäre. Es gibt kluge Ideenfür wie man dies mildern kann, einschließlich des sehr aktuellenOrbit SSFVorschlag. Aber selbst wenn dies die Benutzererfahrung erheblich verbessert, indem die "Endgültigkeit" schneller erreicht wird, ändert es nichts daran, dass die Benutzer 5-20 Sekunden warten müssen.

Rollup Vorbestätigungen

In den letzten Jahren hat Ethereum eineRoadmap mit Fokus auf Rollup, das Design der Ethereum-Basis (auch bekannt als „L1“) mit dem Ziel, Datenverfügbarkeitund andere Funktionalitäten, die dann von Layer-2-Protokollen wie verwendet werden könnenRollups(aber auchvalidiumsundPlasmen) , die den Benutzern dasselbe Sicherheitsniveau wie Ethereum bieten kann, jedoch in einem viel größeren Maßstab.

Dies schafft eine Trennung der Anliegenim Ethereum-Ökosystem: Das Ethereum L1 kann sich darauf konzentrieren, zensurresistent, zuverlässig, stabil zu sein und eine bestimmte Grundfunktionalität aufrechtzuerhalten und zu verbessern, und die L2s können sich darauf konzentrieren, direkter auf Benutzer zuzugreifen - sowohl durch verschiedenekulturellund technologische Kompromisse. Aber wenn Sie diesen Weg gehen, tritt ein unvermeidliches Problem auf: L2s möchten Benutzer bedienen, die Bestätigungen viel schneller als 5-20 Sekunden wünschen.

Bisher war es zumindest in der Rhetorik die Verantwortung von L2s, ihre eigenen "dezentralen Sequenzierungs"-Netzwerke zu erstellen. Eine kleinere Gruppe von Validatoren würde Blöcke abzeichnen, vielleicht einmal alle paar hundert Millisekunden, und sie würden ihren "Einsatz" hinter diese Blöcke setzen. Schließlich werden die Header dieser L2-Blöcke auf L1 veröffentlicht.

L2-Validatoren könnten betrügen: Sie könnten zuerst Block B1 unterzeichnen und später einen widersprüchlichen Block B2 unterzeichnen und ihn vor B1 auf die Kette setzen. Aber wenn sie das tun, würden sie erwischt und ihre Einlagen verlieren. In der Praxis haben wir zentralisierte Versionen davon gesehen, aber Rollups haben sich langsam entwickelt, um dezentrale Sequenzierungsnetzwerke zu entwickeln. Und man kann argumentieren, dass es unfair ist, von allen L2s zu verlangen, dass sie eine dezentrale Sequenzierung durchführen: Wir verlangen von Rollups im Grunde genommen, dass sie die meiste Arbeit wie die Schaffung eines vollständig neuen L1 leisten. Aus diesem und anderen Gründen hat Justin Drake die Förderung eines Weges zur Verfügung gestellt, um allen L2s (sowie L1) Zugang zu einem gemeinsamen, Ethereum-weiten Vorbestätigungsmechanismus zu geben: basierte Vorbestätigungen.

Vorbestätigungen auf Basis

Die auf der Basis der Vorbestätigungsmethode beruht, geht davon aus, dass die Ethereum-Vorschlagenden aus MEV-bezogenen Gründen zu hochentwickelten Akteuren werden (siehe hierFür meine Erklärung von MEV und siehe auch das Ausführungstickets Vorschlagslinie). Der basierte Preconfirmation-Ansatz macht sich diese Raffinesse zunutze, indem er diesen erfahrenen Bietern einen Anreiz bietet, die Verantwortung für das Angebot von Preconfirmations-as-a-Service zu übernehmen.

Die Grundidee besteht darin, ein standardisiertes Protokoll zu erstellen, mit dem ein Benutzer eine zusätzliche Gebühr anbieten kann, um eine sofortige Garantie dafür zu erhalten, dass die Transaktion im nächsten Block enthalten ist, möglicherweise zusammen mit einer Behauptung über die Ergebnisse der Ausführung dieser Transaktion. Wenn der Antragsteller seine Versprechen gegenüber einem Benutzer nicht einhält, kann er bestraft werden.

Wie beschrieben, bieten vorbestätigte Transaktionen Garantien für L1-Transaktionen. Wenn Rollups verwendet werden, "basiert", dann sind alle L2-Blöcke L1-Transaktionen, und so kann der gleiche Mechanismus verwendet werden, um Vorbestätigungen für jeden L2 bereitzustellen.

Worauf schauen wir hier eigentlich?

Angenommen, wir implementieren eine endgültige Einzelslot. Wir verwenden Orbit-ähnliche Techniken, um die Anzahl der Validatoren, die pro Slot unterschreiben, zu reduzieren, aber nicht zu sehr, damit wir auch Fortschritte bei dem Hauptziel machen können, das Minimum von 32 ETH zu reduzieren. Dadurch kann es sein, dass sich die Slot-Zeit auf 16 Sekunden erhöht. Wir verwenden dann entweder Rollup-Vorbestätigungen oder basierte Vorbestätigungen, um den Benutzern schnellere Zusicherungen zu geben. Was haben wir jetzt? Eine Epochen- und Slot-Architektur.

Das Meme „sie sind das gleiche Bild“ wird langsam ziemlich überstrapaziert, daher werde ich einfach eine alte Zeichnung, die ich vor Jahren erstellt habe, neben ein Diagramm von Gasper's Slot- und Epoch-Architektur und ein Diagramm von L2-Präbestätigungen stellen und hoffentlich wird das den Punkt verdeutlichen.

Es gibt einen tiefgründigen philosophischen Grund, warum Epoch- und Slot-Architekturen scheinbar so schwer zu vermeiden sind: Es dauert von Natur aus weniger Zeit, um eine ungefähre Einigung über etwas zu erzielen, als um eine maximal verfestigte "wirtschaftliche Endgültigkeit" darüber zu erzielen.

Ein einfacher Grund dafür ist die Anzahl der Knotenpunkte. Während das alte lineare @VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">die Abwägung von Dezentralisierung / Endgültigkeit / Overhead-Zeit ist jetzt aufgrund der hyperoptimierten BLS-Aggregation und in naher Zukunft ZK-STARKs milder, es ist jedoch nach wie vor grundlegend wahr, dass:

1. "Ungefähre Einigung" erfordert nur wenige Knoten, während wirtschaftliche Endgültigkeit einen signifikanten Anteil aller Knoten erfordert.
2. Sobald die Anzahl der Knoten eine bestimmte Größe überschreitet, müssen Sie mehr Zeit aufwenden, um Signaturen zu sammeln.

Heute wird bei Ethereum ein 12-Sekunden-Slot in drei Unter-Slots unterteilt, für (i) Blockveröffentlichung und -verteilung, (ii) Beglaubigung und (iii) Beglaubigungsaggregation. Wenn die Anzahl der Beglaubiger deutlich geringer wäre, könnten wir auf zwei Unter-Slots umsteigen und eine 8-Sekunden-Slot-Zeit haben. Ein weiterer, und realistischerweise größerer, Faktor ist die "Qualität" der Knoten. Wenn wir uns auch auf einen professionalisierten Teilbereich von Knoten verlassen könnten, um ungefähre Vereinbarungen zu treffen (und dennoch den vollständigen Validatoren-Satz für die Endgültigkeit zu verwenden), könnten wir das plausiblerweise auf ~2 Sekunden reduzieren.

Daher habe ich das Gefühl, dass (i) Slot- und Epoch-Architekturen offensichtlich korrekt sind, aber auch (ii) nicht alle Slot- und Epoch-Architekturen gleich geschaffen sind und es wert ist, den Designraum vollständiger zu erkunden. Insbesondere lohnt es sich, Optionen zu erkunden, die nicht eng miteinander verflochten sind wie Gasper, und bei denen stattdessen eine stärkere Trennung der Anliegen zwischen den beiden Mechanismen besteht.

Was sollten L2s tun?

Aus meiner Sicht gibt es derzeit drei vernünftige Strategien, die L2s verfolgen können:

1. Seien Sie sowohl technologisch als auch spirituell "basiert". Das heißt, sie optimieren darauf, Durchgangsleitungen für die technischen Eigenschaften der Ethereum-Basis-Plattform und ihre Werte (hohe Dezentralisierung, Zensurresistenz, etc.) zu sein. In ihrer einfachsten Form könnten Sie sich diese Rollups als "markenbehaftete Shards" vorstellen, aber sie können auch viel ehrgeiziger sein und recht stark mit neuen Designs virtueller Maschinen und anderen technischen Verbesserungen experimentieren.
2. Sei stolz darauf, ein „Server mit Blockchain-Gerüst“ zu sein und das Beste daraus zu machen. Wenn du von einem Server ausgehst und dann (i) STARK-Gültigkeitsnachweise hinzufügst, um sicherzustellen, dass der Server den Regeln folgt, (ii) garantierte Rechte für den Benutzer, um Transaktionen zu beenden oder zu erzwingen, und möglicherweise (iii) die Freiheit der kollektiven Entscheidung, entweder durch koordinierten Massenaustritt oder durch die Möglichkeit zur Abstimmung, um den Sequencer zu ändern, dann hast du bereits viele Vorteile einer On-Chain-Lösung erlangt, während du die Effizienz eines Servers weitgehend beibehältst.
3. Der Kompromissansatz: eine hundertknotige Schnellkette, bei der Ethereum zusätzliche Interoperabilität und Sicherheit bietet. Dies ist der faktische aktuelle Fahrplan vieler L2-Projekte.

Für einige Anwendungen (z. B. ENS, Keystores), einige Zahlungen), eine Blockzeit von 12 Sekunden ausreicht. Für Anwendungen, die dies nicht tun, ist die einzige Lösung eine Slot- und Epoch-Architektur. In allen drei Fällen sind die „Epochen“ das SSF von Ethereum (vielleicht können wir dieses Akronym nachträglich so umdeuten, dass es etwas anderes als „Einzel-Slot“ bedeutet, z.B. könnte es „Sicher Schnelle Endgültigkeit“ sein). Aber die „Slots“ sind in jedem der oben genannten drei Fälle etwas anderes:

1. Eine Ethereum-native Slot- und Epochenarchitektur
2. Server-Vorbestätigungen
3. Ausschussvorbestätigungen

Eine Schlüsselfrage ist, wie gut können wir etwas in Kategorie (1) machen? Insbesondere, wenn es wirklich gut wird, dann scheint es, dass Kategorie (3) nicht mehr so viel Bedeutung hat. Kategorie (2) wird immer existieren, zumindest weil alles “basierte” für Off-Chain-Daten L2s wie Plasmas und Validiums nicht funktioniert. Aber wenn eine Ethereum-native Slot-und-Epochen-Architektur auf 1-Sekunden-“Slot” (d.h. Vor-Bestätigungs-)Zeiten kommen kann, dann wird der Raum für Kategorie (3) ziemlich viel kleiner.

Heute sind wir weit davon entfernt, endgültige Antworten auf diese Fragen zu haben. Eine wichtige Frage - wie raffiniert werden Blockvorschläge werden - bleibt ein Bereich, in dem es ziemlich viele Unsicherheiten gibt. Designs wie Orbit SSFsind sehr neu, was darauf hindeutet, dass der Designraum für Slot- und Epoch-Designs, bei denen so etwas wie Orbit SSF die Epoche ist, noch ziemlich unerforscht ist. Je mehr Optionen wir haben, desto besser können wir es für Benutzer sowohl auf L1 als auch auf L2s machen, und desto mehr können wir die Arbeit von L2-Entwicklern vereinfachen.

Haftungsausschluss：

1. Dieser Artikel wurde aus [reprinted] übersetztvitalik]. Weiterleiten des Originaltitels „Epochs and slots all the way down: ways to give Ethereum users faster transaction confirmation times“. Alle Urheberrechte gehören dem Originalautor [ vitalik*]. Wenn es Einwände gegen diesen Nachdruck gibt, kontaktieren Sie bitte die Gate LearnTeam, und sie werden es prompt erledigen.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel ausgedrückt werden, 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, Verteilen oder Plagiieren der übersetzten Artikel untersagt.