Ethereum Proof-of-Stake: Angriff und Verteidigung

Diebe und Saboteure suchen ständig nach Möglichkeiten, die Client-Software von Ethereum anzugreifen. Diese Seite beschreibt die bekannten Angriffsvektoren auf die Konsensschicht von Ethereum und skizziert, wie diese Angriffe abgewehrt werden können. Die Informationen auf dieser Seite basieren auf einer ausführlicheren Version (opens in a new tab).

Voraussetzungen

Einige Grundkenntnisse über Proof-of-Stake (PoS) sind erforderlich. Außerdem ist es hilfreich, ein grundlegendes Verständnis der Anreizschicht von Ethereum und des Fork-Choice-Algorithmus LMD-GHOST zu haben.

Was wollen Angreifer?

Ein weit verbreiteter Irrglaube ist, dass ein erfolgreicher Angreifer neue Ether generieren oder Ether von beliebigen Konten abziehen kann. Beides ist nicht möglich, da alle Transaktionen von allen Ausführungs-Clients im Netzwerk ausgeführt werden. Sie müssen grundlegende Gültigkeitsbedingungen erfüllen (z. B. müssen Transaktionen mit dem privaten Schlüssel des Senders signiert sein, der Sender muss über ein ausreichendes Guthaben verfügen usw.), andernfalls werden sie einfach rückgängig gemacht. Es gibt drei Arten von Ergebnissen, auf die ein Angreifer realistischerweise abzielen könnte: Reorgs, doppelte Endgültigkeit oder Verzögerung der Endgültigkeit.

Ein „Reorg“ ist eine Neuordnung von Blöcken in eine neue Reihenfolge, möglicherweise mit dem Hinzufügen oder Entfernen von Blöcken in der kanonischen Chain. Ein böswilliger Reorg könnte sicherstellen, dass bestimmte Blöcke ein- oder ausgeschlossen werden, was Doppelausgaben oder Wertabschöpfung durch Front-Running- und Back-Running-Transaktionen (MEV) ermöglicht. Reorgs könnten auch verwendet werden, um zu verhindern, dass bestimmte Transaktionen in die kanonische Chain aufgenommen werden – eine Form der Zensur. Die extremste Form eines Reorgs ist die „Umkehrung der Endgültigkeit“, bei der Blöcke entfernt oder ersetzt werden, die zuvor endgültig gemacht wurden. Dies ist nur möglich, wenn mehr als ⅓ der gesamten gestakten Ether vom Angreifer zerstört werden – diese Garantie ist als „wirtschaftliche Endgültigkeit“ bekannt – dazu später mehr.

Doppelte Endgültigkeit ist der unwahrscheinliche, aber schwerwiegende Zustand, in dem zwei Forks gleichzeitig endgültig werden können, was zu einer dauerhaften Spaltung der Chain führt. Dies ist theoretisch für einen Angreifer möglich, der bereit ist, 34 % der gesamten gestakten Ether zu riskieren. Die Community wäre gezwungen, sich offchain zu koordinieren und sich darauf zu einigen, welcher Chain sie folgen soll, was Stärke in der sozialen Schicht erfordern würde.

Ein Angriff zur Verzögerung der Endgültigkeit verhindert, dass das Netzwerk die notwendigen Bedingungen erreicht, um Abschnitte der Chain endgültig zu machen. Ohne Endgültigkeit ist es schwer, Finanzanwendungen zu vertrauen, die auf Ethereum aufbauen. Das Ziel eines Angriffs zur Verzögerung der Endgültigkeit ist wahrscheinlich einfach, Ethereum zu stören, anstatt direkt davon zu profitieren, es sei denn, der Angreifer hat strategische Short-Positionen.

Ein Angriff auf die soziale Schicht könnte darauf abzielen, das öffentliche Vertrauen in Ethereum zu untergraben, Ether abzuwerten, die Akzeptanz zu verringern oder die Ethereum-Community zu schwächen, um eine Out-of-Band-Koordination zu erschweren.

Nachdem wir festgestellt haben, warum ein Gegner Ethereum angreifen könnte, untersuchen die folgenden Abschnitte, wie er dabei vorgehen könnte.

Angriffsmethoden

Layer-0-Angriffe

Zunächst einmal können Personen, die nicht aktiv an Ethereum teilnehmen (indem sie Client-Software ausführen), angreifen, indem sie auf die soziale Schicht (Layer 0) abzielen. Layer 0 ist das Fundament, auf dem Ethereum aufbaut, und stellt als solches eine potenzielle Angriffsfläche mit Konsequenzen dar, die sich durch den Rest des Stacks ziehen. Einige Beispiele könnten sein:

• Eine Desinformationskampagne könnte das Vertrauen der Community in die Roadmap von Ethereum, Entwicklerteams, Apps usw. untergraben. Dies könnte dann die Anzahl der Personen verringern, die bereit sind, sich an der Sicherung des Netzwerks zu beteiligen, was sowohl die Dezentralisierung als auch die kryptoökonomische Sicherheit beeinträchtigt.

• Gezielte Angriffe und/oder Einschüchterungen gegen die Entwickler-Community. Dies könnte zum freiwilligen Austritt von Entwicklern führen und den Fortschritt von Ethereum verlangsamen.

• Übereifrige Regulierung könnte ebenfalls als Angriff auf Layer 0 betrachtet werden, da sie die Teilnahme und Akzeptanz schnell demotivieren könnte.

• Infiltration sachkundiger, aber böswilliger Akteure in die Entwickler-Community, deren Ziel es ist, den Fortschritt durch endlose Diskussionen über Nebensächlichkeiten (Bike-Shedding), Verzögerung wichtiger Entscheidungen, Erstellung von Spam usw. zu verlangsamen.

