Angriff und Verteidigung im Proof-of-Stake-System auf Ethereum

Diebe und Saboteure suchen ständig nach Möglichkeiten, die Client-Software auf Ethereum anzugreifen. Diese Seite stellt die bekannten Angriffsvektoren auf Ethereums Konsensebene dar und erläutert, wie diese Angriffe abgewehrt werden können. Die Informationen auf dieser Seite stammen aus einer ausführlicheren Version(opens in a new tab).

Voraussetzungen

Einige Grundkenntnisse im Bereich Proof-of-Stake sind erforderlich. Außerdem ist es hilfreich, Grundkenntnisse über die Anreizebene und den Abspaltungs-Wahl-Algorithmus auf Ethereum, LMD-GHOST, zu haben.

Was möchten Angreifer?

Ein häufiges Missverständnis ist, dass erfolgreiche Angreifer neue Ether generieren oder sie von beliebigen Konten abziehen können. Keines von beidem ist möglich, da alle Transaktionen von allen Ausführungs-Clients im Netzwerk ausgeführt werden. Diese müssen einfache Gültigkeitsbedingungen erfüllen (z. B. müssen Transaktionen vom privaten Schlüssel eines Absenders signiert werden, der Absender muss über ausreichend Guthaben verfügen, usw.), sonst werden sie einfach rückgängig gemacht. Es gibt drei verschiedene Arten von Ergebnissen, die ein Angreifer realistischerweise erreichen möchte: Neuorganisationen, doppelte Endgültigkeit oder das Verzögern von Endgültigkeit.

Eine “Neuorganisation” ist eine Neumischung von Blöcken in eine neue Reihenfolge. Hier könnten einige Blöcke in der kanonischen Chain hinzugefügt oder entfernt werden. Bei einer böswilligen Neuanordnung könnte sichergegangen werden, dass spezifische Blöcke ein- oder ausgeschlossen werden. Dies könnte dazu führen, dass für vorweglaufende und zurücklaufende Transaktionen (MEV) doppelte Ausgaben oder Wertextraktionen getätigt werden. Neuorganisationen könnten auch dazu eingesetzt werden, um zu verhindern, dass bestimmte Transaktionen in die kanonische Chain aufgenommen werden – eine Form der Zensur. Die extremste Form einer Neuorganisation ist die „Endgültigkeitsumkehrung“, bei der Blöcke ersetzt oder entfernt werden, die zuvor bereits finalisiert wurden. Das ist nur möglich, wenn mehr als ⅓ der insgesamt eingesetzten Ether vom Angreifer zerstört wird – diese Garantie wird als „wirtschaftliche Endgültigkeit“ bezeichnet – mehr dazu später.

Doppelte Endgültigkeit ist die unwahrscheinliche, aber ernste Bedingung, bei der zwei Abspaltungen gleichzeitig finalisiert werden können, was zu einer permanente Spaltung der Chain führt. Das ist theoretisch möglich für einen Angreifer, der dazu bereit ist, 34 % der insgesamt eingesetzten Ether zu riskieren. Die Community wäre dazu gezwungen, sich außerhalb der Chain zu koordinieren und sich darauf zu einigen, welcher Chain gefolgt werden soll. Dies würde eine starke Sozialebene erfordern.

Ein Angriff, bei dem die Endgültigkeit verzögert wird, hindert das Netzwerk daran, die notwendigen Bedingungen zu erreichen, um die Chain zu finalisieren. Ohne Endgültigkeit ist es schwer, finanziellen Anwendungen auf Basis von Ethereum zu vertrauen. Das Ziel eines solchen Angriffs wäre wahrscheinlich eher die Störung von Ethereum als eine direkte Bereicherung, es sei denn, der Angreifer verfügt über eine/einige strategische Short-Position(en).

Ein Angriff auf die soziale Ebene könnte darauf abzielen, das öffentliche Vertrauen in Ethereum zu untergraben, Ether zu entwerten, die Akzeptanz zu verringern oder die Ethereum-Community zu schwächen, sodass die Koordination außerhalb des Bands erschwert wird.

Nachdem wir festgestellt haben, warum ein Angreifer Ethereum angreifen könnte, geht es in den folgenden Abschnitten darum, wie so ein Angriff versucht werden könnte.

Angriffsmethoden

Angriffe auf Layer 0

Erstmal könnten Einzelpersonen, die sich nicht aktiv an Ethereum beteiligen (indem sie Client-Software ausführen) angreifen, indem sie die Sozialebene (Layer 0) ins Visier nehmen. Layer 0 ist das Fundament, auf dem Ethereum aufgebaut ist. Als solches bietet es eine potenzielle Angriffsfläche. Die Konsequenzen aus so einem Angriff hätten Auswirkungen auf den gesamten restlichen Stack. Einige Beispiele hierfür sind:

Eie Falschinformationskampagne könnte das Vertrauen der Community in Ethereums Roadmap, Entwicklerteams, Anwendungen usw. untergraben. Das könnte dann dazu führen, dass sich die Anzahl an Menschen, die dazu bereit sind, bei der Sicherung des Netzwerks zu helfen, stark verringern würde. So eine Entwicklung hätte negative Einflüsse sowohl auf die Dezentralisierung als auch auf die krypto-ökonomische Sicherheit.
Gezielte Angriffe und/oder Einschüchterungsversuche in Richtung der Entwicklercommunity. Dies könnte zum freiwilligen Austritt von Entwicklern führen und Ethereums Fortschritt verlangsamen.
Eine übereifrige Regulierung könnte auch als Angriff auf die Layer 0 interpretiert werden, da sie die Anreize für die Teilnahme und Übernahme massiv verringern könnte.
Eine Infiltration der Entwicklercommunity durch wissende, aber böswillige Akteure mit dem Ziel, den Fortschritt aufzuhalten, und zwar durch Diskussionen über Kleinigkeiten, das Verlangsamen von Schlüsselentscheidungen, Spam usw.
Bestechungsgelder, die an Schlüsselpersonen im Ethereum-Ökosystem gesendet werden, um deren Entscheidungen zu beeinflussen.

