Vitalik: Welche Verbesserungen sind beim Ethereum PoS noch möglich und welche Wege zur Verbesserung gibt es?

Dieser Artikel konzentriert sich auf das Thema des Ethereum „Merge“: Welche Aspekte des technischen Designs des Proof-of-Stake können noch verbessert werden und welche Wege gibt es, diese Verbesserungen zu erreichen?

Autor:Vitalik Buterin

Übersetzung: Deng Tong, Jinse Finance

Besonderer Dank an Justin Drake, Hsiao-wei Wang, @antonttc und Francesco für ihr Feedback und ihre Durchsicht.

Ursprünglich bezeichnete der „Merge“ das wichtigste Ereignis in der Geschichte des Ethereum-Protokolls seit seiner Einführung: den lang erwarteten und schwer erkämpften Übergang vom Proof-of-Work zum Proof-of-Stake. Heute läuft Ethereum seit fast zwei Jahren als stabiles Proof-of-Stake-System, das sich in Bezug auf Stabilität, Leistung und Vermeidung von Zentralisierungsrisiken sehr gut bewährt hat. Dennoch gibt es im Proof-of-Stake noch einige wichtige Bereiche, die verbessert werden müssen.

Mein Fahrplan von 2023 unterteilt dies in mehrere Teile: Verbesserung technischer Eigenschaften wie Stabilität, Leistung und Zugänglichkeit für kleinere Validatoren sowie wirtschaftliche Veränderungen zur Bewältigung von Zentralisierungsrisiken. Ersteres übernahm den Titel „Merge“, während Letzteres Teil der „Scourge“ wurde.

Dieser Artikel konzentriert sich auf den „Merge“-Teil: Welche Aspekte des technischen Designs des Proof-of-Stake können noch verbessert werden und welche Wege gibt es, diese Verbesserungen zu erreichen?

Dies ist keine vollständige Liste aller möglichen Verbesserungen für Proof-of-Stake; vielmehr handelt es sich um eine Liste von Ideen, die derzeit aktiv diskutiert werden.

Single-Slot-Finalität und Demokratisierung des Stakings

Welches Problem lösen wir?

Derzeit dauert es 2-3 Epochen (ca. 15 Minuten), um einen Block zu finalisieren, und es werden 32 ETH benötigt, um Validator zu werden. Dies war ursprünglich ein Kompromiss, um ein Gleichgewicht zwischen drei Zielen zu erreichen:

• Maximierung der Anzahl der Validatoren, die am Staking teilnehmen können (was direkt bedeutet, den minimalen ETH-Betrag für das Staking zu minimieren)
• Minimierung der Finalisierungszeit
• Minimierung des Overheads für den Betrieb eines Knotens

Diese drei Ziele stehen im Widerspruch zueinander: Um wirtschaftliche Finalität zu erreichen (d. h. ein Angreifer muss eine große Menge ETH zerstören, um einen finalisierten Block rückgängig zu machen), muss jeder Validator bei jeder Finalisierung zwei Nachrichten signieren. Wenn Sie also viele Validatoren haben, dauert es entweder sehr lange, alle Signaturen zu verarbeiten, oder Sie benötigen sehr leistungsfähige Knoten, um alle Signaturen gleichzeitig zu verarbeiten.

Beachten Sie, dass dies alles von einem zentralen Ziel von Ethereum abhängt: sicherzustellen, dass selbst ein erfolgreicher Angriff für den Angreifer sehr teuer ist. Das ist die Bedeutung des Begriffs „wirtschaftliche Finalität“. Wenn wir dieses Ziel nicht hätten, könnten wir das Problem lösen, indem wir für jeden Slot ein zufällig ausgewähltes Komitee zur Finalisierung heranziehen (wie es z. B. Algorand tut). Das Problem bei diesem Ansatz ist jedoch, dass ein Angreifer, der tatsächlich 51 % der Validatoren kontrolliert, mit sehr geringen Kosten angreifen kann (Finalisierung rückgängig machen, Zensur oder Verzögerung der Finalisierung): Nur ein Teil der Knoten im Komitee kann als an dem Angriff beteiligt erkannt und bestraft werden, sei es durch Slashing oder eine Minderheits-Softfork. Das bedeutet, dass der Angreifer die Kette wiederholt angreifen kann. Wenn wir also wirtschaftliche Finalität wollen, funktioniert der einfache Komitee-basierte Ansatz nicht, und auf den ersten Blick brauchen wir tatsächlich die volle Beteiligung aller Validatoren.