• Bestechungsgelder an wichtige Akteure im Ethereum-Ökosystem, um die Entscheidungsfindung zu beeinflussen.

Was diese Angriffe besonders gefährlich macht, ist, dass in vielen Fällen nur sehr wenig Kapital oder technisches Know-how erforderlich ist. Ein Layer-0-Angriff könnte ein Multiplikator für einen kryptoökonomischen Angriff sein. Wenn beispielsweise Zensur oder die Umkehrung der Endgültigkeit durch einen böswilligen Mehrheits-Stakeholder erreicht würde, könnte die Untergrabung der sozialen Schicht es schwieriger machen, eine Reaktion der Community Out-of-Band zu koordinieren.

Die Abwehr von Layer-0-Angriffen ist wahrscheinlich nicht einfach, aber es lassen sich einige Grundprinzipien aufstellen. Eines davon ist die Aufrechterhaltung eines insgesamt hohen Signal-Rausch-Verhältnisses für öffentliche Informationen über Ethereum, die von ehrlichen Mitgliedern der Community über Blogs, Discord-Server, kommentierte Spezifikationen, Bücher, Podcasts und YouTube erstellt und verbreitet werden. Hier bei ethereum.org bemühen wir uns sehr, genaue Informationen bereitzustellen und sie in so viele Sprachen wie möglich zu übersetzen. Einen Raum mit hochwertigen Informationen und Memes zu überfluten, ist eine wirksame Verteidigung gegen Fehlinformationen.

Eine weitere wichtige Befestigung gegen Angriffe auf die soziale Schicht ist ein klares Leitbild und Governance-Protokoll. Ethereum hat sich als Champion für Dezentralisierung und Sicherheit unter den Smart-Contract-Layer-1-Netzwerken positioniert und legt gleichzeitig großen Wert auf Skalierbarkeit und Nachhaltigkeit. Welche Meinungsverschiedenheiten auch immer in der Ethereum-Community auftreten, diese Kernprinzipien werden nur minimal beeinträchtigt. Die Bewertung eines Narrativs anhand dieser Kernprinzipien und deren Prüfung durch aufeinanderfolgende Überprüfungsrunden im EIP-Prozess (Ethereum Improvement Proposal) könnte der Community helfen, gute von schlechten Akteuren zu unterscheiden, und schränkt den Spielraum für böswillige Akteure ein, die zukünftige Ausrichtung von Ethereum zu beeinflussen.

Schließlich ist es von entscheidender Bedeutung, dass die Ethereum-Community offen und einladend für alle Teilnehmer bleibt. Eine Community mit Gatekeepern und Exklusivität ist besonders anfällig für soziale Angriffe, da es einfach ist, „Wir gegen die“-Narrative aufzubauen. Tribalismus und toxischer Maximalismus schaden der Community und untergraben die Sicherheit von Layer 0. Ethereans mit einem berechtigten Interesse an der Sicherheit des Netzwerks sollten ihr Verhalten online und im echten Leben (Meatspace) als direkten Beitrag zur Sicherheit von Ethereums Layer 0 betrachten.

Angriffe auf das Protokoll

Jeder kann die Client-Software von Ethereum ausführen. Um einem Client einen Validator hinzuzufügen, muss ein Benutzer 32 Ether in den Einzahlungsvertrag staken. Ein Validator ermöglicht es einem Benutzer, sich aktiv an der Netzwerksicherheit von Ethereum zu beteiligen, indem er neue Blöcke vorschlägt und attestiert. Der Validator hat nun eine Stimme, mit der er die zukünftigen Inhalte der Blockchain beeinflussen kann – er kann dies ehrlich tun und seinen Ether-Bestand durch Belohnungen vergrößern, oder er kann versuchen, den Prozess zu seinem eigenen Vorteil zu manipulieren und dabei seinen Stake zu riskieren. Eine Möglichkeit, einen Angriff durchzuführen, besteht darin, einen größeren Anteil des gesamten Stakes anzuhäufen und ihn dann zu nutzen, um ehrliche Validatoren zu überstimmen. Je größer der vom Angreifer kontrollierte Anteil des Stakes ist, desto größer ist seine Stimmacht, insbesondere bei bestimmten wirtschaftlichen Meilensteinen, die wir später untersuchen werden. Die meisten Angreifer werden jedoch nicht in der Lage sein, genügend Ether anzuhäufen, um auf diese Weise anzugreifen, sodass sie stattdessen subtile Techniken anwenden müssen, um die ehrliche Mehrheit dazu zu manipulieren, auf eine bestimmte Weise zu handeln.

Grundsätzlich sind alle Angriffe mit kleinem Stake subtile Variationen von zwei Arten von Fehlverhalten von Validatoren: Unteraktivität (Versäumnis zu attestieren/vorzuschlagen oder dies zu spät zu tun) oder Überaktivität (zu häufiges Vorschlagen/Attestieren in einem Slot). In ihren einfachsten Formen werden diese Aktionen leicht vom Fork-Choice-Algorithmus und der Anreizschicht gehandhabt, aber es gibt clevere Möglichkeiten, das System zum Vorteil eines Angreifers auszunutzen.

Angriffe mit kleinen Mengen an ETH

Reorgs