Was diese Angriffe besonders gefährlich macht, ist, dass in vielen Fällen sehr wenig Kapital oder technisches Wissen dafür erforderlich ist. Ein Angriff auf Layer 0 könnte ein Multiplikator auf einen krypto-ökonomischen Angriff sein. Wenn es beispielsweise zu Zensur oder einer Endgültigkeitsumkehrung durch einen böswilligen Mehrheits-Stakeholder kommen würde, könnte eine Schwächung der Sozialebene es schwieriger machen, eine Antwort der Community außerhalb des Bandes zu koordinieren.

Eine Verteidigung gegen Angriffe auf Layer 0 ist wahrscheinlich nicht unkompliziert, jedoch lassen sich einige einfachen Prinzipien festlegen. Eines davon ist die Aufrechterhaltung eines hohen Signal-Rausch-Verhältnisses in Bezug auf öffentliche Informationen über Ethereum, die von ehrlichen Mitgliedern der Community in Blogs, auf Discord-Servern, in kommentierten Spezifikationen, Büchern, Podcasts und auf YouTube erstellt und verbreitet werden. Hier auf ethereum.org bemühen wir uns sehr darum, akkurate Informationen zu liefern und diese in möglichst viele Sprachen zu übersetzen. Einen Bereich mit hochqualitativen Informationen und Memes zu überfluten ist eine effektive Verteidigung gegen Falschinformationen.

Eine andere wichtige Verteidigung gegen Angriffe gegen die Sozialebene sind klare Leitlinien und Verwaltungsprotokolle. Ethereum hat sich unter den Smart-Contract-Layer-1-Systemen seine Position als Champion in Bezug auf Dezentralisierung und Sicherheit erkämpft und misst gleichzeitig auch der Skalierbarkeit und Nachhaltigkeit hohen Wert bei. Welche Meinungsverschiedenheiten auch immer in der Ethereum-Community auftreten, diese Grundprinzipien werden nur minimal beeinträchtigt. Die Einschätzung zu einem Narrativ gegen diese Grundprinzipien und eine Prüfung dieser Prinzipien in mehreren Runden im Rahmen des EIP(Ethereum Improvement Proposal)-Prozesses könnte der Community helfen, gute von böswilligen Akteuren zu unterscheiden. Dies schränkt darüber hinaus die Optionen für böswillige Akteuren ein, die zukünftige Richtung von Ethereum zu beeinflussen.

Schließlich ist es von entscheidender Bedeutung, dass die Ethereum-Community offen bleibt und alle Teilnehmer willkommen heißt. Eine von Gatekeepern und Exklusivität geprägte Community ist besonders anfällig für soziale Angriffe, weil es ein Leichtes ist, ein „Wir gegen die anderen“-Narrativ zu etablieren. Tribalismus und toxischer Maximalismus schaden der Community und untergraben die Sicherheit der Layer 0. Ethereaner, die ein berechtigtes Interesse an der Sicherheit des Netzwerks haben, sollten ihr Verhalten online und in der realen Welt als direkten Beitrag zur Sicherheit der Layer 0 auf Ethereum betrachten.

Angriffe auf das Protokoll

Jeder kann die Client-Software von Ethereum ausführen. Um einen Validatoren zu einem Client hinzuzufügen, muss ein Benutzer 32 Ether in den Einzahlungsvertrag überweisen. Ein Validator ermöglicht es einem Benutzer, sich aktiv an der Netzwerksicherheit von Ethereum zu beteiligen, indem er neue Blöcke vorschlägt und diese attestiert. Der Validator hat nun eine Stimme, mit der er den zukünftigen Inhalt der Blockchain beeinflussen kann – er kann dies auf ehrliche Weise tun und seinen Vorrat an Ether durch Belohnungen vergrößern oder er kann versuchen, den Prozess zu seinem eigenen Vorteil zu manipulieren und dabei seinen Stake riskieren. Eine Möglichkeit, einen Angriff zu starten, besteht darin, einen größeren Anteil des Gesamt-Stakes anzuhäufen und diesen dann zu nutzen, um ehrliche Validatoren zu überstimmen. Je größer der Anteil des von den Angreifern kontrollierten Stakes ist, desto größer ist ihr Stimmgewicht, insbesondere bei bestimmten wirtschaftlichen Meilensteinen, auf die wir später noch eingehen werden. Die meisten Angreifer werden jedoch nicht in der Lage sein, genügend Ether anzuhäufen, um auf diese Weise einen Angriff durchzuführen. Stattdessen sind sie auf subtile Techniken angewiesen, mit denen sie die ehrliche Mehrheit so manipulieren, dass sie auf eine bestimmte Weise handelt.

Grundsätzlich handelt es sich bei allen Angriffen mit kleinen Stakes um subtile Variationen zweier Arten von Validator-Fehlverhalten: Unteraktivität (keine oder zu späte Attestierungen/Vorschläge) oder Überaktivität (zu viele Attestierungen/Vorschläge in einem Slot). In ihrer einfachsten Form werden diese Aktionen durch den Abspaltungs-Wahl-Algorithmus und die Anreizebene leicht abgewehrt. Allerdings gibt es clevere Möglichkeiten, das System zum Vorteil eines Angreifers zu manipulieren.

