Angriff und Verteidigung bei Ethereums Proof-of-Stake

Diebe und Saboteure suchen ständig nach Möglichkeiten, die Client-Software von Ethereum anzugreifen. Diese Seite beschreibt die bekannten Angriffsvektoren auf die Konsensebene 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

Ein gewisses Grundwissen über Proof-of-Stake ist erforderlich. Außerdem ist es hilfreich, ein grundlegendes Verständnis der Anreizebene 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 Private-Key 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 Finalität oder Finalitätsverzögerung.

Ein „Reorg“ ist eine Neuanordnung 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 Double-Spending oder Wertabschöpfung durch Front-Running- und Back-Running-Transaktionen (MEV - Maximal extrahierbarer Wert) 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 des Reorgs ist die „Finalitätsumkehrung“, bei der Blöcke entfernt oder ersetzt werden, die zuvor finalisiert wurden. Dies ist nur möglich, wenn mehr als ⅓ der gesamten eingesetzten Ether vom Angreifer zerstört werden – diese Garantie ist als „wirtschaftliche Finalität“ bekannt – dazu später mehr.

Doppelte Finalität ist der unwahrscheinliche, aber schwerwiegende Zustand, in dem zwei Forks gleichzeitig finalisieren 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 eingesetzten Ether zu riskieren. Die Community wäre gezwungen, sich Off-Chain zu koordinieren und sich darauf zu einigen, welcher Chain sie folgen soll, was Stärke auf der sozialen Ebene erfordern würde.

Ein Angriff zur Finalitätsverzögerung hindert das Netzwerk daran, die notwendigen Bedingungen zur Finalisierung von Abschnitten der Chain zu erreichen. Ohne Finalität ist es schwer, Finanzanwendungen zu vertrauen, die auf Ethereum aufbauen. Das Ziel eines Angriffs zur Finalitätsverzögerung 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 Ebene 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 nun geklärt ist, warum ein Angreifer Ethereum angreifen könnte, untersuchen die folgenden Abschnitte, wie er dabei vorgehen könnte.

Angriffsmethoden

Angriffe auf Ebene 0 (Layer 0)

Zunächst einmal können Personen, die nicht aktiv an Ethereum teilnehmen (indem sie Client-Software ausführen), angreifen, indem sie auf die soziale Ebene (Ebene 0) abzielen. Ebene 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, die sich gegen die Entwickler-Community richten. Dies könnte zum freiwilligen Ausscheiden von Entwicklern führen und den Fortschritt von Ethereum verlangsamen.
Übereifrige Regulierung könnte ebenfalls als Angriff auf Ebene 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), die Verzögerung wichtiger Entscheidungen, die Erstellung von Spam usw. zu verlangsamen.
Bestechung von Schlüsselakteuren 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 Angriff auf Ebene 0 könnte ein Multiplikator für einen kryptoökonomischen Angriff sein. Wenn beispielsweise Zensur oder Finalitätsumkehrung durch einen böswilligen Mehrheits-Stakeholder erreicht würden, könnte die Untergrabung der sozialen Ebene es schwieriger machen, eine Out-of-Band-Reaktion der Community zu koordinieren.

Die Abwehr von Angriffen auf Ebene 0 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 Ebene ist ein klares Leitbild und Governance-Protokoll. Ethereum hat sich als Champion für Dezentralisierung und Sicherheit unter den Smart Contract-Ebene-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 kompromittiert. Die Bewertung eines Narrativs anhand dieser Kernprinzipien und deren Prüfung durch aufeinanderfolgende Überprüfungsrunden im EIP-Prozess (Ethereum-Verbesserungsvorschlag) 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 und Die“-Narrative aufzubauen. Tribalismus und toxischer Maximalismus schaden der Community und untergraben die Sicherheit von Ebene 0. Ethereans mit einem begründeten Interesse an der Sicherheit des Netzwerks sollten ihr Verhalten online und im echten Leben (Meatspace) als direkten Beitrag zur Sicherheit von Ethereums Ebene 0 betrachten.

Angriff auf das Protokoll

Jeder kann die Client-Software von Ethereum ausführen. Um einer Anwendung einen Validator hinzuzufügen, muss ein Benutzer 32 Ether in den Einzahlungsvertrag einzahlen (Staking). Ein Validator ermöglicht es einem Benutzer, sich aktiv an der Netzwerksicherheit von Ethereum zu beteiligen, indem er neue Blöcke vorschlägt und Bestätigungen dafür abgibt. 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 Einsatz zu riskieren. Eine Möglichkeit, einen Angriff durchzuführen, besteht darin, einen größeren Anteil des gesamten Einsatzes anzuhäufen und diesen dann zu nutzen, um ehrliche Validatoren zu überstimmen. Je größer der vom Angreifer kontrollierte Anteil am Einsatz ist, desto größer ist seine Stimmmacht, 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. Stattdessen müssen sie subtile Techniken anwenden, um die ehrliche Mehrheit dazu zu manipulieren, auf eine bestimmte Weise zu handeln.

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