Mehrere Papiere haben Angriffe auf Ethereum erklärt, die Reorgs oder eine Verzögerung der Endgültigkeit mit nur einem kleinen Anteil der gesamten gestakten Ether erreichen. Diese Angriffe beruhen im Allgemeinen darauf, dass der Angreifer einige Informationen vor anderen Validatoren zurückhält und sie dann auf nuancierte Weise und/oder in einem günstigen Moment freigibt. Sie zielen in der Regel darauf ab, einige ehrliche Blöcke aus der kanonischen Chain zu verdrängen. Neuder et al. 2020 (opens in a new tab) zeigten, wie ein angreifender Validator einen Block (B) für einen bestimmten Slot n+1 erstellen und attestieren kann, aber davon absieht, ihn an andere Knoten im Netzwerk weiterzuleiten. Stattdessen behalten sie diesen attestierten Block bis zum nächsten Slot n+2. Ein ehrlicher Validator schlägt einen Block (C) für Slot n+2 vor. Fast gleichzeitig kann der Angreifer seinen zurückgehaltenen Block (B) und seine zurückgehaltenen Attestierungen dafür freigeben und mit seinen Stimmen für Slot n+2 auch attestieren, dass B die Spitze der Chain ist, wodurch die Existenz des ehrlichen Blocks C effektiv geleugnet wird. Wenn der ehrliche Block D freigegeben wird, sieht der Fork-Choice-Algorithmus, dass D, der auf B aufbaut, schwerer ist als D, der auf C aufbaut. Dem Angreifer ist es somit gelungen, den ehrlichen Block C in Slot n+2 mithilfe eines 1-Block-Ex-ante-Reorgs aus der kanonischen Chain zu entfernen. Ein Angreifer mit 34 % (opens in a new tab) des Stakes hat sehr gute Chancen, bei diesem Angriff erfolgreich zu sein, wie in dieser Notiz (opens in a new tab) erklärt wird. Theoretisch könnte dieser Angriff jedoch auch mit kleineren Stakes versucht werden. Neuder et al. 2020 (opens in a new tab) beschrieben, dass dieser Angriff mit einem Stake von 30 % funktioniert, aber später wurde gezeigt, dass er mit 2 % des gesamten Stakes (opens in a new tab) und dann noch einmal für einen einzelnen Validator (opens in a new tab) unter Verwendung von Balancing-Techniken, die wir im nächsten Abschnitt untersuchen werden, durchführbar ist.

Ein konzeptionelles Diagramm des oben beschriebenen Ein-Block-Reorg-Angriffs (angepasst von https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair (opens in a new tab))

Ein raffinierterer Angriff kann die Menge der ehrlichen Validatoren in diskrete Gruppen aufteilen, die unterschiedliche Ansichten über die Spitze der Chain haben. Dies ist als Balancing-Angriff bekannt. Der Angreifer wartet auf seine Chance, einen Block vorzuschlagen, und wenn sie kommt, begeht er eine Äquivokation und schlägt zwei vor. Er sendet einen Block an die Hälfte der ehrlichen Validatoren und den anderen Block an die andere Hälfte. Die Äquivokation würde vom Fork-Choice-Algorithmus erkannt und der Block-Proposer würde geslasht und aus dem Netzwerk geworfen werden, aber die beiden Blöcke würden weiterhin existieren und etwa die Hälfte der Validatoren würde für jeden Fork attestieren. Währenddessen halten die verbleibenden böswilligen Validatoren ihre Attestierungen zurück. Indem sie dann selektiv die Attestierungen, die den einen oder anderen Fork begünstigen, an gerade genug Validatoren freigeben, genau wenn der Fork-Choice-Algorithmus ausgeführt wird, kippen sie das angesammelte Gewicht der Attestierungen zugunsten des einen oder anderen Forks. Dies kann auf unbestimmte Zeit fortgesetzt werden, wobei die angreifenden Validatoren eine gleichmäßige Aufteilung der Validatoren auf die beiden Forks aufrechterhalten. Da keiner der Forks eine 2/3-Supermehrheit auf sich ziehen kann, würde das Netzwerk nicht endgültig werden.

Bouncing-Angriffe sind ähnlich. Stimmen werden wiederum von den angreifenden Validatoren zurückgehalten. Anstatt die Stimmen freizugeben, um eine gleichmäßige Aufteilung zwischen zwei Forks aufrechtzuerhalten, nutzen sie ihre Stimmen in günstigen Momenten, um Checkpoints zu rechtfertigen, die zwischen Fork A und Fork B wechseln. Dieses Hin und Her der Rechtfertigung zwischen zwei Forks verhindert, dass es Paare von gerechtfertigten Quell- und Ziel-Checkpoints gibt, die auf einer der beiden Chains endgültig gemacht werden können, wodurch die Endgültigkeit gestoppt wird.

Sowohl Bouncing- als auch Balancing-Angriffe beruhen darauf, dass der Angreifer eine sehr genaue Kontrolle über das Timing von Nachrichten im gesamten Netzwerk hat, was unwahrscheinlich ist. Dennoch sind im Protokoll Verteidigungen in Form einer zusätzlichen Gewichtung eingebaut, die schnellen Nachrichten im Vergleich zu langsamen gegeben wird. Dies ist als Proposer-Weight-Boosting (opens in a new tab) bekannt. Zur Abwehr von Bouncing-Angriffen wurde der Fork-Choice-Algorithmus so aktualisiert, dass der letzte gerechtfertigte Checkpoint nur während des ersten Drittels der Slots in jeder Epoche (opens in a new tab) zu dem einer alternativen Chain wechseln kann. Diese Bedingung verhindert, dass der Angreifer Stimmen aufspart, um sie später einzusetzen – der Fork-Choice-Algorithmus bleibt einfach dem Checkpoint treu, den er im ersten Drittel der Epoche gewählt hat, in der die meisten ehrlichen Validatoren abgestimmt hätten.

Zusammengenommen schaffen diese Maßnahmen ein Szenario, in dem ein ehrlicher Block-Proposer seinen Block sehr schnell nach Beginn des Slots ausgibt, dann gibt es eine Periode von ~1/3 eines Slots (4 Sekunden), in der dieser neue Block den Fork-Choice-Algorithmus dazu veranlassen könnte, zu einer anderen Chain zu wechseln. Nach derselben Frist werden Attestierungen, die von langsamen Validatoren eintreffen, im Vergleich zu denen, die früher eingetroffen sind, abgewertet. Dies begünstigt schnelle Proposer und Validatoren bei der Bestimmung der Spitze der Chain stark und verringert die Wahrscheinlichkeit eines erfolgreichen Balancing- oder Bouncing-Angriffs erheblich.