Angriffe mit kleinen ETH-Beträgen

Neuorganisationen

In mehreren Artikeln wurden Angriffe auf Ethereum beschrieben, die Neuorganisationen oder Endgültigkeitsverzögerungen mit nur einem kleinen Teil der insgesamt eingesetzten Ether erreichten. Diese Angriffe beruhen in der Regel darauf, dass der Angreifer anderen Validatoren bestimmte Informationen vorenthält und diese dann auf eine nuancierte Art und/oder zu einem günstigen Zeitpunkt freigibt. 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) hat gezeigt, wie ein angreifender Validator einen Block für einen bestimmten Slot n+1 erstellen und attestieren kann (B), diesen aber nicht an andere Nodes im Netzwerk weitergeben kann. Stattdessen halten sie an diesem attestierten Block bis zum nächsten Slot n+2 fest. 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 dafür zurückgehaltenen Attestierungen freigeben und auch attestieren, dass B die Spitze der Chain ist mit seinen Stimmen für Slot n+2. Damit würde er die Existenz des ehrlichen Blocks C faktisch leugnen. Wenn der ehrliche Block D freigegeben wird, sieht der Abspaltungs-Wahl-Algorithmus, dass D auf B aufbaut, der schwerer ist als D, der auf Caufbaut. Der Angreifer hat es also geschafft, den ehrlichen Block C aus der kanonischen Chain aus Slot n+2 zu entfernen und hat dazu eine 1-Block-Ex-ante-Neuorganisation eingesetzt. Ein Angreifer, der 34 %(opens in a new tab) des Stakes hält, hat eine sehr gute Chance, diesen Angriff erfolgreich durchzuführen, wie in dieser Anmerkung erklärt wird(opens in a new tab). Theoretisch könnte dieser Angriff jedoch auch mit kleineren Stakes unternommen werden. Neuder et al 2020(opens in a new tab) hat beschrieben, wie dieser Angriff mit einem Stake von 30 % funktioniert. Später wurde allerdings gezeigt, dass er auch mit 2 % des Gesamt-Stakes(opens in a new tab) und außerdem mit einem einzelnen Validator(opens in a new tab) erfolgreich war, der Balancing-Techniken anwandte, die wir uns im nächsten Abschnitt genauer ansehen werden.

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

Ein raffinierterer Angriff kann die Reihe ehrlicher Validatoren in getrennte Gruppen aufteilen, die unterschiedliche Ansichten über die Spitze der Chain haben. Dies ist bekannt unter dem Namen Balancing-Angriff. Der Angreifer wartet auf seine Chance, einen Block vorzuschlagen, und wenn diese gekommen ist, wird er mehrdeutig und schlägt zwei vor. Sie senden einen Block an die Hälfte der Reihe aus ehrlichen Validatoren und den anderen Block an die andere Hälfte. Die Mehrdeutigkeit würde vom Abspaltungs-Wahl-Algorithmus erkannt werden und der Block-Proposer würde mit Slashing bestraft und aus dem Netz geworfen werden. Die beiden Blöcke würden hingegen weiterhin existieren, wobei jeweils etwa die Hälfte der Validatoren eine der beiden Abspaltungen attestieren. In der Zwischenzeit halten die übrigen böswilligen Validatoren ihre Attestierungen zurück. Indem sie dann selektiv die Attestierungen, die die eine oder andere Abspaltung begünstigen, genau während der Ausführung des Abspaltungs-Wahl-Algorithmus an gerade genug Validatoren freigeben, kippen sie das kumulierte Gewicht der Attestierungen zugunsten der einen oder anderen Abspaltung. Dies kann auf unbestimmte Zeit fortgesetzt werden, wobei die angreifenden Validatoren eine gleichmäßige Verteilung der Validatoren auf die beiden Abspaltungen beibehalten. Da keine der beiden Abspaltungen eine 2/3-Supermajority auf sich vereinigen kann, würde das Netzwerk nicht finalisiert werden.

Bouncing-Angriffe funktionieren ähnlich. Die Stimmen werden erneut von den angreifenden Validatoren zurückgehalten. Anstatt die Stimmen freizugeben, um eine gleichmäßige Aufteilung zwischen zwei Abspaltungen aufrechtzuerhalten, nutzen sie ihre Stimmen in günstigen Momenten, um Checkpoints zu rechtfertigen, die zwischen Aspaltung A und Abspaltung B alternieren. Dieses Hin- und Herwechseln der Berechtigungen zwischen zwei Abspaltungen verhindert, dass sich Paare berechtigter Quell- und Ziel-Checkpoints bilden, die auf beiden Chains finalisiert werden können, was die Endgültigkeit aufhält.

Sowohl Bouncing- als auch Balancing-Angriffe setzen voraus, dass der Angreifer das Timing der Nachrichten im Netzwerk sehr genau kontrollieren kann, was unwahrscheinlich ist. Dennoch sind Schutzmechanismen in das Protokoll eingebaut, und zwar in Form einer zusätzlichen Gewichtung von prompten Nachrichten gegenüber langsamen Nachrichten. Dies ist bekannt unter dem Namen Proposer-Weight Boosting(opens in a new tab). Um sich gegen Bouncing-Angriffe zu schützen, wurde der Abspaltungs-Wahl-Algorithmus so aktualisiert, dass der letzte berechtigte Checkpoint auf die einer alternativen Chain nur während des ersten Drittels der Slots in jeder Epoche(opens in a new tab) wechseln kann. Diese Bedingung hindert den Angreifer daran, Stimmen zu speichern, um sie später einzusetzen – der Abspaltungs-Wahl-Algorithmus bleibt einfach dem Checkpoint treu, den er im ersten Drittel der Epoche gewählt hat, in der die meisten ehrlichen Validatoren gewählt hätten.