Idealerweise möchten wir die wirtschaftliche Finalität beibehalten und gleichzeitig in zwei Bereichen Verbesserungen erzielen:

• Finalisierung von Blöcken innerhalb eines Slots (idealerweise Beibehaltung oder sogar Verkürzung der aktuellen 12 Sekunden), statt 15 Minuten
• Erlauben, dass Validatoren mit 1 ETH staken können (Reduzierung von 32 ETH auf 1 ETH)

Das erste Ziel wird von zwei Zielen angetrieben, die beide als „Angleichung der Eigenschaften von Ethereum an (zentralisiertere) leistungsorientierte L1-Chains“ betrachtet werden können.

Erstens stellt es sicher, dass alle Ethereum-Nutzer von dem durch den Finalisierungsmechanismus gebotenen höheren Sicherheitsniveau profitieren. Heute können die meisten Nutzer diesen Schutz nicht genießen, weil sie nicht bereit sind, 15 Minuten zu warten; mit Single-Slot-Finalität können Nutzer die Finalisierung praktisch sofort nach der Bestätigung ihrer Transaktion sehen. Zweitens, wenn Nutzer und Anwendungen sich keine Sorgen mehr über mögliche Chain-Reorgs machen müssen (außer in seltenen Fällen von Inactivity-Leak), vereinfacht dies das Protokoll und die umgebende Infrastruktur.

Das zweite Ziel ist der Wunsch, Einzelstaker zu unterstützen. Umfragen zeigen immer wieder, dass der Hauptgrund, warum mehr Menschen nicht einzeln staken, die Mindestgrenze von 32 ETH ist. Die Senkung der Mindestgrenze auf 1 ETH würde dieses Problem lösen, sodass andere Faktoren zu den Hauptgründen werden, die Einzelstaker einschränken.

Es gibt eine Herausforderung: Schnellere Finalität und das Ziel einer demokratischeren Staking stehen beide im Widerspruch zum Ziel der Minimierung des Overheads. Tatsächlich ist dies der Grund, warum wir ursprünglich keine Single-Slot-Finalität eingeführt haben. Neuere Forschungen haben jedoch einige mögliche Wege zur Lösung dieses Problems aufgezeigt.

Was ist das und wie funktioniert es?

Single-Slot-Finalität beinhaltet die Verwendung eines Konsensalgorithmus, der Blöcke innerhalb eines Slots finalisiert. Das ist an sich kein schwer zu erreichendes Ziel: Viele Algorithmen (z. B. Tendermint-Konsens) haben dies bereits mit optimalen Eigenschaften umgesetzt. Eine für Ethereum einzigartige Eigenschaft, die Tendermint nicht unterstützt, ist das Inactivity-Leak, das es der Chain ermöglicht, auch dann weiterzulaufen und sich zu erholen, wenn mehr als 1/3 der Validatoren offline sind. Glücklicherweise wurde dieser Wunsch bereits erfüllt: Es gibt bereits Vorschläge, Tendermint-ähnlichen Konsens an das Inactivity-Leak anzupassen.

Führende Vorschläge für Single-Slot-Finalität

Der schwierigste Teil des Problems ist herauszufinden, wie Single-Slot-Finalität bei einer sehr hohen Anzahl von Validatoren funktioniert, ohne dass der Overhead für Nodebetreiber extrem hoch wird. Dafür gibt es mehrere führende Lösungen:

