Single-Slot-Finalität
Es dauert etwa 15 Minuten, bis ein Ethereum-Block finalisiert ist. Wir können jedoch den Konsensmechanismus von Ethereum so anpassen, dass Blöcke effizienter validiert werden und die Zeit bis zur Finalität drastisch verkürzt wird. Anstatt 15 Minuten zu warten, könnten Blöcke im selben Slot vorgeschlagen und finalisiert werden. Dieses Konzept ist als Single-Slot-Finalität (SSF) bekannt.
Was ist Finalität?
Im Proof-of-Stake-basierten Konsensmechanismus von Ethereum bezieht sich Finalität auf die Garantie, dass ein Block nicht geändert oder aus der Blockchain entfernt werden kann, ohne dass mindestens 33 % der gesamten als Einsatz hinterlegten ETH verbrannt werden. Dies ist eine „kryptoökonomische“ Sicherheit, da das Vertrauen aus den extrem hohen Kosten resultiert, die mit der Änderung der Reihenfolge oder des Inhalts der Chain verbunden sind, was jeden rationalen wirtschaftlichen Akteur davon abhalten würde, es zu versuchen.
Warum eine schnellere Finalität anstreben?
Die aktuelle Zeit bis zur Finalität hat sich als zu lang erwiesen. Die meisten Benutzer möchten nicht 15 Minuten auf die Finalität warten, und es ist unpraktisch für Apps und Börsen, die möglicherweise einen hohen Transaktionsdurchsatz wünschen, so lange warten zu müssen, um sicher zu sein, dass ihre Transaktionen dauerhaft sind. Eine Verzögerung zwischen dem Vorschlag und der Finalisierung eines Blocks schafft auch eine Gelegenheit für kurze Reorganisationen (Reorgs), die ein Angreifer nutzen könnte, um bestimmte Blöcke zu zensieren oder MEV zu extrahieren. Der Mechanismus, der sich mit der stufenweisen Aktualisierung von Blöcken befasst, ist ebenfalls recht komplex und wurde mehrmals gepatcht, um Sicherheitslücken zu schließen, was ihn zu einem der Teile der Ethereum-Codebasis macht, in denen subtile Fehler wahrscheinlicher auftreten. All diese Probleme könnten beseitigt werden, indem die Zeit bis zur Finalität auf einen einzigen Slot reduziert wird.
Der Kompromiss zwischen Dezentralisierung, Zeit und Aufwand
Die Finalitätsgarantie ist keine sofortige Eigenschaft eines neuen Blocks; es dauert seine Zeit, bis ein neuer Block finalisiert ist. Der Grund dafür ist, dass Validatoren, die mindestens 2/3 der gesamten als Einsatz hinterlegten ETH im Netzwerk repräsentieren, für den Block abstimmen („bestätigen“) müssen, damit er als finalisiert gilt. Jeder validierende Blockchain-Knoten im Netzwerk muss Bestätigungen von anderen Blockchain-Knoten verarbeiten, um zu wissen, ob ein Block diesen 2/3-Schwellenwert erreicht hat oder nicht.
Je kürzer die zulässige Zeit bis zur Finalisierung ist, desto mehr Rechenleistung wird an jedem Blockchain-Knoten benötigt, da die Verarbeitung der Bestätigungen schneller erfolgen muss. Je mehr validierende Blockchain-Knoten im Netzwerk existieren, desto mehr Bestätigungen müssen für jeden Block verarbeitet werden, was ebenfalls die erforderliche Rechenleistung erhöht. Je mehr Rechenleistung erforderlich ist, desto weniger Personen können teilnehmen, da teurere Hardware benötigt wird, um jeden validierenden Blockchain-Knoten zu betreiben. Eine Erhöhung der Zeit zwischen den Blöcken verringert die an jedem Blockchain-Knoten erforderliche Rechenleistung, verlängert aber auch die Zeit bis zur Finalität, da Bestätigungen langsamer verarbeitet werden.
Daher gibt es einen Kompromiss zwischen dem Aufwand (Rechenleistung), der Dezentralisierung (Anzahl der Blockchain-Knoten, die an der Validierung der Chain teilnehmen können) und der Zeit bis zur Finalität. Das ideale System balanciert minimale Rechenleistung, maximale Dezentralisierung und minimale Zeit bis zur Finalität aus.
Der aktuelle Konsensmechanismus von Ethereum hat diese drei Parameter wie folgt ausbalanciert:
- Festlegung des Mindesteinsatzes auf 32 ETH. Dies setzt eine Obergrenze für die Anzahl der Bestätigungen der Validatoren, die von einzelnen Blockchain-Knoten verarbeitet werden müssen, und somit eine Obergrenze für die Rechenanforderungen jedes Blockchain-Knotens.
- Festlegung der Zeit bis zur Finalität auf ~15 Minuten. Dies gibt Validatoren, die auf normalen Heimcomputern ausgeführt werden, ausreichend Zeit, um Bestätigungen für jeden Block sicher zu verarbeiten.
Mit dem aktuellen Design des Mechanismus ist es zur Reduzierung der Zeit bis zur Finalität erforderlich, die Anzahl der Validatoren im Netzwerk zu verringern oder die Hardwareanforderungen für jeden Blockchain-Knoten zu erhöhen. Es gibt jedoch Verbesserungen, die an der Art und Weise vorgenommen werden können, wie Bestätigungen verarbeitet werden, sodass mehr Bestätigungen gezählt werden können, ohne den Aufwand an jedem Blockchain-Knoten zu erhöhen. Die effizientere Verarbeitung wird es ermöglichen, die Finalität innerhalb eines einzigen Slots anstatt über zwei Epochen hinweg zu bestimmen.
Wege zur SSF
Seit dem Entwurf des Ethereum-Konsensmechanismus hat sich das Signatur-Aggregationsschema (BLS) als weitaus skalierbarer erwiesen als ursprünglich angenommen, während sich auch die Fähigkeit von Anwendungen verbessert hat, Signaturen zu verarbeiten und zu verifizieren. Es stellt sich heraus, dass die Verarbeitung von Bestätigungen einer riesigen Anzahl von Validatoren tatsächlich innerhalb eines einzigen Slots möglich ist. Wenn beispielsweise eine Million Validatoren jeweils zweimal in jedem Slot abstimmen und die Slot-Zeiten auf 16 Sekunden angepasst werden, müssten Blockchain-Knoten Signaturen mit einer Mindestrate von 125.000 Aggregationen pro Sekunde verifizieren, um alle 1 Million Bestätigungen innerhalb des Slots zu verarbeiten. In der Realität benötigt ein normaler Computer etwa 500 Nanosekunden für eine Signaturverifizierung, was bedeutet, dass 125.000 in ~62,5 ms durchgeführt werden können – weit unter der Ein-Sekunden-Grenze.
Weitere Effizienzgewinne könnten durch die Schaffung von Superkomitees mit z. B. 125.000 zufällig ausgewählten Validatoren pro Slot erzielt werden. Nur diese Validatoren dürfen über einen Block abstimmen, und daher entscheidet nur diese Teilmenge von Validatoren, ob ein Block finalisiert wird. Ob dies eine gute Idee ist oder nicht, hängt davon ab, wie teuer ein erfolgreicher Angriff auf Ethereum nach Ansicht der Community sein sollte. Denn anstatt 2/3 der gesamten als Einsatz hinterlegten Ether zu benötigen, könnte ein Angreifer einen unehrlichen Block mit 2/3 der als Einsatz hinterlegten Ether in diesem Superkomitee finalisieren. Dies ist noch ein aktives Forschungsgebiet, aber es erscheint plausibel, dass bei einer Menge an Validatoren, die groß genug ist, um überhaupt Superkomitees zu erfordern, die Kosten für einen Angriff auf eines dieser Subkomitees extrem hoch sein werden (z. B. würden die in ETH denominierten Angriffskosten 2/3 * 125.000 * 32 = ~2,6 Millionen ETH betragen). Die Angriffskosten können durch Erhöhung der Größe der Validatoren-Menge angepasst werden (z. B. die Validatoren-Größe so abstimmen, dass die Angriffskosten 1 Million Ether, 4 Millionen Ether, 10 Millionen Ether usw. entsprechen). Vorläufige Umfragen (opens in a new tab) in der Community deuten darauf hin, dass 1-2 Millionen Ether akzeptable Angriffskosten sind, was ~65.536 - 97.152 Validatoren pro Superkomitee impliziert.
Die Verifizierung ist jedoch nicht der wahre Engpass – es ist die Signatur-Aggregation, die validierende Blockchain-Knoten wirklich herausfordert. Um die Signatur-Aggregation zu skalieren, wird es wahrscheinlich erforderlich sein, die Anzahl der Validatoren in jedem Subnetz zu erhöhen, die Anzahl der Subnetze zu erhöhen oder zusätzliche Aggregationsebenen hinzuzufügen (d. h. Komitees von Komitees zu implementieren). Ein Teil der Lösung könnte darin bestehen, spezialisierte Aggregatoren zuzulassen – ähnlich wie die Block-Erstellung und die Generierung von Commitments für Rollups-Daten im Rahmen der Proposer-Builder Separation (PBS) und Danksharding an spezialisierte Block-Ersteller ausgelagert werden.
Welche Rolle spielt die Fork-Choice-Regel bei SSF?
Der heutige Konsensmechanismus beruht auf einer engen Kopplung zwischen dem Finalitäts-Gadget (dem Algorithmus, der bestimmt, ob 2/3 der Validatoren eine bestimmte Chain bestätigt haben) und der Fork-Choice-Regel (dem Algorithmus, der entscheidet, welche Chain die richtige ist, wenn es mehrere Optionen gibt). Der Fork-Choice-Algorithmus berücksichtigt nur Blöcke seit dem letzten finalisierten Block. Unter SSF gäbe es keine Blöcke, die die Fork-Choice-Regel berücksichtigen könnte, da die Finalität im selben Slot eintritt, in dem der Block vorgeschlagen wird. Das bedeutet, dass unter SSF zu jedem Zeitpunkt entweder der Fork-Choice-Algorithmus oder das Finalitäts-Gadget aktiv wäre. Das Finalitäts-Gadget würde Blöcke finalisieren, bei denen 2/3 der Validatoren online waren und ehrlich bestätigt haben. Wenn ein Block den 2/3-Schwellenwert nicht überschreiten kann, würde die Fork-Choice-Regel eingreifen, um zu bestimmen, welcher Chain gefolgt werden soll. Dies schafft auch die Möglichkeit, den Inactivity-Leak-Mechanismus beizubehalten, der eine Chain wiederherstellt, bei der >1/3 der Validatoren offline gehen, wenn auch mit einigen zusätzlichen Nuancen.
Offene Probleme
Das Problem bei der Skalierung der Aggregation durch Erhöhung der Anzahl der Validatoren pro Subnetz besteht darin, dass dies zu einer größeren Belastung des Peer-to-Peer-Netzwerks führt. Das Problem beim Hinzufügen von Aggregationsebenen ist, dass es technisch recht komplex ist und Latenz hinzufügt (d. h. es könnte länger dauern, bis der Block-Vorschlagende von allen Subnetz-Aggregatoren hört). Es ist auch unklar, wie mit dem Szenario umgegangen werden soll, dass es mehr aktive Validatoren im Netzwerk gibt, als in jedem Slot machbar verarbeitet werden können, selbst mit BLS-Signatur-Aggregation. Eine mögliche Lösung besteht darin, dass, da alle Validatoren in jedem Slot bestätigen und es unter SSF keine Komitees gibt, die Obergrenze von 32 ETH für das effektive Guthaben vollständig aufgehoben werden könnte. Das bedeutet, dass Betreiber, die mehrere Validatoren verwalten, ihren Einsatz konsolidieren und weniger betreiben könnten, wodurch die Anzahl der Nachrichten reduziert wird, die validierende Blockchain-Knoten verarbeiten müssen, um die gesamte Validatoren-Menge zu berücksichtigen. Dies setzt voraus, dass große Staker zustimmen, ihre Validatoren zu konsolidieren. Es ist auch möglich, jederzeit eine feste Obergrenze für die Anzahl der Validatoren oder die Menge der als Einsatz hinterlegten ETH festzulegen. Dies erfordert jedoch einen Mechanismus zur Entscheidung, welche Validatoren teilnehmen dürfen und welche nicht, was wahrscheinlich unerwünschte Nebeneffekte hervorruft.
Aktueller Fortschritt
SSF befindet sich in der Forschungsphase. Es wird nicht erwartet, dass es in den nächsten Jahren eingeführt wird, wahrscheinlich erst nach anderen wesentlichen Upgrades wie Verkle-Bäumen und Danksharding.
Weiterführende Literatur
- Vitalik über SSF auf der EDCON 2022 (opens in a new tab)
- Vitaliks Notizen: Wege zur Single-Slot-Finalität (opens in a new tab)
Letzte Aktualisierung der Seite: 23. Februar 2026