Zusammengenommen führen diese Maßnahmen zu einem Szenario, in dem ein ehrlicher Block-Proposer seinen Block sehr schnell nach dem Beginn des Slots überträgt, woraufhin eine Zeitspanne von ~1/3 eines Slots (4 Sekunden) folgt, während der dieser neue Block den Abspaltungs-Wahl-Algorithmus veranlassen könnte, zu einer anderen Chain zu wechseln. Nach Ablauf dieser Frist werden Attestierungen, die von langsamen Validatoren eingehen, im Vergleich zu den früher eingegangenen Attestierungen niedriger gewichtet. Dies begünstigt schnelle Antragsteller und Validatoren bei der Bestimmung Spitze der Chain und verringert die Wahrscheinlichkeit eines erfolgreichen Balancing- oder Bouncing-Angriffs erheblich.

Es ist erwähnenswert, dass das Proposer-Boosting allein nur gegen „billige Neuorganisationen“ schützt, d. h. gegen solche, die von einem Angreifer mit einem kleinen Stake versucht werden. Das „Proposer-Boosting“ selbst kann von größeren Stakeholdern manipuliert werden. Die Autoren von diesem Beitrag(opens in a new tab) beschreiben, wie ein Angreifer mit 7 % des Stakes seine Stimmen strategisch so einsetzen kann, dass er ehrliche Validatoren dazu bringt, auf ihrer Abspaltung aufzubauen und durch Neuorganisation einen ehrlichen Block aus dem Rennen zu nehmen. Dieser Angriff wurde unter der Annahme idealer Latenzbedingungen entwickelt, die sehr unwahrscheinlich sind. Die Chancen für den Angreifer sind nach wie vor sehr gering und der größere Stake bedeutet auch ein höheres Kapitalrisiko und eine stärkere wirtschaftliche Abschreckung.

Ein Balancing-Angriff, der speziell auf die LMD-Regel abzielt(opens in a new tab), wurde ebenfalls vorgeschlagen. Es wurde vermutet, dass so ein Angriff trotz Proposer Boosting Erfolg haben könnte. Ein Angreifer richtet zwei konkurrierende Chains ein, indem er dafür sorgt, dass ihr Block-Proposal mehrdeutig wird. Außerdem propagiert er jeden Block an etwa jeweils die Hälfte des Netzwerks, wodurch ein ungefähres Gleichgewicht zwischen den Abspaltungen hergestellt wird. Dann geben die betrügerischen Validatoren ihre Stimmen mehrdeutig ab und legen den Zeitpunkt so fest, dass die Hälfte des Netzes zuerst ihre Stimmen für Abspaltung A erhält und die andere Hälfte zuerst ihre Stimmen für Abspaltung B erhält. Da die LMD-Regel die zweite Attestierung verwirft und nur die erste Attestierung für jeden Validator aufrechterhä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“ dazu verleiht, einen Balancing-Angriff zu starten.

Dieser LMD-Angriffsvektor wurde geschlossen, indem der Abspaltungs-Wahl-Algorithmus(opens in a new tab) so aktualisiert wurde, dass mehrdeutige Validatoren bei der Abspaltungs-Wahl überhaupt nicht berücksichtigt werden. Bei mehrdeutigen Validatoren wird ihr zukünftiger Einfluss durch den Abspaltungs-Wahl-Algorithmus ebenfalls abgewertet. Dadurch wird der oben beschriebene Balancing-Angriff verhindert und gleichzeitig die Widerstandsfähigkeit gegen Lawinenangriffe aufrechterhalten.

Eine andere Klasse von Angriffen, genannt Lawinenangriffe(opens in a new tab), wurde in einem Artikel aus dem März 2022(opens in a new tab) beschrieben. Um einen Lawinenangriff durchzuführen, muss der Angreifer mehrere aufeinanderfolgende Block-Proposer kontrollieren. In jedem der Block-Proposal-Slots hält der Angreifer seinen Block zurück und sammelt Blöcke, bis die ehrliche Chain ein Gleichgewicht des Subtrees mit den zurückgehaltenen Blöcken erreicht. Dann werden die zurückgehaltenen Blöcke freigegeben, sodass sie für maximale Mehrdeutigkeit sorgen. Die Autoren legen nahe, dass Proposer Boosting – die primäre Verteidigung gegen Balancing- und Bouncing-Angriffe – nicht vor einigen Varianten von Lawinenangriffen schützt. Allerdings demonstrierten die Autoren den Angriff auch nur an einer stark idealisierten Version des Abspaltungs-Wahl-Algorithmus auf Ethereum (sie verwendeten GHOST ohne LMD).

Der Lawinenangriff wird durch den LMD-Teil des LMD-GHOST-Abspaltungs-Wahl-Algorithmus abgeschwächt. LMD bedeutet „latest-message-driven“ und bezieht sich auf eine Tabelle, die von jedem Validator geführt wird und die die letzte von anderen Validatoren erhaltene Nachricht enthält. Dieses Feld wird nur dann aktualisiert, wenn die neue Nachricht von einem späteren Slot stammt als die bereits in der Tabelle für einen bestimmten Validator enthaltene Nachricht. In der Praxis bedeutet dies, dass in jedem Slot die erste empfangene Nachricht diejenige ist, die akzeptiert wurde, und dass alle weiteren Nachrichten zu ignorierende Mehrdeutigkeiten sind. Anders ausgedrückt: Die Konsens-Clients zählen keine Mehrdeutigkeiten – sie verwenden die zuerst eintreffende Nachricht von jedem Validator und Mehrdeutigkeiten werden einfach verworfen, um Lawinenangriffe zu verhindern.