Option 1: Brute-Force – Entwicklung besserer Signatur-Aggregationsprotokolle, möglicherweise unter Verwendung von ZK-SNARKs, die es tatsächlich ermöglichen, die Signaturen von Millionen Validatoren pro Slot zu verarbeiten.

Horn, eines der Designs für bessere Aggregationsprotokolle.

Option 2: Orbit-Komitee – Ein neuer Mechanismus, der es einem zufällig ausgewählten mittelgroßen Komitee ermöglicht, für die Finalisierung der Chain verantwortlich zu sein, jedoch auf eine Weise, die die gewünschten Angriffskosten-Eigenschaften beibehält.

Eine Möglichkeit, über Orbit SSF nachzudenken, ist, dass es einen Kompromissraum eröffnet, der von x=0 (Algorand-ähnliches Komitee, keine wirtschaftliche Finalität) bis x=1 (aktueller Stand von Ethereum) reicht und dazwischen Punkte schafft, bei denen Ethereum immer noch genügend wirtschaftliche Finalität für extreme Sicherheit hat, aber gleichzeitig den Effizienzvorteil erhält, dass pro Slot nur eine mittelgroße, zufällig ausgewählte Validatorenstichprobe teilnehmen muss.

Orbit nutzt die bereits vorhandene Heterogenität der Validator-Einlagen, um so viel wirtschaftliche Finalität wie möglich zu erreichen und gleichzeitig kleinen Validatoren entsprechende Rollen zuzuweisen. Außerdem verwendet Orbit eine langsame Komitee-Rotation, um eine hohe Überlappung zwischen benachbarten Quoren sicherzustellen, sodass die wirtschaftliche Finalität auch an den Grenzen der Komitee-Rotation erhalten bleibt.

Option 3: Zwei-Schichten-Staking – Ein Mechanismus, bei dem Staker in zwei Kategorien unterteilt werden, eine mit höheren und eine mit niedrigeren Einlagenanforderungen. Nur die Schicht mit höheren Einlagen nimmt direkt an der wirtschaftlichen Finalität teil. Es gibt verschiedene Vorschläge, welche Rechte und Pflichten die Schicht mit niedrigeren Einlagen genau haben sollte (siehe z. B. Rainbow Staking Post). Häufige Ideen sind:

• Das Recht, Anteile an die Staker der höheren Schicht zu delegieren
• Zufällig ausgewählte Staker der niedrigeren Schicht müssen jeden Block bestätigen
• Das Recht, Inclusion-Listen zu erstellen

Welche Verbindungen gibt es zu bestehenden Forschungen?

• Wege zur Umsetzung von Single-Slot-Finalität (2022):
• Konkrete Vorschläge für Ethereum Single-Slot-Finalitätsprotokolle (2023):
• Orbit SSF:
• Weitere Analysen zu Orbit-Mechanismen:
• Horn, Signatur-Aggregationsprotokoll (2022):
• Signaturzusammenführung für groß angelegten Konsens (2023):
• Signatur-Aggregationsprotokoll von Khovratovich et al.:
• STARK-basierte Signaturaggregation (2022):
• Rainbow Staking:

Was bleibt zu tun? Welche Abwägungen sind nötig?

Es gibt vier Hauptwege (wir können auch einen hybriden Weg wählen):

• Status quo beibehalten
• Orbit SSF
• Brute-Force SSF
• SSF mit Zwei-Schichten-Staking

(1) bedeutet, nichts zu tun und das Staking unverändert zu lassen, was jedoch die Sicherheitserfahrung und die Zentralisierungseigenschaften von Ethereum schlechter macht, als sie sein könnten.