Es ist erwähnenswert, dass Proposer-Boosting allein nur gegen „billige Reorgs“ verteidigt, d. h. solche, die von einem Angreifer mit einem kleinen Stake versucht werden. Tatsächlich kann das Proposer-Boosting selbst von größeren Stakeholdern ausgenutzt werden. Die Autoren dieses Beitrags (opens in a new tab) beschreiben, wie ein Angreifer mit 7 % des Stakes seine Stimmen strategisch einsetzen kann, um ehrliche Validatoren dazu zu bringen, auf seinem Fork aufzubauen und einen ehrlichen Block durch einen Reorg zu entfernen. Dieser Angriff wurde unter der Annahme idealer Latenzbedingungen entwickelt, die sehr unwahrscheinlich sind. Die Chancen stehen für den Angreifer immer noch sehr schlecht, und der größere Stake bedeutet auch mehr gefährdetes Kapital und eine stärkere wirtschaftliche Abschreckung.

Ein Balancing-Angriff, der speziell auf die LMD-Regel abzielt (opens in a new tab), wurde ebenfalls vorgeschlagen, der trotz Proposer-Boosting als durchführbar angesehen wurde. Ein Angreifer richtet zwei konkurrierende Chains ein, indem er bei seinem Blockvorschlag eine Äquivokation begeht und jeden Block an jeweils etwa die Hälfte des Netzwerks weiterleitet, wodurch ein ungefähres Gleichgewicht zwischen den Forks hergestellt wird. Dann begehen die kolludierenden Validatoren eine Äquivokation bei ihren Stimmen und timen dies so, dass die Hälfte des Netzwerks ihre Stimmen für Fork A zuerst erhält und die andere Hälfte ihre Stimmen für Fork B zuerst erhält. Da die LMD-Regel die zweite Attestierung verwirft und nur die erste für jeden Validator behält, sieht die Hälfte des Netzwerks Stimmen für A und keine für B, die andere Hälfte sieht Stimmen für B und keine für A. Die Autoren beschreiben, dass die LMD-Regel dem Gegner „bemerkenswerte Macht“ verleiht, um einen Balancing-Angriff durchzuführen.

Dieser LMD-Angriffsvektor wurde geschlossen, indem der Fork-Choice-Algorithmus aktualisiert (opens in a new tab) wurde, sodass er Validatoren, die eine Äquivokation begehen, vollständig aus der Fork-Choice-Betrachtung ausschließt. Der zukünftige Einfluss von Validatoren, die eine Äquivokation begehen, wird ebenfalls vom Fork-Choice-Algorithmus abgewertet. Dies verhindert den oben beschriebenen Balancing-Angriff und erhält gleichzeitig die Widerstandsfähigkeit gegen Avalanche-Angriffe aufrecht.

Eine weitere Klasse von Angriffen, sogenannte Avalanche-Angriffe (opens in a new tab), wurde in einem Papier vom März 2022 (opens in a new tab) beschrieben. Um einen Avalanche-Angriff durchzuführen, muss der Angreifer mehrere aufeinanderfolgende Block-Proposer kontrollieren. In jedem der Blockvorschlags-Slots hält der Angreifer seinen Block zurück und sammelt sie, bis die ehrliche Chain ein gleiches Teilbaumgewicht wie die zurückgehaltenen Blöcke erreicht. Dann werden die zurückgehaltenen Blöcke freigegeben, sodass sie maximal äquivokieren. Die Autoren deuten an, dass Proposer-Boosting – die primäre Verteidigung gegen Balancing- und Bouncing-Angriffe – nicht vor einigen Varianten von Avalanche-Angriffen schützt. Die Autoren demonstrierten den Angriff jedoch auch nur an einer stark idealisierten Version des Fork-Choice-Algorithmus von Ethereum (sie verwendeten GHOST ohne LMD).

Der Avalanche-Angriff wird durch den LMD-Teil des LMD-GHOST-Fork-Choice-Algorithmus abgeschwächt. LMD bedeutet „latest-message-driven“ (gesteuert durch die neueste Nachricht) und bezieht sich auf eine Tabelle, die von jedem Validator geführt wird und die neueste von anderen Validatoren empfangene Nachricht enthält. Dieses Feld wird nur aktualisiert, wenn die neue Nachricht aus einem späteren Slot stammt als diejenige, die sich bereits für einen bestimmten Validator in der Tabelle befindet. In der Praxis bedeutet dies, dass in jedem Slot die erste empfangene Nachricht diejenige ist, die akzeptiert wird, und alle zusätzlichen Nachrichten Äquivokationen sind, die ignoriert werden. Anders ausgedrückt: Die Konsens-Clients zählen keine Äquivokationen – sie verwenden die zuerst eintreffende Nachricht von jedem Validator und Äquivokationen werden einfach verworfen, was Avalanche-Angriffe verhindert.

Es gibt mehrere andere potenzielle zukünftige Upgrades für die Fork-Choice-Regel, die die durch Proposer-Boost gebotene Sicherheit erhöhen könnten. Eines davon ist View-Merge (opens in a new tab), bei dem Attestierer ihre Sicht auf die Fork-Choice n Sekunden vor Beginn eines Slots einfrieren und der Proposer dann hilft, die Sicht auf die Chain im gesamten Netzwerk zu synchronisieren. Ein weiteres potenzielles Upgrade ist die Single-Slot-Endgültigkeit (opens in a new tab), die vor Angriffen schützt, die auf dem Timing von Nachrichten basieren, indem die Chain nach nur einem Slot endgültig gemacht wird.