Es gibt mehrere andere mögliche Upgrades für die Abspaltungs-Wahl-Regel, die in Zukunft die Sicherheit durch Proposer Boost erhöhen könnten. Eines davon ist View-Merge(opens in a new tab), wobei die Attestierer ihre Sicht auf die Abspaltungs-Wahl n Sekunden vor Beginn eines Slots einfrieren und der Proposer dann dabei hilft, die Sicht auf die Chain im gesamten Netzwerk zu synchronisieren. Ein weiteres mögliches Upgrade ist die Einzelplatzendgültigkeit(opens in a new tab), die vor Angriffen auf Basis des Timings von Nachrichten schützt, indem sie die Chain nach nur einem Slot finalisiert.

Endgültigkeitsverzögerung

Im selben Artikel(opens in a new tab), der zuerst den kostengünstigen Angriff auf die Neuorganisation eines einzelnen Blocks beschrieben hatte, wurde auch ein Angriff mit Endgültigkeitsverzögerung (auch bekannt als „Livesness-Versagen“) beschrieben, der sich darauf stützt, dass der Angreifer der Block-Proposer für einen Block an der Epochengrenze ist. Dies ist von entscheidender Bedeutung, da diese Blöcke an der Epochengrenze zu den Checkpoints werden, die Casper FFG verwendet, um Teile der Chain zu finalisieren. Der Angreifer hält seinen Block einfach so lange zurück, bis genügend ehrliche Validatoren ihre FFG-Stimmen zugunsten des vorherigen Blocks an der Epochengrenze als aktuelles Finalisierungsziel einsetzen. Dann geben sie ihren zurückgehaltenen Block frei. Sie attestieren für ihren Block und die übrigen ehrlichen Validatoren tun dies ebenfalls, wodurch Abspaltungen mit unterschiedlichen Ziel-Checkpoints kreiert werden. Wenn sie es genau richtig timen, verhindern sie die Endgültigkeit, weil es keine 2/3-Supermajority gibt, die für eine der beiden Abspaltungen attestiert. Je kleiner der Stake ist, desto präziser muss das Timing sein, da der Angreifer weniger Attestierungen direkt kontrolliert, und desto geringer ist die Wahrscheinlichkeit, dass der Angreifer den Validator kontrolliert, der einen bestimmten Block an der Epochengrenze vorschlägt.

Langstreckenangriffe

Es gibt auch eine Angriffsklasse, die spezifisch für Proof-of-Stake-Blockchains ist, bei der ein Validator, der am Genesis-Block beteiligt war, eine separate Abspaltung der Blockchain neben der ehrlichen aufrechterhält. Schließlich überzeugt dieser die Reihe ehrlicher Validator davon, viel später zu einem günstigen Zeitpunk zu dieser Abspaltung zu wechseln. Diese Art von Angriff ist bei Ethereum nicht möglich, da das Endgültigkeits-Gadget sicherstellt, dass sich alle Validatoren in regelmäßigen Abständen („Checkpoints“) über den Zustand der ehrlichen Chain einig sind. Dieser einfache Mechanismus neutralisiert Langstreckenangriffe, da Ethereum-Clients finalisierte Blöcke einfach nicht neu organisieren. Neue Nodes, die dem Netzwerk beitreten, tun dies, indem sie einen vertrauenswürdigen aktuellen Zustands-Hash finden (einen „Checkpoint schwacher(opens in a new tab) Subjektivität“) und ihn als Pseudo-Genesis-Block verwenden, auf dem aufgebaut werden kann. Dadurch wird für einen neuen Node, der in das Netzwerk eintritt, ein „Vertrauens-Gateway“ geschaffen, bevor er damit beginnen kann, Informationen für sich selbst zu verifizieren.

Denial of Service

Der PoS-Mechanismus von Ethereum wählt in jedem Slot einen einzelnen Validator aus der Gesamtmenge der Validatoren aus, der als Block-Proposer fungiert. Diese kann mit Hilfe einer öffentlich bekannten Funktion berechnet werden und es ist möglich, dass ein Angreifer den nächsten Block-Proposer kurze Zeit vor seinem Block-Proposal identifiziert. Dann kann der Angreifer den Block-Proposer mit Spam-Mails bombardieren, um ihn daran zu hindern, Informationen mit seinen Peers auszutauschen. Für den Rest des Netzwerkes würde es so aussehen, als wäre der Block-Proposer offline und als würde der Slot einfach leer werden. Dies könnte als eine Form der Zensur gegen bestimmte Validatoren eingesetzt werden, die so daran gehindert werden, Informationen zur Blockchain hinzuzufügen. Durch die Implementierung von Single Secret Leader Elections (SSLE) oder Non Single Secret Leader Elections wird das DoS-Risiko gemindert, da nur derjenige, der den Block vorschlägt, weiß, dass er ausgewählt wurde und die Auswahl nicht im Voraus bekannt ist. Dies wurde noch nicht implementiert, ist 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. Für die hier beschriebenen realisierbaren Angriffe sind ein idealisierter Abspaltungs-Wahl-Algorithmus oder unwahrscheinliche Netzwerkbedingungen erforderlich oder die Angriffsvektoren wurden bereits mit relativ kleinen Patches für die Client-Software geschlossen. Dies schließt natürlich nicht aus, dass irgendwo dort draußen Zero-Days existieren. Allerdings zeigt es, wie hoch die Messlatte für technisches Geschick, Wissen über die Konsensebene und Glück liegt, damit ein Angreifer mit einem Minderheits-Stake erfolgreich sein kann. Aus der Sicht eines Angreifers wäre es am besten, so viel Ether wie möglich zu sammeln und, ausgestattet mit einem größeren Anteil des Gesamt-Stakes, zurückzukehren.