(2) vermeidet „High-Tech“ und löst das Problem durch eine clevere Neubewertung der Protokollannahmen: Wir lockern die Anforderungen an die wirtschaftliche Finalität, sodass wir immer noch hohe Angriffskosten verlangen, aber akzeptieren, dass die Angriffskosten möglicherweise zehnmal niedriger sind als heute (z. B. 2.5 Milliarden Dollar statt 25 Milliarden Dollar). Es wird allgemein angenommen, dass Ethereums wirtschaftliche Finalität heute weit über dem erforderlichen Niveau liegt und die Hauptsicherheitsrisiken woanders liegen, sodass dies ein akzeptabler Kompromiss sein könnte.

Die Hauptaufgabe besteht darin, zu überprüfen, ob das Orbit-Mechanismus sicher ist und die gewünschten Eigenschaften hat, es dann vollständig zu formalisieren und zu implementieren. Außerdem ermöglicht EIP-7251 (Erhöhung des maximalen effektiven Saldos) die freiwillige Zusammenlegung von Validator-Salden, was den Chain-Validierungsaufwand sofort reduziert und als effektive Anfangsphase für die Einführung von Orbit dient.

(3) vermeidet clevere Neubewertungen und löst das Problem stattdessen mit High-Tech. Dazu müssen in sehr kurzer Zeit (5-10 Sekunden) eine große Anzahl von Signaturen (über 1 Million) gesammelt werden.

(4) vermeidet sowohl clevere Neubewertungen als auch High-Tech, schafft aber ein Zwei-Schichten-Staking-System, das immer noch Zentralisierungsrisiken birgt. Das Risiko hängt weitgehend von den spezifischen Rechten ab, die die niedrigere Staking-Schicht erhält. Zum Beispiel:

• Wenn Staker der unteren Schicht ihr Bestätigungsrecht an die obere Schicht delegieren müssen, könnte die Delegation zentralisiert werden, sodass wir am Ende zwei hochgradig zentralisierte Staking-Schichten hätten.
• Wenn für die untere Schicht eine Zufallsstichprobe zur Bestätigung jedes Blocks erforderlich ist, könnte ein Angreifer mit sehr wenig ETH die Finalität verhindern.
• Wenn Staker der unteren Schicht nur Inclusion-Listen erstellen können, könnte die Bestätigungsschicht weiterhin zentralisiert sein, sodass ein 51%-Angriff auf die Bestätigungsschicht die Inclusion-Listen selbst zensieren könnte.

Es können mehrere Strategien kombiniert werden, zum Beispiel:

• (1 + 2): Orbit hinzufügen, ohne Single-Slot-Finalität umzusetzen.
• (1 + 3): Brute-Force-Technik verwenden, um die minimale Einlagenhöhe zu reduzieren, ohne Single-Slot-Finalität umzusetzen. Die erforderliche Aggregationsmenge ist 64-mal geringer als im reinen (3)-Fall, sodass das Problem leichter wird.
• (2 + 3): Orbit SSF mit konservativen Parametern umsetzen (z. B. 128k Validator-Komitee statt 8k oder 32k) und Brute-Force-Technik verwenden, um es hocheffizient zu machen.
• (1 + 4): Rainbow Staking hinzufügen, ohne Single-Slot-Finalität umzusetzen.

Wie interagiert es mit anderen Teilen des Fahrplans?

Neben anderen Vorteilen verringert Single-Slot-Finalität auch das Risiko bestimmter Arten von Multi-Block-MEV-Angriffen. Außerdem müssen im Single-Slot-Finalitätsmodell das Prover-Proposer-Separation-Design und andere Protokoll-interne Blockproduktionspipelines anders gestaltet werden.

Die Schwäche der Brute-Force-Strategien besteht darin, dass sie es schwieriger machen, die Slot-Zeit zu verkürzen.

Single Secret Leader Election

Welches Problem wollen wir lösen?

Heute ist im Voraus bekannt, welcher Validator den nächsten Block vorschlagen wird. Das führt zu einer Sicherheitslücke: Ein Angreifer kann das Netzwerk überwachen, herausfinden, welche Validatoren zu welchen IP-Adressen gehören, und einen DoS-Angriff auf den Validator starten, kurz bevor dieser einen Block vorschlagen soll.