Verzögerung der Endgültigkeit

Dasselbe Papier (opens in a new tab), das zuerst den kostengünstigen Ein-Block-Reorg-Angriff beschrieb, beschrieb auch einen Angriff zur Verzögerung der Endgültigkeit (auch bekannt als „Liveness Failure“), der darauf beruht, dass der Angreifer der Block-Proposer für einen Epochengrenzen-Block ist. Dies ist kritisch, da diese Epochengrenzen-Blöcke zu den Checkpoints werden, die Casper FFG verwendet, um Teile der Chain endgültig zu machen. Der Angreifer hält seinen Block einfach zurück, bis genügend ehrliche Validatoren ihre FFG-Stimmen zugunsten des vorherigen Epochengrenzen-Blocks als aktuelles Finalisierungsziel verwenden. Dann geben sie ihren zurückgehaltenen Block frei. Sie attestieren ihren Block und die verbleibenden ehrlichen Validatoren tun dies ebenfalls, wodurch Forks mit unterschiedlichen Ziel-Checkpoints entstehen. Wenn sie das Timing genau richtig gewählt haben, verhindern sie die Endgültigkeit, da es für keinen der beiden Forks eine 2/3-Supermehrheit geben wird, die attestiert. Je kleiner der Stake, desto präziser muss das Timing sein, da der Angreifer weniger Attestierungen direkt kontrolliert und die Wahrscheinlichkeit geringer ist, dass der Angreifer den Validator kontrolliert, der einen bestimmten Epochengrenzen-Block vorschlägt.

Long-Range-Angriffe

Es gibt auch eine Klasse von Angriffen, die spezifisch für Proof-of-Stake-Blockchains ist und bei der ein Validator, der am Genesis-Block teilgenommen hat, einen separaten Fork der Blockchain neben dem ehrlichen aufrechterhält und schließlich die ehrlichen Validatoren davon überzeugt, zu einem viel späteren, günstigen Zeitpunkt zu diesem zu wechseln. Diese Art von Angriff ist auf Ethereum nicht möglich, da das Finalitäts-Gadget sicherstellt, dass sich alle Validatoren in regelmäßigen Abständen („Checkpoints“) auf den Zustand der ehrlichen Chain einigen. Dieser einfache Mechanismus neutralisiert Long-Range-Angreifer, da Ethereum-Clients endgültige Blöcke einfach nicht reorgen. Neue Knoten, die dem Netzwerk beitreten, tun dies, indem sie einen vertrauenswürdigen aktuellen Zustands-Hash (einen Checkpoint für „schwache Subjektivität (opens in a new tab)“) finden und ihn als Pseudo-Genesis-Block verwenden, auf dem sie aufbauen. Dies schafft ein „Vertrauens-Gateway“ für einen neuen Knoten, der in das Netzwerk eintritt, bevor er beginnen kann, Informationen selbst zu verifizieren.

Denial of Service

Der PoS-Mechanismus von Ethereum wählt in jedem Slot einen einzelnen Validator aus der gesamten Validatorenmenge als Block-Proposer aus. Dies kann mithilfe einer öffentlich bekannten Funktion berechnet werden, und es ist für einen Gegner möglich, den nächsten Block-Proposer kurz vor seinem Blockvorschlag zu identifizieren. Dann kann der Angreifer den Block-Proposer spammen, um zu verhindern, dass er Informationen mit seinen Peers austauscht. Für den Rest des Netzwerks würde es so aussehen, als wäre der Block-Proposer offline und der Slot würde einfach leer bleiben. Dies könnte eine Form der Zensur gegen bestimmte Validatoren sein, die sie daran hindert, der Blockchain Informationen hinzuzufügen. Die Implementierung von Single Secret Leader Elections (SSLE) oder Non-Single Secret Leader Elections wird DoS-Risiken mindern, da nur der Block-Proposer jemals weiß, dass er ausgewählt wurde, und die Auswahl nicht im Voraus bekannt ist. Dies ist noch nicht implementiert, aber ein aktiver Bereich der Forschung und Entwicklung (opens in a new tab).

All dies deutet darauf hin, dass es sehr schwierig ist, Ethereum mit einem kleinen Stake erfolgreich anzugreifen. Die hier beschriebenen durchführbaren Angriffe erfordern einen idealisierten Fork-Choice-Algorithmus, unwahrscheinliche Netzwerkbedingungen, oder die Angriffsvektoren wurden bereits mit relativ kleinen Patches an der Client-Software geschlossen. Dies schließt natürlich nicht die Möglichkeit aus, dass Zero-Days in der Praxis existieren, aber es zeigt die extrem hohe Hürde an technischer Eignung, Wissen über die Konsensschicht und Glück, die erforderlich ist, damit ein Angreifer mit Minderheits-Stake effektiv sein kann. Aus der Perspektive eines Angreifers könnte es die beste Option sein, so viel Ether wie möglich anzuhäufen und mit einem größeren Anteil des gesamten Stakes bewaffnet zurückzukehren.

Angreifer mit >= 33 % des gesamten Stakes

Alle zuvor in diesem Artikel erwähnten Angriffe werden wahrscheinlicher erfolgreich sein, wenn der Angreifer mehr gestakte Ether hat, mit denen er abstimmen kann, und mehr Validatoren, die ausgewählt werden könnten, um in jedem Slot Blöcke vorzuschlagen. Ein böswilliger Validator könnte daher darauf abzielen, so viele gestakte Ether wie möglich zu kontrollieren.