Angreifer, die >= 33 % des gesamten Stakes nutzen

Alle in diesem Artikel erwähnten Angriffe werden wahrscheinlicher, wenn der Angreifer über mehr eingesetzte Ether verfügt, mit denen er abstimmen kann, und über mehr Validatoren, die ausgewählt werden können, um Blöcke in jedem Slot vorzuschlagen. Ein böswilliger Validator könnte dadurch versuchen, so viele eingesetzte Ether wie möglich zu kontrollieren.

33 % des eingesetzten Ethers ist ein Richtwert für einen Angreifer, da er bei jedem höheren Betrag 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 auf böswillige Weise attestieren oder gar nicht attestieren, kann keine 2/3-Supermajority existieren und die Chain kann nicht finalisiert werden. Die Verteidigung dagegen ist das Inactivity Leak. Das Inactivity Leak identifiziert diejenigen Validatoren, die nicht attestieren oder widersprüchlich zur Mehrheit attestieren. Die eingesetzten Ether, die sich im Besitz dieser nicht attestierenden Validatoren befinden, werden nach und nach abgezogen, bis sie schließlich zusammengenommen weniger als 1/3 der Gesamtmenge ausmachen, sodass die Chain wieder finalisiert werden kann.

Der Zweck dieses Inactivity Leak ist es, dafür zu sorgen, dass die Kette wieder finalisiert werden kann. Jedoch verliert der Angreifer auch einen Teil seiner eingesetzten Ether. Anhaltende Inaktivität bei Validatoren, die 33 % der insgesamt eingesetzten Ether repräsentieren, ist sehr teuer, auch wenn die Validatoren nicht mit 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 Stakes kontrolliert, eine doppelte Endgültigkeit herbeiführen. Der Grund dafür ist, dass der Angreifer, wenn er als Block-Producer ausgewählt wird, für Mehrdeutigkeit sorgen und dann doppelt mit all seinen Validatoren abstimmen kann. Das erzeugt eine Situation, in der eine Abspaltung in der Blockchain existiert, für die jeweils 34 % der eingesetzten Ether abstimmen. Für jede Abspaltung müssten nur 50 % der übrigen Validatoren stimmen, damit beide Abspaltungen von einer Supermajority unterstützt werden. In diesem Fall können beide Chains finalisiert werden (weil 34 % der Angreifervalidatoren + die Hälfte der verbleibenden 66 % = 67 % für jede Abspaltung). 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 über das Netzwerk propagierten Nachrichten hat, sodass er dafür sorgen kann, dass die Hälfte der ehrlichen Validatoren auf jede Chain gelangen. 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 Slashing und der maximalen Korrelationsstrafe geahndet wird. Die Verteidigung gegen diesen Angriff sind die sehr großen Kosten für das Zerstören von 34 % der insgesamt eingesetzten Ether. Um sich von diesem Angriff zu erholen, müsste sich die Ethereum-Community „außerhalb des Bands“ koordinieren und sich auf das Folgen einer Abspaltung einigen und die andere Abspaltung ignorieren.

Angreifer, die ~50 % des gesamten Stakes nutzen

Mit 50 % des eingesetzten Ethers könnte eine böswillige Gruppe von Validatoren die Chain theoretisch in zwei gleich große Abspaltungen aufteilen und dann einfach ihren gesamten Stake von 50 % einsetzen, um gegensätzlich zum ehrlichen Validatoren-Set abzustimmen, was die beiden Abspaltungen aufrechterhalten und die Endgültigkeit verhindern würde. Das Inactivity Leak auf beiden Abspaltungen würde letztendlich dazu führen, dass beide Chains finalisiert werden. An diesem Punkt bleibt als einzige Option ein Rückgriff auf die soziale Wiederherstellung.

Es ist sehr unwahrscheinlich, dass eine böswillige Gruppe von Validatoren durchgängig genau 50 % des Gesamt-Stakes kontrollieren könnte, da die Zahl der ehrlichen Validatoren und die Netzwerklatenz usw. stark schwanken. Die enormen Kosten eines solchen Angriffs in Verbindung mit der geringen Erfolgswahrscheinlichkeit sollten für rationale Angreifer eine starke Abschreckung darstellen; vor allem, da eine kleine zusätzliche Investition, um mehr als 50 % zu erhalten, ihnen viel mehr Möglichkeiten eröffnet.

Bei >50 % des gesamten Stakes könnte der Angreifer den Abspaltungs-Wahl-Alogrithmus dominieren. In diesem Fall wäre der Angreifer in der Lage, mit der Mehrheit der Stimmen zu attestieren, was ihm genügend Kontrolle gibt, um kurze Neuorganisationen durchzuführen, ohne dass er ehrliche Clients täuschen muss. Die ehrlichen Validatoren würden es ihm gleichtun, da ihr Abspaltungs-Wahl-Algorithmus auch seine bevorzugte Chain als die schwerste ansehen würde, sodass die Chain finalisiert werden könnte. Dies ermöglicht es dem Angreifer, bestimmte Transaktionen zu zensieren, Kurzstrecken-Neuorganisationen vorzunehmen und die maximale Anzahl an MEV zu extrahieren, indem Blöcke nach Belieben neu angeordnet werden. Die Verteidigung dagegen sind die enormen Kosten eines Mehrheits-Stakes (derzeit knapp 19 Mrd. USD), die ein Angreifer aufs Spiel setzen würde, weil die Sozialebene wahrscheinlich eingreifen und eine ehrliche Minderheits-Abspaltung übernehmen würde, wodurch der Stake des Angreifers dramatisch abgewertet würde.