Was ist das? Wie funktioniert es?

Die beste Methode, das DoS-Problem zu lösen, besteht darin, zu verbergen, welcher Validator den nächsten Block generieren wird – zumindest bis der Block tatsächlich erzeugt wird. Beachten Sie: Wenn wir die „Single“-Anforderung entfernen, ist das einfach: Eine Lösung wäre, jedem zu erlauben, den nächsten Block zu erstellen, aber zu verlangen, dass randao kleiner als 2^256 / N ist. Im Durchschnitt kann nur ein Validator diese Bedingung erfüllen – manchmal aber auch zwei oder mehr, manchmal keiner. Die Kombination aus „Geheimhaltung“ und „Single“-Anforderung war schon immer eine Herausforderung.

Single Secret Leader Election-Protokolle lösen dieses Problem, indem sie mit kryptographischen Techniken für jeden Validator eine „blinde“ Validator-ID erstellen. Viele Proposer können dann die blinden IDs mischen und neu verschleiern (ähnlich wie Mixnets funktionieren). In jedem Slot wird eine zufällige blinde ID ausgewählt. Nur der Besitzer dieser blinden ID kann einen gültigen Nachweis zur Blockvorschlagserstellung liefern, aber niemand weiß, welcher Validator zu welcher blinden ID gehört.

Whisk SSLE-Protokoll

Welche Links zu bestehenden Forschungen gibt es?

• Dan Bonehs Paper (2020):
• Whisk (konkreter Ethereum-Vorschlag, 2022):
• Single Secret Leader Election Tag auf ethresear.ch:
• Vereinfachtes SSLE mit Ringsignaturen:

Was bleibt zu tun? Welche Abwägungen sind nötig?

Tatsächlich bleibt die Aufgabe, ein ausreichend einfaches Protokoll zu finden und zu implementieren, sodass wir es problemlos auf dem Mainnet einsetzen können. Wir legen großen Wert darauf, dass Ethereum ein relativ einfaches Protokoll bleibt, und wollen die Komplexität nicht weiter erhöhen. Die uns bekannten SSLE-Implementierungen fügen Hunderte Zeilen Spezifikationscode hinzu und führen neue Annahmen in komplexer Kryptographie ein. Eine ausreichend effiziente quantensichere SSLE-Implementierung zu finden, ist ebenfalls ein offenes Problem.

Es könnte letztlich darauf hinauslaufen, dass die „marginale Zusatzkomplexität“ von SSLE erst dann niedrig genug ist, wenn wir aus anderen Gründen (z. B. State Trees, ZK-EVM) allgemeine Zero-Knowledge-Proof-Mechanismen auf L1 des Ethereum-Protokolls einführen.

Eine andere Option wäre, SSLE ganz zu ignorieren und stattdessen das DoS-Problem mit Off-Protocol-Maßnahmen (z. B. auf der p2p-Schicht) zu lösen.

Wie interagiert es mit anderen Teilen des Fahrplans?

Wenn wir eine Prover-Proposer-Separation (APS) wie Execution Tickets einführen, benötigen Execution Blocks (d. h. Blöcke mit Ethereum-Transaktionen) kein SSLE, da wir uns auf spezialisierte Blockbuilder verlassen können. Für Konsensblöcke (d. h. Blöcke mit Protokollnachrichten wie Beweisen, Inclusion-Listen usw.) profitieren wir jedoch weiterhin von SSLE.

Schnellere Transaktionsbestätigung

Welches Problem lösen wir?

Eine weitere Reduzierung der Transaktionsbestätigungszeit von Ethereum, von 12 Sekunden auf 4 Sekunden, ist wertvoll. Dies würde das Nutzererlebnis auf L1 und für Rollup-basierte Anwendungen deutlich verbessern und defi-Protokolle effizienter machen. Außerdem würde es L2s die Dezentralisierung erleichtern, da viele L2-Anwendungen dann auf Rollups arbeiten könnten, wodurch der Bedarf entfällt, dass L2s eigene Komitee-basierte dezentrale Sequencer aufbauen müssen.