33 % der gestakten Ether sind ein Richtwert für einen Angreifer, da er mit allem, was über diesen Betrag hinausgeht, die Möglichkeit hat, zu verhindern, dass die Chain endgültig wird, ohne die Aktionen der anderen Validatoren genau kontrollieren zu müssen. Sie können einfach alle zusammen verschwinden. Wenn 1/3 oder mehr der gestakten Ether böswillig attestieren oder nicht attestieren, kann keine 2/3-Supermehrheit existieren und die Chain kann nicht endgültig werden. Die Verteidigung dagegen ist das Inaktivitätsleck. Das Inaktivitätsleck identifiziert diejenigen Validatoren, die nicht attestieren oder entgegen der Mehrheit attestieren. Die gestakten Ether im Besitz dieser nicht attestierenden Validatoren werden allmählich abgebaut, bis sie schließlich zusammen weniger als 1/3 der Gesamtsumme ausmachen, sodass die Chain wieder endgültig werden kann.

Der Zweck des Inaktivitätslecks besteht darin, die Chain wieder endgültig zu machen. Der Angreifer verliert jedoch auch einen Teil seiner gestakten Ether. Anhaltende Inaktivität bei Validatoren, die 33 % der gesamten gestakten Ether repräsentieren, ist sehr teuer, auch wenn die Validatoren nicht geslasht werden.

Unter der Annahme, dass das Ethereum-Netzwerk asynchron ist (d. h. es gibt Verzögerungen zwischen dem Senden und Empfangen von Nachrichten), könnte ein Angreifer, der 34 % des gesamten Stakes kontrolliert, eine doppelte Endgültigkeit verursachen. Dies liegt daran, dass der Angreifer eine Äquivokation begehen kann, wenn er als Blockproduzent ausgewählt wird, und dann mit all seinen Validatoren doppelt abstimmen kann. Dies schafft eine Situation, in der ein Fork der Blockchain existiert, für den jeweils 34 % der gestakten Ether abstimmen. Jeder Fork benötigt nur 50 % der verbleibenden Validatoren, die zu seinen Gunsten abstimmen, damit beide Forks von einer Supermehrheit unterstützt werden. In diesem Fall können beide Chains endgültig werden (da 34 % der Validatoren des Angreifers + die Hälfte der verbleibenden 66 % = 67 % auf jedem Fork). Die konkurrierenden Blöcke müssten jeweils von etwa 50 % der ehrlichen Validatoren empfangen werden, sodass dieser Angriff nur durchführbar ist, wenn der Angreifer ein gewisses Maß an Kontrolle über das Timing der sich über das Netzwerk ausbreitenden Nachrichten hat, sodass er die Hälfte der ehrlichen Validatoren auf jede Chain lenken kann. Der Angreifer würde zwangsläufig seinen gesamten Stake (34 % von ~10 Millionen Ether mit dem heutigen Validatoren-Set) zerstören, um diese doppelte Endgültigkeit zu erreichen, da 34 % seiner Validatoren gleichzeitig doppelt abstimmen würden – ein Vergehen, das mit der maximalen Korrelationsstrafe geslasht wird. Die Verteidigung gegen diesen Angriff sind die sehr hohen Kosten für die Zerstörung von 34 % der gesamten gestakten Ether. Die Erholung von diesem Angriff würde erfordern, dass sich die Ethereum-Community „Out-of-Band“ koordiniert und sich darauf einigt, dem einen oder anderen Fork zu folgen und den anderen zu ignorieren.

Angreifer mit ~50 % des gesamten Stakes

Bei 50 % der gestakten Ether könnte eine böswillige Gruppe von Validatoren die Chain theoretisch in zwei gleich große Forks aufteilen und dann einfach ihren gesamten 50 %-Stake verwenden, um entgegen den ehrlichen Validatoren abzustimmen, wodurch die beiden Forks aufrechterhalten und die Endgültigkeit verhindert wird. Das Inaktivitätsleck auf beiden Forks würde schließlich dazu führen, dass beide Chains endgültig werden. An diesem Punkt besteht die einzige Möglichkeit darin, auf eine soziale Wiederherstellung zurückzugreifen.

Es ist sehr unwahrscheinlich, dass eine gegnerische Gruppe von Validatoren angesichts einer gewissen Fluktuation bei der Anzahl ehrlicher Validatoren, der Netzwerklatenz usw. konstant genau 50 % des gesamten Stakes kontrollieren könnte – die enormen Kosten für die Durchführung eines solchen Angriffs in Kombination mit der geringen Erfolgswahrscheinlichkeit scheinen eine starke Abschreckung für einen rationalen Angreifer zu sein, insbesondere wenn eine kleine zusätzliche Investition, um mehr als 50 % zu erhalten, viel mehr Macht freisetzt.

Bei >50 % des gesamten Stakes könnte der Angreifer den Fork-Choice-Algorithmus dominieren. In diesem Fall wäre der Angreifer in der Lage, mit der Mehrheitsstimme zu attestieren, was ihm ausreichend Kontrolle gibt, um kurze Reorgs durchzuführen, ohne ehrliche Clients täuschen zu müssen. Die ehrlichen Validatoren würden nachziehen, da ihr Fork-Choice-Algorithmus die vom Angreifer bevorzugte Chain ebenfalls als die schwerste ansehen würde, sodass die Chain endgültig werden könnte. Dies ermöglicht es dem Angreifer, bestimmte Transaktionen zu zensieren, Short-Range-Reorgs durchzuführen und maximales MEV zu extrahieren, indem er Blöcke zu seinen Gunsten neu anordnet. Die Verteidigung dagegen sind die enormen Kosten eines Mehrheits-Stakes (derzeit knapp 19 Milliarden USD), die von einem Angreifer aufs Spiel gesetzt werden, da die soziale Schicht wahrscheinlich eingreifen und einen ehrlichen Minderheits-Fork übernehmen wird, was den Stake des Angreifers dramatisch abwertet.