Angreifer, die >= 66 % des gesamten Stakes nutzen

Ein Angreifer, der 66 % oder mehr der insgesamt eingesetzten Ether besitzt, kann seine bevorzugte Chain finalisieren, ohne ehrliche Validatoren zu etwas zwingen zu müssen. Der Angreifer kann einfach für seine bevorzugte Chain abstimmen und sie dann finalisieren, schlichtweg weil er mit einer unehrlichen Supermajority abstimmen kann. Als Stakeholder mit Supermajority könnte der Angreifer immer die Inhalte der finalisierten Blöcke bestimmen. Er könnte nach Belieben Ausgaben tätigen, diese zurücknehmen und dann erneut tätigen, bestimmte Transaktionen zensieren oder die Chain neu organisieren. Wenn der Angreifer zusätzliche Ether kauft, sodass er 66 % statt 51 % des gesamten Stakes kontrolliert, erwirbt er im Endeffekt die Fähigkeit, rückwirkende Neuorganisationen und Endgültigkeitsumkehrungen durchzuführen (d. h. die Vergangenheit zu verändern und die Zukunft zu kontrollieren). Die einzige echte Verteidigung hier sind die enormen Kosten von 66 % des gesamten Ether-Stakes und die Option, auf die Sozialebene zurückzugreifen, wo sich die Übernahme einer alternativen Abspaltung koordinieren lässt. Wir können uns diesen Vorgang im nächsten Abschnitt detaillierter ansehen.

Menschen: die letzte Verteidigungslinie

Wenn es unehrlichen Validatoren gelingt, ihre präferierte Version der Chain zu finalisieren, gerät die Ethereum-Community in eine schwierige Lage. Die kanonische Chain beinhaltet dann einen „unehrlichen“ Abschnitt, der in die Historie aufgenommen wurde, wohingegen ehrliche Validatoren dafür bestraft werden können, für eine alternative („ehrliche“) Chain abzustimmen. Dabei ist zu beachten, dass eine finalisierte, aber inkorrekte Chain auch das Ergebnis eines Fehlers im Mehrheits-Client sein könnte. Letztendlich ist es der ultimative Fallback, sich zur Lösung der Situation auf die Sozialebene – Layer 0 – zu verlassen.

Eine der Stärken des PoS-Konsens auf Ethereum ist es, dass es eine Reihe von Verteidigungsstrategien(opens in a new tab) gibt, auf die die Community zurückgreifen kann, sollte es zu einem Angriff kommen. Eine minimale Reaktion könnte darin bestehen, die Validatoren der Angreifer zwangsweise aus dem Netzwerk zu entfernen, ohne zusätzliche Strafen zu verhängen. Um dem Netzwerk wieder beitreten zu können, müsste ein Angreifer Teil einer Aktivierungswarteschlange werden, mit der sichergestellt wird, dass das Validatoren-Set allmählich größer wird. So dauert es zum Beispiel etwa 200 Tage, bis genügend Validatoren hinzukommen, um die Menge an eingesetztem Ether zu verdoppeln. Dies bedeutet, dass die ehrlichen Validatoren im Grunde 200 Tage Zeit haben, bevor der Angreifer einen weiteren 51 %-Angriff starten kann. Jedoch könnte sich die Community auch dazu entscheiden, den Angreifer härter zu bestrafen. Das könnte durch den Widerruf vergangener Belohnungen oder das Zerstören eines Anteils (bis zu 100 %) ihres eingesetzten Kapitals geschehen.

Unabhängig von der Strafe, die dem Angreifer auferlegt wird, muss die Community auch gemeinsam nicht nur entscheiden, ob die unehrliche Chain tatsächlich ungültig ist (obwohl es sich bei ihr um die vom Abspaltungs-Wahl-Algorithmus, der in den Ethereum-Client kodiert ist, bevorzugte handelt), sondern auch, dass die Community stattdessen auf der ehrlichen Chain aufbauen sollte. Ehrliche Validatoren könnten sich gemeinsam darauf einigen, auf einer von der Community akzeptierten Abspaltung der Ethereum-Blockchain aufzubauen, die beispielsweise vor Beginn des Angriffs von der kanonischen Chain abgezweigt wurde. Alternativ vereinbaren die Validatoren, die Validatoren der Angreifer zwangsweise zu entfernen. Ehrliche Validierer hätten einen Anreiz dafür, auf dieser Chain aufzubauen, weil sie die Strafen vermeiden würden, die ihnen auferlegt werden, weil sie die Chain des Angreifers (gerechtfertigterweise) nicht attestieren. Börsen, On-Ramps und Anwendungen, die auf Ethereum aufbauen, würden es vermutlich vorziehen, auf der ehrlichen Chain zu sein und würden den ehrlichen Validatoren auf die ehrliche Blockchain folgen.