Was ist das? Wie funktioniert es?

Hier gibt es im Wesentlichen zwei technische Ansätze:

• Verkürzung der Slot-Zeit, z. B. auf 8 oder 4 Sekunden. Das bedeutet nicht unbedingt 4 Sekunden Finalität: Finalität erfordert im Wesentlichen drei Kommunikationsrunden, sodass wir jede Runde als separaten Block behandeln können und nach 4 Sekunden zumindest eine vorläufige Bestätigung erhalten.
• Erlauben, dass Proposer während des Slots Pre-Confirmations veröffentlichen. Im Extremfall kann der Proposer Transaktionen in Echtzeit in seinen Block aufnehmen und sofort für jede Transaktion eine Pre-Confirmation-Nachricht veröffentlichen („Meine erste Transaktion ist 0×1234...“, „Meine zweite Transaktion ist 0×5678...“). Wenn ein Proposer zwei widersprüchliche Bestätigungen veröffentlicht, kann dies entweder (i) durch Slashing des Proposers oder (ii) durch Abstimmung der Prover, welche Bestätigung früher war, behandelt werden.

Welche Links zu bestehenden Forschungen gibt es?

• Pre-Confirmation-basiert:
• Protocol-Enforced Proposer Commitments (PEPC):
• Interleaved Epochs on Parallel Chains (2018, Idee für niedrige Latenz):

Was bleibt zu tun und welche Abwägungen gibt es?

Es ist derzeit unklar, wie praktikabel die Verkürzung der Slot-Zeit ist. Selbst heute haben viele Validatoren weltweit Schwierigkeiten, Beweise schnell genug zu erhalten. Ein Versuch, die Slot-Zeit auf 4 Sekunden zu reduzieren, birgt das Risiko einer Konzentration des Validator-Sets und macht es außerhalb weniger privilegierter Regionen aufgrund der Latenz unrealistisch, Validator zu werden.

Die Schwäche des Pre-Confirmation-Ansatzes ist, dass er die durchschnittliche Inklusionszeit erheblich verbessert, aber nicht die schlechteste Fallzeit: Wenn der aktuelle Proposer gut läuft, wird Ihre Transaktion in 0,5 Sekunden pre-confirmed statt (im Schnitt) in 6 Sekunden aufgenommen, aber wenn der aktuelle Proposer offline oder langsam ist, müssen Sie trotzdem volle 12 Sekunden warten, bis der nächste Slot beginnt und ein neuer Proposer gewählt wird.

Außerdem ist noch offen, wie Pre-Confirmations incentiviert werden sollen. Proposer haben einen Anreiz, ihre Optionalität so lange wie möglich zu maximieren. Wenn Prover die Rechtzeitigkeit von Pre-Confirmations signieren, könnten Transaktionssender einen Teil der Gebühr als Bedingung für sofortige Pre-Confirmation anbieten, aber das belastet die Prover zusätzlich und könnte es ihnen erschweren, weiterhin als neutrale „dumme Pipeline“ zu agieren.

Andererseits, wenn wir dies nicht versuchen und die Finalisierungszeit bei 12 Sekunden (oder länger) belassen, wird das Ökosystem Pre-Confirmation-Mechanismen auf Layer 2 stärker gewichten, und Interaktionen zwischen Layer 2s werden länger dauern.

Wie interagiert es mit anderen Teilen des Fahrplans?

Pre-Confirmation durch Proposer hängt tatsächlich von einer Prover-Proposer-Separation (APS) wie Execution Tickets ab. Andernfalls könnte der Druck, Echtzeit-Pre-Confirmations zu liefern, zu einer zu starken Zentralisierung der regulären Validatoren führen.

Weitere Forschungsbereiche

51%-Angriffs-Wiederherstellung