Angreifer mit >=66 % des gesamten Stakes

Ein Angreifer mit 66 % oder mehr der gesamten gestakten Ether kann seine bevorzugte Chain endgültig machen, ohne ehrliche Validatoren zwingen zu müssen. Der Angreifer kann einfach für seinen bevorzugten Fork abstimmen und ihn dann endgültig machen, einfach weil er mit einer unehrlichen Supermehrheit abstimmen kann. Als Stakeholder mit Supermehrheit würde der Angreifer immer den Inhalt der endgültigen Blöcke kontrollieren, mit der Macht, auszugeben, zurückzuspulen und erneut auszugeben, bestimmte Transaktionen zu zensieren und die Chain nach Belieben zu reorgen. Durch den Kauf zusätzlicher Ether, um 66 % statt 51 % zu kontrollieren, kauft der Angreifer effektiv die Fähigkeit, Ex-post-Reorgs und Umkehrungen der Endgültigkeit durchzuführen (d. h. die Vergangenheit zu ändern sowie die Zukunft zu kontrollieren). Die einzigen wirklichen Verteidigungen hier sind die enormen Kosten von 66 % der gesamten gestakten Ether und die Option, auf die soziale Schicht zurückzugreifen, um die Übernahme eines alternativen Forks zu koordinieren. Wir können dies im nächsten Abschnitt genauer untersuchen.

Menschen: die letzte Verteidigungslinie

Wenn es den unehrlichen Validatoren gelingt, ihre bevorzugte Version der Chain endgültig zu machen, gerät die Ethereum-Community in eine schwierige Situation. Die kanonische Chain enthält einen unehrlichen Abschnitt, der in ihre Geschichte eingebrannt ist, während ehrliche Validatoren am Ende dafür bestraft werden können, dass sie für eine alternative (ehrliche) Chain attestieren. Beachten Sie, dass eine endgültige, aber falsche Chain auch durch einen Fehler in einem Mehrheits-Client entstehen könnte. Letztendlich besteht der ultimative Rückhalt darin, sich auf die soziale Schicht – Layer 0 – zu verlassen, um die Situation zu lösen.

Eine der Stärken des PoS-Konsenses von Ethereum ist, dass es eine Reihe von Verteidigungsstrategien (opens in a new tab) gibt, die die Community im Falle eines Angriffs anwenden kann. Eine minimale Reaktion könnte darin bestehen, die Validatoren der Angreifer ohne zusätzliche Strafe zwangsweise aus dem Netzwerk austreten zu lassen. Um wieder in das Netzwerk einzutreten, müsste sich der Angreifer in eine Aktivierungswarteschlange einreihen, die sicherstellt, dass die Validatorenmenge allmählich wächst. Beispielsweise dauert das Hinzufügen von genügend Validatoren, um die Menge der gestakten Ether zu verdoppeln, etwa 200 Tage, was den ehrlichen Validatoren effektiv 200 Tage verschafft, bevor der Angreifer einen weiteren 51%-Angriff versuchen kann. Die Community könnte sich jedoch auch dafür entscheiden, den Angreifer härter zu bestrafen, indem sie vergangene Belohnungen widerruft oder einen Teil (bis zu 100 %) seines gestakten Kapitals verbrennt.

Unabhängig von der dem Angreifer auferlegten Strafe muss die Community auch gemeinsam entscheiden, ob die unehrliche Chain, obwohl sie vom in den Ethereum-Clients codierten Fork-Choice-Algorithmus bevorzugt wird, tatsächlich ungültig ist und die Community stattdessen auf der ehrlichen Chain aufbauen sollte. Ehrliche Validatoren könnten sich kollektiv darauf einigen, auf einem von der Community akzeptierten Fork der Ethereum-Blockchain aufzubauen, der sich beispielsweise vor Beginn des Angriffs von der kanonischen Chain abgespalten hat oder bei dem die Validatoren der Angreifer zwangsweise entfernt wurden. Ehrliche Validatoren hätten einen Anreiz, auf dieser Chain aufzubauen, da sie die Strafen vermeiden würden, die gegen sie verhängt werden, weil sie (zu Recht) nicht für die Chain des Angreifers attestieren. Börsen, On-Ramps und auf Ethereum basierende Anwendungen würden vermutlich lieber auf der ehrlichen Chain sein und den ehrlichen Validatoren zur ehrlichen Blockchain folgen.

Dies wäre jedoch eine erhebliche Governance-Herausforderung. Einige Benutzer und Validatoren würden zweifellos durch den Wechsel zurück zur ehrlichen Chain verlieren, Transaktionen in Blöcken, die nach dem Angriff validiert wurden, könnten möglicherweise zurückgesetzt werden, was die Anwendungsschicht stört, und es untergräbt ganz einfach die Ethik einiger Benutzer, die dazu neigen zu glauben, dass „Code Gesetz ist“ (Code is law). Börsen und Anwendungen werden höchstwahrscheinlich Offchain-Aktionen mit Onchain-Transaktionen verknüpft haben, die nun möglicherweise zurückgesetzt werden, was eine Kaskade von Rücknahmen und Revisionen auslöst, die schwer fair zu entwirren wäre, insbesondere wenn unrechtmäßig erworbene Gewinne gemischt, in Dezentralisierte Finanzen (DeFi) oder andere Derivate mit sekundären Auswirkungen für ehrliche Benutzer eingezahlt wurden. Zweifellos hätten einige Benutzer, vielleicht sogar institutionelle, bereits von der unehrlichen Chain profitiert, sei es durch Scharfsinn oder durch Zufall, und könnten sich einem Fork widersetzen, um ihre Gewinne zu schützen. Es gab Forderungen, die Reaktion der Community auf >51%-Angriffe zu proben, damit eine sinnvolle koordinierte Schadensbegrenzung schnell durchgeführt werden kann. Es gibt einige nützliche Diskussionen von Vitalik auf ethresear.ch hier (opens in a new tab) und hier (opens in a new tab) sowie auf Twitter hier (opens in a new tab). Das Ziel einer koordinierten sozialen Reaktion sollte es sein, sehr zielgerichtet und spezifisch bei der Bestrafung des Angreifers vorzugehen und die Auswirkungen für andere Benutzer zu minimieren.