Angriffe mit kleinen Mengen an ETH

Reorgs

Mehrere wissenschaftliche Arbeiten haben Angriffe auf Ethereum erklärt, die Reorgs oder Finalitätsverzögerungen mit nur einem kleinen Anteil der gesamten eingesetzten Ether erreichen. Diese Angriffe beruhen im Allgemeinen darauf, dass der Angreifer den anderen Validatoren bestimmte Informationen vorenthält und diese dann auf nuancierte Weise und/oder zu einem günstigen Zeitpunkt veröffentlicht. Sie zielen in der Regel darauf ab, einen oder mehrere 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 bestätigen kann, ihn aber nicht an andere Blockchain-Knoten im Netzwerk weiterleitet. Stattdessen behält er diesen bestätigten Block bis zum nächsten Slot n+2 zurück. 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 Bestätigungen dafür freigeben und mit seinen Stimmen für Slot n+2 auch bestätigen, dass B die Spitze der Chain ist, wodurch er die Existenz des ehrlichen Blocks C effektiv leugnet. 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 Einsatzes 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 geringeren Einsätzen versucht werden. Neuder et al. 2020 (opens in a new tab) beschrieben, dass dieser Angriff mit einem Einsatz von 30 % funktioniert, aber später wurde gezeigt, dass er mit 2 % des gesamten Einsatzes (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 wird als Balancing-Angriff bezeichnet. Der Angreifer wartet auf seine Chance, einen Block vorzuschlagen, und wenn diese kommt, verhält er sich zweideutig (Equivocation) 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 Zweideutigkeit würde vom Fork-Choice-Algorithmus erkannt werden, und der Block-Vorschlagende würde durch Slashing bestraft 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 Bestätigungen abgeben. In der Zwischenzeit halten die verbleibenden böswilligen Validatoren ihre Bestätigungen zurück. Indem sie dann selektiv die Bestätigungen, die den einen oder anderen Fork begünstigen, an gerade genug Validatoren freigeben, genau in dem Moment, in dem der Fork-Choice-Algorithmus ausgeführt wird, kippen sie das angesammelte Gewicht der Bestätigungen 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 vereinen kann, würde das Netzwerk nicht finalisieren.

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 Herwechseln der Rechtfertigung zwischen zwei Forks verhindert, dass es Paare von gerechtfertigten Quell- und Ziel-Checkpoints gibt, die auf einer der beiden Chains finalisiert werden können, wodurch die Finalität 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 Verteidigungsmechanismen 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 zuletzt 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 hindert den Angreifer daran, Stimmen aufzusparen, 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-Vorschlagender seinen Block sehr schnell nach Beginn des Slots ausgibt. Dann gibt es eine Zeitspanne 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 Bestätigungen, die von langsamen Validatoren eintreffen, im Vergleich zu den früher eingetroffenen abgewertet. Dies begünstigt schnelle Vorschlagende 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“ schützt, d. h. solche, die von einem Angreifer mit einem kleinen Einsatz versucht werden. Tatsächlich kann das Proposer Boosting selbst von größeren Stakeholdern ausgetrickst werden. Die Autoren dieses Beitrags (opens in a new tab) beschreiben, wie ein Angreifer mit 7 % des Einsatzes seine Stimmen strategisch einsetzen kann, um ehrliche Validatoren dazu zu bringen, auf seinem Fork aufzubauen und so einen ehrlichen Block durch einen Reorg zu verdrängen. 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 Einsatz bedeutet auch mehr riskiertes Kapital und eine stärkere wirtschaftliche Abschreckung.

Es wurde auch ein Balancing-Angriff vorgeschlagen, der speziell auf die LMD-Regel abzielt (opens in a new tab) und der trotz Proposer Boosting als durchführbar erachtet wurde. Ein Angreifer richtet zwei konkurrierende Chains ein, indem er seinen Blockvorschlag zweideutig macht und jeden Block an etwa die Hälfte des Netzwerks weiterleitet, wodurch ein ungefähres Gleichgewicht zwischen den Forks hergestellt wird. Dann verhalten sich die kolludierenden Validatoren bei ihren Abstimmungen zweideutig 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 Bestätigung 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 Angreifer „bemerkenswerte Macht“ verleiht, um einen Balancing-Angriff durchzuführen.

Dieser LMD-Angriffsvektor wurde geschlossen, indem der Fork-Choice-Algorithmus aktualisiert wurde (opens in a new tab), sodass er zweideutig handelnde Validatoren vollständig aus der Fork-Choice-Betrachtung ausschließt. Der zukünftige Einfluss von zweideutig handelnden Validatoren wird vom Fork-Choice-Algorithmus ebenfalls 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-Vorschlagende 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 zweideutig sind. Die Autoren deuten an, dass Proposer Boosting – die primäre Verteidigung gegen Balancing- und Bouncing-Angriffe – nicht vor einigen Varianten des Avalanche-Angriffs schützt. Die Autoren demonstrierten den Angriff jedoch auch nur an einer stark idealisierten Version von Ethereums Fork-Choice-Algorithmus (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 Zweideutigkeiten sind, die ignoriert werden. Anders ausgedrückt: Die Konsens-Clients zählen keine Zweideutigkeiten – sie verwenden die zuerst eintreffende Nachricht von jedem Validator, und Zweideutigkeiten 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 Bestätigende ihre Sicht auf die Fork-Choice n Sekunden vor Beginn eines Slots einfrieren und der Vorschlagende dann hilft, die Sicht auf die Chain im gesamten Netzwerk zu synchronisieren. Ein weiteres potenzielles Upgrade ist die Single-Slot-Finalität (opens in a new tab), die vor Angriffen schützt, die auf dem Timing von Nachrichten basieren, indem die Chain nach nur einem Slot finalisiert wird.

Finalitätsverzögerung

Dasselbe Papier (opens in a new tab), das zuerst den kostengünstigen Ein-Block-Reorg-Angriff beschrieb, beschrieb auch einen Angriff zur Finalitätsverzögerung (auch bekannt als „Liveness Failure“), der darauf beruht, dass der Angreifer der Block-Vorschlagende für einen Epochengrenzen-Block ist. Dies ist von entscheidender Bedeutung, da diese Epochengrenzen-Blöcke zu den Checkpoints werden, die Casper FFG verwendet, um Teile der Chain zu finalisieren. 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 freigegeben. Sie geben Bestätigungen für ihren Block ab, 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 Finalität, da es für keinen der beiden Forks eine 2/3-Supermehrheit an Bestätigungen geben wird. Je kleiner der Einsatz, desto präziser muss das Timing sein, da der Angreifer weniger Bestätigungen 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, neben dem ehrlichen Fork einen separaten Fork der Blockchain aufrechterhält und schließlich die ehrliche Validatoren-Menge davon überzeugt, zu einem viel späteren, günstigen Zeitpunkt zu diesem zu wechseln. Diese Art von Angriff ist auf Ethereum aufgrund des Finalitäts-Gadgets nicht möglich, das 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 finalisierte Blöcke einfach nicht reorg-en. Neue Blockchain-Knoten, die dem Netzwerk beitreten, tun dies, indem sie einen vertrauenswürdigen aktuellen Zustands-Hash (einen „Weak Subjectivity (opens in a new tab) Checkpoint“) finden und ihn als Pseudo-Genesis-Block verwenden, auf dem sie aufbauen. Dies schafft ein „Vertrauens-Gateway“ für einen neuen Blockchain-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 Validatoren-Menge als Block-Vorschlagenden aus. Dies kann mithilfe einer öffentlich bekannten Funktion berechnet werden, und es ist für einen Angreifer möglich, den nächsten Block-Vorschlagenden kurz vor seinem Blockvorschlag zu identifizieren. Dann kann der Angreifer den Block-Vorschlagenden mit Spam überhäufen, um ihn daran zu hindern, Informationen mit seinen Peers auszutauschen. Für den Rest des Netzwerks würde es so aussehen, als wäre der Block-Vorschlagende 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-Vorschlagende 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 Einsatz 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 freier Wildbahn existieren, aber es zeigt die extrem hohe Hürde an technischer Eignung, Wissen über die Konsensebene und Glück, die erforderlich ist, damit ein Angreifer mit Minderheitseinsatz effektiv sein kann. Aus der Sicht eines Angreifers könnte es die beste Wette sein, so viel Ether wie möglich anzuhäufen und mit einem größeren Anteil am gesamten Einsatz bewaffnet zurückzukehren.

Angreifer mit >= 33 % des gesamten Einsatzes

Alle zuvor in diesem Artikel erwähnten Angriffe haben eine höhere Erfolgswahrscheinlichkeit, wenn der Angreifer über mehr eingesetzte Ether verfügt, mit denen er abstimmen kann, und über 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 eingesetzte Ether wie möglich zu kontrollieren.

33 % der eingesetzten Ether sind ein Richtwert für einen Angreifer, da er mit allem, was über diesen Betrag hinausgeht, die Möglichkeit hat, die Finalisierung der Chain zu verhindern, ohne die Aktionen der anderen Validatoren genau kontrollieren zu müssen. Sie können einfach alle zusammen verschwinden. Wenn 1/3 oder mehr der eingesetzten Ether böswillig Bestätigungen abgeben oder dies unterlassen, kann keine 2/3-Supermehrheit existieren und die Chain kann nicht finalisieren. Die Verteidigung dagegen ist das Inactivity Leak (Inaktivitätsleck). Das Inactivity Leak identifiziert diejenigen Validatoren, die keine Bestätigungen abgeben oder entgegen der Mehrheit bestätigen. Die eingesetzten Ether, die diesen nicht bestätigenden Validatoren gehören, werden allmählich abgezogen, bis sie schließlich zusammen weniger als 1/3 der Gesamtsumme ausmachen, sodass die Chain wieder finalisieren kann.

Der Zweck des Inactivity Leaks besteht darin, die Chain wieder zur Finalisierung zu bringen. Der Angreifer verliert jedoch auch einen Teil seiner eingesetzten Ether. Anhaltende Inaktivität bei Validatoren, die 33 % der gesamten eingesetzten Ether repräsentieren, ist sehr teuer, auch wenn die Validatoren nicht durch Slashing bestraft 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 Einsatzes kontrolliert, eine doppelte Finalität verursachen. Dies liegt daran, dass der Angreifer sich zweideutig verhalten 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 eingesetzten Ether stimmen. Jeder Fork benötigt nur 50 % der verbleibenden Validatoren, die für ihn stimmen, damit beide Forks von einer Supermehrheit unterstützt werden. In diesem Fall können beide Chains finalisieren (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 Einsatz (34 % von ~10 Millionen Ether beim heutigen Validatoren-Set) zerstören, um diese doppelte Finalität zu erreichen, da 34 % seiner Validatoren gleichzeitig doppelt abstimmen würden – ein Vergehen, das mit Slashing und der maximalen Korrelationsstrafe geahndet wird. Die Verteidigung gegen diesen Angriff sind die sehr hohen Kosten für die Zerstörung von 34 % der gesamten eingesetzten 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 Einsatzes

Bei 50 % der eingesetzten 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 %-Einsatz verwenden, um entgegen der ehrlichen Validatoren-Menge abzustimmen, wodurch die beiden Forks aufrechterhalten und die Finalität verhindert wird. Das Inactivity Leak auf beiden Forks würde schließlich dazu führen, dass beide Chains finalisieren. An diesem Punkt besteht die einzige Option darin, auf eine soziale Wiederherstellung zurückzugreifen.

Es ist sehr unwahrscheinlich, dass eine feindliche Gruppe von Validatoren angesichts einer gewissen Fluktuation bei den Zahlen der ehrlichen Validatoren, der Netzwerklatenz usw. konstant genau 50 % des gesamten Einsatzes 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 Einsatzes könnte der Angreifer den Fork-Choice-Algorithmus dominieren. In diesem Fall wäre der Angreifer in der Lage, mit der Mehrheitsstimme Bestätigungen abzugeben, 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 finalisieren könnte. Dies ermöglicht es dem Angreifer, bestimmte Transaktionen zu zensieren, Short-Range-Reorgs durchzuführen und maximalen MEV zu extrahieren, indem er Blöcke zu seinen Gunsten neu anordnet. Die Verteidigung dagegen sind die enormen Kosten eines Mehrheitseinsatzes (derzeit knapp 19 Milliarden USD), die von einem Angreifer aufs Spiel gesetzt werden, da die soziale Ebene wahrscheinlich eingreifen und einen ehrlichen Minderheits-Fork übernehmen wird, was den Einsatz des Angreifers dramatisch abwertet.

Angreifer mit >=66 % des gesamten Einsatzes

Ein Angreifer mit 66 % oder mehr der gesamten eingesetzten Ether kann seine bevorzugte Chain finalisieren, ohne ehrliche Validatoren zwingen zu müssen. Der Angreifer kann einfach für seinen bevorzugten Fork stimmen und ihn dann finalisieren, einfach weil er mit einer unehrlichen Supermehrheit abstimmen kann. Als Stakeholder mit Supermehrheit würde der Angreifer immer den Inhalt der finalisierten Blöcke kontrollieren, mit der Macht, auszugeben, zurückzuspulen und erneut auszugeben, bestimmte Transaktionen zu zensieren und die Chain nach Belieben zu reorg-en. Durch den Kauf zusätzlicher Ether, um 66 % statt 51 % zu kontrollieren, kauft der Angreifer effektiv die Fähigkeit, Ex-post-Reorgs und Finalitätsumkehrungen 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 eingesetzten Ether und die Option, auf die soziale Ebene 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 zu finalisieren, 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 Bestätigungen für eine alternative (ehrliche) Chain abgeben. Beachten Sie, dass eine finalisierte, aber fehlerhafte Chain auch durch einen Fehler in einem Mehrheits-Client entstehen könnte. Letztendlich besteht der ultimative Rückhalt darin, sich auf die soziale Ebene – Ebene 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 zu entfernen. Um wieder in das Netzwerk einzutreten, müsste sich der Angreifer in eine Aktivierungswarteschlange einreihen, die sicherstellt, dass die Validatoren-Menge allmählich wächst. Beispielsweise dauert das Hinzufügen von genügend Validatoren, um die Menge der eingesetzten Ether zu verdoppeln, etwa 200 Tage, was den ehrlichen Validatoren effektiv 200 Tage Zeit 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 eingesetzten Kapitals verbrennt.

Unabhängig von der dem Angreifer auferlegten Strafe muss die Community auch gemeinsam entscheiden, ob die unehrliche Chain, obwohl sie diejenige ist, die von dem in den Ethereum-Clients codierten Fork-Choice-Algorithmus bevorzugt wird, tatsächlich ungültig ist und dass die Community stattdessen auf der ehrlichen Chain aufbauen sollte. Ehrliche Validatoren würden 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) keine Bestätigungen für die Chain des Angreifers abgeben. 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 Anwendungsebene stört, und es untergräbt ganz einfach die Ethik einiger Benutzer, die dazu neigen zu glauben, dass „Code is Law“ (Code ist Gesetz) gilt. Börsen und Anwendungen werden höchstwahrscheinlich Off-Chain-Aktionen mit Transaktionen auf der Blockchain 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 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 Aufrufe, 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 Bewältigung einer Notfallreaktion auf Ebene 0 auf eine unehrliche finalisierende 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 hat einige der Möglichkeiten untersucht, wie Angreifer versuchen könnten, das Proof-of-Stake-Konsensprotokoll von Ethereum auszunutzen. Reorgs und Finalitätsverzögerungen wurden für Angreifer mit zunehmenden Anteilen an den gesamten eingesetzten Ether untersucht. Insgesamt hat ein reicherer Angreifer mehr Erfolgschancen, da sich sein Einsatz in Stimmmacht übersetzt, mit der er den Inhalt zukünftiger Blöcke beeinflussen kann. Bei bestimmten Schwellenwerten an eingesetzten Ether steigt die Macht des Angreifers:

33 %: Finalitätsverzögerung

34 %: Finalitätsverzögerung, doppelte Finalität

51 %: Finalitätsverzögerung, doppelte Finalität, Zensur, Kontrolle über die Zukunft der Blockchain

66 %: Finalitätsverzögerung, doppelte Finalität, Zensur, Kontrolle über die Zukunft und Vergangenheit der Blockchain

Es gibt auch eine Reihe raffinierterer Angriffe, die kleine Mengen an eingesetzten Ether erfordern, aber darauf beruhen, dass ein sehr raffinierter Angreifer eine genaue Kontrolle über das Timing von Nachrichten hat, um die ehrliche Validatoren-Menge 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 eingesetzten Ether, die von einem Angreifer aufs Spiel gesetzt werden, der darauf abzielt, ehrliche Validatoren mit seiner Stimmmacht zu überwältigen. Die eingebaute Anreizebene nach dem „Zuckerbrot und Peitsche“-Prinzip schützt vor den meisten Verfehlungen, insbesondere bei Angreifern mit geringem Einsatz. 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.

Angriffe mit 34 %, 51 % oder 66 % würden zur Lösung wahrscheinlich eine soziale Out-of-Band-Koordination 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 Ebene 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 eingesetzter Ether auf einer bekannten unehrlichen Chain zurückbleibt, die von der Ethereum-Community ignoriert wird. Die Wahrscheinlichkeit, dass dies für den Angreifer am Ende profitabel wäre, ist gering genug, um eine wirksame Abschreckung zu sein. Aus diesem Grund sind Investitionen in die Aufrechterhaltung einer kohäsiven sozialen Ebene mit eng aufeinander abgestimmten Werten so wichtig.