Es wird allgemein angenommen, dass im Falle eines 51%-Angriffs (einschließlich solcher ohne kryptographischen Beweis, wie Zensur) die Community zusammenarbeitet, um eine Minderheits-Softfork durchzuführen, damit die Guten gewinnen und die Bösen durch Inactivity-Leak oder Slashing bestraft werden. Dieses starke Vertrauen in die soziale Ebene kann jedoch als ungesund angesehen werden. Wir können versuchen, die Abhängigkeit von der sozialen Ebene zu verringern und den Wiederherstellungsprozess so weit wie möglich zu automatisieren.

Vollständige Automatisierung ist nicht möglich, denn wenn doch, wäre dies ein Konsensalgorithmus mit >50% Fehlertoleranz, und wir kennen bereits die (sehr strengen) mathematischen Beweisgrenzen solcher Algorithmen. Aber wir können eine teilweise Automatisierung erreichen: Wenn z. B. ein Client Transaktionen, die er lange genug gesehen hat, zensiert, kann der Client automatisch ablehnen, eine Chain als finalisiert zu akzeptieren oder sie sogar als Fork-Choice-Head zu akzeptieren. Ein zentrales Ziel ist es, sicherzustellen, dass die Angreifer im Angriff zumindest nicht schnell gewinnen können.

Erhöhung des Quorum-Schwellenwerts

Heute wird ein Block finalisiert, wenn 67 % der Staker zustimmen. Einige halten das für zu aggressiv. In der gesamten Geschichte von Ethereum gab es nur einmal (sehr kurz) einen Finalitätsausfall. Wenn dieser Prozentsatz auf 80 % erhöht würde, wäre die Anzahl der Nicht-Finalitätsperioden relativ gering, aber Ethereum würde an Sicherheit gewinnen: Besonders viele umstrittenere Fälle würden zu einer vorübergehenden Finalitätsunterbrechung führen. Das scheint gesünder zu sein, als wenn die „falsche Seite“ sofort gewinnt, egal ob das Angreifer sind oder Clients einen Fehler haben.

Das beantwortet auch die Frage „Was bringt Einzelstaker?“. Heute staken die meisten bereits über Pools, und es scheint unwahrscheinlich, dass Einzelstaker jemals 51 % der gestakten ETH erreichen. Aber wenn wir uns bemühen, könnten Einzelstaker die Minderheit erreichen, die die Mehrheit blockieren kann, besonders wenn die Mehrheit 80 % erreicht (d. h. die Minderheit, die die Mehrheit blockiert, braucht nur 21 %). Solange Einzelstaker nicht an 51%-Angriffen teilnehmen (egal ob Finalitätsumkehr oder Zensur), wird ein solcher Angriff keinen „sauberen Sieg“ erzielen, und Einzelstaker helfen aktiv bei der Organisation von Minderheits-Softforks.

Quantensicherheit

Metaculus geht derzeit davon aus, dass Quantencomputer, trotz großer Unsicherheiten, wahrscheinlich irgendwann in den 2030er Jahren beginnen werden, Kryptographie zu brechen:

Quantencomputing-Experten wie Scott Aaronson beginnen ebenfalls, die Möglichkeit, dass Quantencomputer mittelfristig tatsächlich funktionieren, ernster zu nehmen. Das hat Auswirkungen auf den gesamten Ethereum-Fahrplan: Es bedeutet, dass jeder Teil des Ethereum-Protokolls, der derzeit auf elliptischen Kurven basiert, eine Alternative auf Hash- oder anderer quantensicherer Basis benötigt. Das bedeutet insbesondere, dass wir nicht davon ausgehen können, dass wir für immer auf die hervorragenden Eigenschaften von BLS-Aggregation zur Verarbeitung von Signaturen großer Validatorensets setzen können. Das rechtfertigt eine konservative Haltung bei den Leistungsannahmen im Proof-of-Stake-Design und ist ein Grund, aktivere quantensichere Alternativen zu entwickeln.