Governance ist ohnehin schon ein kompliziertes Thema. Die Verwaltung einer Layer-0-Notfallreaktion auf eine unehrliche, endgültig werdende Chain wäre zweifellos eine Herausforderung für die Ethereum-Community, aber es ist bereits passiert – zweimal – in der Geschichte von Ethereum).

Dennoch hat es etwas ziemlich Befriedigendes, dass der letzte Rückhalt im echten Leben (Meatspace) liegt. Letztendlich müssten sich echte Menschen, selbst mit diesem phänomenalen Technologie-Stack über uns, im schlimmsten Fall koordinieren, um einen Ausweg zu finden.

Zusammenfassung

Diese Seite untersuchte einige der Möglichkeiten, wie Angreifer versuchen könnten, das Proof-of-Stake-Konsensprotokoll von Ethereum auszunutzen. Reorgs und Verzögerungen der Endgültigkeit wurden für Angreifer mit zunehmenden Anteilen der gesamten gestakten Ether untersucht. Insgesamt hat ein reicherer Angreifer mehr Erfolgschancen, da sich sein Stake in Stimmacht übersetzt, die er nutzen kann, um den Inhalt zukünftiger Blöcke zu beeinflussen. Bei bestimmten Schwellenwerten an gestakten Ethern steigt die Macht des Angreifers:

33 %: Verzögerung der Endgültigkeit

34 %: Verzögerung der Endgültigkeit, doppelte Endgültigkeit

51 %: Verzögerung der Endgültigkeit, doppelte Endgültigkeit, Zensur, Kontrolle über die Zukunft der Blockchain

66 %: Verzögerung der Endgültigkeit, doppelte Endgültigkeit, Zensur, Kontrolle über die Zukunft und Vergangenheit der Blockchain

Es gibt auch eine Reihe raffinierterer Angriffe, die kleine Mengen an gestakten Ethern erfordern, aber darauf beruhen, dass ein sehr raffinierter Angreifer eine genaue Kontrolle über das Timing von Nachrichten hat, um die ehrlichen Validatoren zu seinen Gunsten zu beeinflussen.

Insgesamt ist das Risiko eines erfolgreichen Angriffs trotz dieser potenziellen Angriffsvektoren gering, sicherlich geringer als bei Proof-of-Work-Äquivalenten. Dies liegt an den enormen Kosten der gestakten Ether, die von einem Angreifer aufs Spiel gesetzt werden, der darauf abzielt, ehrliche Validatoren mit seiner Stimmacht zu überwältigen. Die eingebaute Anreizschicht nach dem Prinzip „Zuckerbrot und Peitsche“ schützt vor den meisten Verfehlungen, insbesondere bei Angreifern mit geringem Stake. Subtilere Bouncing- und Balancing-Angriffe sind ebenfalls unwahrscheinlich erfolgreich, da reale Netzwerkbedingungen die genaue Kontrolle der Nachrichtenübermittlung an bestimmte Teilmengen von Validatoren sehr schwierig machen und Client-Teams die bekannten Bouncing-, Balancing- und Avalanche-Angriffsvektoren schnell mit einfachen Patches geschlossen haben.

34%-, 51%- oder 66%-Angriffe würden wahrscheinlich eine soziale Out-of-Band-Koordination zur Lösung erfordern. Während dies für die Community wahrscheinlich schmerzhaft wäre, ist die Fähigkeit einer Community, Out-of-Band zu reagieren, eine starke Abschreckung für einen Angreifer. Die soziale Schicht von Ethereum ist der ultimative Rückhalt – ein technisch erfolgreicher Angriff könnte immer noch neutralisiert werden, indem die Community zustimmt, einen ehrlichen Fork zu übernehmen. Es gäbe ein Rennen zwischen dem Angreifer und der Ethereum-Community – die Milliarden von Dollar, die für einen 66%-Angriff ausgegeben wurden, würden wahrscheinlich durch einen erfolgreichen sozialen Koordinationsangriff zunichte gemacht, wenn dieser schnell genug durchgeführt würde, sodass der Angreifer mit schweren Taschen illiquider gestakter Ether auf einer bekannten unehrlichen Chain zurückbleibt, die von der Ethereum-Community ignoriert wird. Die Wahrscheinlichkeit, dass dies für den Angreifer letztendlich profitabel wäre, ist gering genug, um eine wirksame Abschreckung zu sein. Deshalb ist die Investition in die Aufrechterhaltung einer kohäsiven sozialen Schicht mit eng aufeinander abgestimmten Werten so wichtig.

Weiterführende Literatur

• Ausführlichere Version dieser Seite (opens in a new tab)
• Vitalik über die Endgültigkeit der Abwicklung (opens in a new tab)
• LMD-GHOST-Papier (opens in a new tab)
• Casper-FFG-Papier (opens in a new tab)
• Gasper-Papier (opens in a new tab)
• Konsens-Spezifikationen zum Proposer-Weight-Boosting (opens in a new tab)
• Bouncing-Angriffe auf ethresear.ch (opens in a new tab)
• SSLE-Forschung (opens in a new tab)

Letzte Aktualisierung der Seite: 13. April 2026

p (opens in a new tab)

c (opens in a new tab)

n (opens in a new tab)

+6

Mitwirkende ansehen