Jedoch wäre dies eine große verwaltungstechnische Herausforderung. Einigen Benutzern und Validatoren würden durch die Umstellung auf die ehrliche Chain zweifellos Nachteile entstehen und Transaktionen in Blöcken, die nach dem Angriff validiert wurden, könnten möglicherweise rückgängig gemacht werden, was zu Störungen auf der Anwendungsebene führen würde. Außerdem untergräbt eine solche Umstellung ganz einfach die Ethik einiger Benutzer, die dazu neigen, zu glauben, dass „Code Gesetz ist“. Börsen und Anwendungen würden höchstwahrscheinlich Off-Chain-Aktionen mit On-Chain-Transaktionen verknüpft haben, was nun möglicherweise rückgängig gemacht werden würde. Dies würde eine Kaskade von Widerrufen und Revisionen in Gang setzen, die nur schwer auf faire Weise zunichtegemacht werden könnten, insbesondere dann, wenn unehrlich erzielte Gewinne durchmischt oder in DeFi oder andere Derivate mit sekundären Auswirkungen für ehrliche Nutzer eingezahlt worden wären. Zweifellos hätten einige Benutzer, vielleicht sogar institutionelle, bereits von der unehrlichen Chain profitiert, entweder durch arglistiges Verhalten oder durch Zufall, und könnten sich gegen eine Abspaltung stellen, um ihre Gewinne zu bewahren. Es gab bereits Aufrufe dazu, die Community-Antwort auf >51 %-Angriffe zu proben, sodass vernünftige, koordinierte Mitigationsmaßnahmen schnell ausgeführt werden können. Es gibt auf ethresear.ch hier(opens in a new tab) und hier(opens in a new tab) und auf Twitter hier(opens in a new tab) einige nützliche Diskussionen von Vitalik. Das Ziel einer koordinierten sozialen Antwort sollte es sein, sehr zielgerichtet vorzugehen, den Angreifer spezifisch zu bestrafen sowie die Auswirkungen für andere Nutzer gering zu halten.

Die Verwaltung ist bereits ein kompliziertes Thema. Die Koordinierung einer Layer-0-Notfallantwort auf eine unehrlich finalisierende Chain wäre zweifellos eine Herausforderung für die Ethereum-Community. Jedoch kam es bereits - zweimal in der Geschichte Ethereums dazu.

Nichtsdestotrotz liegt eine gewisse Befriedigung in der Tatsache, dass der letzte Fallback in der realen Welt angesiedelt ist. Selbst mit dieser phänomenalen Technologie, die uns zur Verfügung steht, müssten sich die Menschen am Ende des Tages koordinieren und gemeinsam einen Ausweg suchen, sollte der schlimmste Fall eintreten.

Zusammenfassung

Auf dieser Seite wurden einige der Möglichkeiten untersucht, wie Angreifer versuchen könnten, Schwächen im Proof-of-Stake-Konsensprotokoll von Ethereum auszunutzen. Neuorganisationen und Endgültigkeitsverzögerungen wurden für verschiedene Angreifer untersucht, die über steigende Anteile des gesamten eingesetzten Ethers verfügen. Insgesamt hat ein vermögenderer Angreifer mehr Chancen auf Erfolg, da sich sein Stake in Stimmrecht niederschlägt, mit dem er den Inhalt künftiger Blöcke beeinflussen kann. Ab bestimmten Schwellenwerten an eingesetztem Ether steigt die Macht eines Angreifers:

33 %: Endgültigkeitsverzögerung

34 %: Endgültigkeitsverzögerung, doppelte Endgültigkeit

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

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

Es gibt auch eine Reihe hoch entwickelter Angriffe, für die nur geringe Mengen an eingesetztem Ether erforderlich sind, die aber darauf beruhen, dass ein sehr raffinierter Angreifer das Timing von Nachrichten genau kontrolliert und damit die ehrlichen Validatoren zu seinen Gunsten beeinflusst.

Insgesamt ist das Risiko eines erfolgreichen Angriffs trotz dieser potenziellen Angriffsvektoren gering, sicherlich geringer als bei Proof-of-Work-Äquivalenten. Der Grund dafür sind die enormen Kosten der eingesetzten Ether, die ein Angreifer aufs Spiel setzen würde, wenn er versuchen würde, die ehrlichen Validatoren mit seiner Stimmabgabe zu überwältigen. Die eingebaute Anreizebene nach dem Prinzip „Zuckerbrot und Peitsche“ schützt gegen die meisten Arten von Vergehen, besonders bei Angreifern, die einen geringen Stake einsetzen. Auch für subtilere Bouncing- und Balancing-Angriffe bestehen geringe Erfolgsaussichten, weil unter realen Netzwerkbedingungen die Feinsteuerung der Nachrichtenzustellung an bestimmte Untergruppen von Validatoren sehr schwierig ist. Darüber hinaus haben Client-Teams die bekannten Bouncing-, Balancing- und Lawinen-Angriffsvektoren mit einfachen Patches schnell geschlossen.

34 %-, 51 %- oder 66 %-Angriffe würden wahrscheinlich eine soziale Koordination außerhalb des Bands erfordern, um mit ihnen fertig zu werden. Auch wenn dies für die Community wahrscheinlich schmerzhaft wäre, wirkt die Möglichkeit, dass die Community außerhalb des Bands reagiert, für Angreifer wie eine starke Abschreckung. Die soziale Ebene von Ethereum ist der ultimative Rückhalt – ein technisch erfolgreicher Angriff könnte immer noch aufgehalten werden, wenn sich die Community darauf einigt, eine ehrliche Abspaltung zu übernehmen. Es käme zu einem Wettlauf zwischen dem Angreifer und der Ethereum-Community. Die Milliarden von US-Dollar, die für einen 66 %-Angriff ausgegeben wurden, würden wahrscheinlich durch einen erfolgreichen Angriff auf Basis sozialer Koordinierung ausgelöscht, sollte dieser schnell genug durchgeführt werden. Dies würde dazu führen, dass der Angreifer mit schweren Taschen voller illiquider Ether auf einer bekanntermaßen unehrlichen Chain zurückbleibt, die von der Ethereum-Community ignoriert wird. Die Wahrscheinlichkeit, dass dies letztendlich für einen Angreifer profitabel ist, ist so gering, dass es eine wirksame Abschreckung darstellt. Aus diesem Grund sind Investitionen in die Aufrechterhaltung einer kohäsiven sozialen Ebene mit eng aufeinander abgestimmten Werten so wichtig.