Übersicht der Sicherheitsherausforderungen

Ein bestimmendes Merkmal von Blockchains ist die atomare Natur von Transaktionen: Sobald eine Aktualisierung in der Blockchain aufgezeichnet ist, gibt es keine Möglichkeit mehr für Eingriffe oder Rückabwicklungen. Dies bietet starke Garantien für Konsistenz und Sicherheit auf Protokollebene, setzt die Nutzer jedoch einem erhöhten operativen Risiko aus: Ein einziger Fehler, ein kompromittierter Schlüssel oder eine übereilte Genehmigung kann zu irreversiblen Verlusten führen.

Infolgedessen fällt eine erhebliche Sicherheitslast auf den Nutzer. Um Ethereum sicher zu nutzen, müssen Einzelpersonen und Organisationen Schlüssel sicher aufbewahren und verwalten, mit Onchain-Anwendungen interagieren und ihre Schlüssel verwenden, um Transaktionen zu signieren, um Vermögenswerte zu transferieren oder anderweitig den Zustand von Ethereum zu aktualisieren.

Jede dieser Anforderungen birgt Risiken wie die Kompromittierung oder den Verlust von Schlüsseln, übereilte oder uninformierte Genehmigungen oder die Kompromittierung der Wallet-Software, auf die sich Nutzer verlassen, um sie bei der Interaktion mit Ethereum zu informieren und anzuleiten.

1.1 Schlüsselverwaltung

Viele Nutzer sind nicht dafür gerüstet, kryptographische Schlüssel sicher zu verwalten.

Die meisten weit verbreiteten Software-Wallets verlassen sich darauf, dass Nutzer Seed-Phrasen sicher speichern, die ihren zugrunde liegenden kryptographischen privaten Schlüssel repräsentieren, was oft dazu führt, dass sie unsichere Notlösungen verwenden, wie das Speichern von Seed-Phrasen im Klartext, in Cloud-Diensten oder das Aufschreiben auf Papier.

Hardware-Wallets sind eine Alternative, die es Nutzern ermöglichen, einen kryptographischen Schlüssel zu verwalten, der in einem speziellen physischen Gerät gespeichert ist. Hardware-Wallets haben jedoch ihre eigenen Schwachstellen und Angriffsflächen. Hardware-Wallets können verloren gehen, beschädigt oder gestohlen werden. Viele Hardware-Wallets sind nicht Open Source und können undurchsichtige Lieferketten aufweisen, was das Risiko eines Lieferkettenangriffs erhöht, bei dem kompromittierte Geräte auf den Markt gebracht werden.

Unabhängig davon, ob Schlüssel in einer Software- oder Hardware-Wallet verwaltet werden, sind viele Nutzer verständlicherweise nervös in Bezug auf die Eigenverwahrung, wenn diese durch physischen Diebstahl oder Überfälle kompromittiert werden kann.

Unternehmens- und institutionelle Nutzer stehen bei der Schlüsselverwaltung vor zusätzlichen Herausforderungen. Wenn einzelne Mitarbeiter Schlüssel halten (z. B. als Teil einer Multisig-Wallet), muss die Organisation in der Lage sein, diese zu ersetzen und aufgrund von personellen Veränderungen im Laufe der Zeit neue zu erstellen. Compliance-Anforderungen in verschiedenen Branchen und Gerichtsbarkeiten können benutzerdefinierte Workflows oder Audit-Trails erfordern, die von bestehender Wallet-Software nicht unterstützt werden. In einigen Fällen wenden sich Unternehmensnutzer für digitale Vermögenswerte an Drittverwahrer, was eine weitere Ebene von Sicherheitsrisiken mit sich bringen kann, die es zu berücksichtigen gilt.

1.2 Blindes Signieren & Transaktionsunsicherheit

Nutzer genehmigen Transaktionen routinemäßig „blind“, ohne zu verstehen, was sie tun. Wallets präsentieren oft rohe hexadezimale Daten, abgeschnittene Vertragsadressen oder andere Informationen, die für den Nutzer nicht ausreichen, um die Konsequenzen einer bestimmten Transaktion zu verstehen. Dies macht Nutzer aller Art anfällig für bösartige Smart Contracts, Phishing, Betrug, gefälschte Schnittstellen, Frontend-Kompromittierungen und grundlegende Benutzerfehler.

1.3 Genehmigungs- und Berechtigungsverwaltung

In vielen Ethereum-Anwendungen ist es üblich, dass Nutzer der zugrunde liegenden Anwendung im Rahmen der normalen Nutzung bestimmte Berechtigungen erteilen. Beispielsweise könnte ein Nutzer einer dezentralen Börse wie Uniswap die Erlaubnis erteilen, seine Token zu bewegen, um sie gegen ETH zu tauschen.

Diese Genehmigungen können Mengenbegrenzungen haben, aber viele Wallets erteilen standardmäßig unbegrenzte Genehmigungen ohne Ablaufdatum. Für Nutzer gibt es in den meisten Wallets keine Möglichkeit, ihre ausstehenden Genehmigungen zu verwalten oder zu überprüfen.

Dies kann Nutzer bösartigen Apps oder kompromittierten Frontends aussetzen, da das Standardmuster für viele Nutzer darin besteht, unbegrenzte Genehmigungen zu erteilen, die dazu verwendet werden können, ihre Gelder abzuziehen. Selbst wenn ein Nutzer einem legitimen Smart Contract eine Genehmigung erteilt, könnte der kompromittierte Vertrag, falls dieser Vertrag später kompromittiert wird, während die Genehmigung bestehen bleibt, die Gelder des Nutzers abziehen.

Dies ist gleichermaßen ein Risiko für organisatorische Nutzer. Beispielsweise könnte sich eine Organisation aus operativen Gründen dafür entscheiden, einem DEX-Router einen unbegrenzten USDC-Freigabebetrag zu gewähren, was sie dann Risiken aussetzt, wenn der Router-Vertrag aktualisiert wird.

1.4 Kompromittierte Web-Schnittstellen

Die meisten Nutzer interagieren nicht direkt mit einem Smart Contract, sondern über eine Web-Schnittstelle via Mobilgerät oder Webbrowser.

Diese Frontends können durch bekannte Methoden wie DNS-Hijacking, bösartige JavaScript-Injektion, unsicheres Hosting oder verschiedene Abhängigkeiten von Drittanbietern anfällig für Angriffe sein. Eine kompromittierte App-UX kann Nutzer aller Art zu bösartigen Smart Contracts umleiten oder sie dazu verleiten, irreführende Transaktionen zu signieren.

1.5 Privatsphäre

Privatsphäre kann Sicherheitsrisiken für Nutzer aller Art mindern oder vergrößern.

Schwächere Privatsphäre-Schutzmaßnahmen setzen einzelne Nutzer einer Vielzahl gezielter Bedrohungen wie Phishing, Ausbeutung, Betrug oder physischen Angriffen aus. Viele gängige UX-Muster entblößen Nutzer, z. B. durch die Wiederverwendung von Adressen, KYC-Daten und andere Lecks von Metadaten.

Für Institutionen und Unternehmen ist Privatsphäre aus Compliance-Gründen oder für bestimmte Anwendungsfälle oft eine grundlegende geschäftliche Anforderung. Zusätzlich zu diesen Problemen kann sie zu spezifischen Sicherheitsrisiken führen. Beispielsweise kann ein Nutzer eines auf Ethereum basierenden Lieferkettensystems starke Privatsphäre-Garantien benötigen, um geistiges Eigentum zu schützen, das kompromittiert werden könnte, wenn das System transparent wäre.

1.6 Fragmentierung

Es mangelt an Konsistenz darin, wie verschiedene Wallets Kernverhalten wie die Anzeige von Transaktionen, die Handhabung von Genehmigungen oder die Kennzeichnung von Verträgen handhaben. Diese Fragmentierung der Benutzererfahrung erschwert es dem Nutzer zu lernen, wie man Wallets sicher verwendet, und erhöht die Risiken.

Beispielsweise können sich Nutzer nicht auf konsistente UX-Hinweise verlassen, um sich vor Phishing und Spoofing zu schützen, da diese sich von Wallet zu Wallet unterscheiden. Nutzer können keine verlässlichen Erwartungen darüber bilden, wie Ethereum funktioniert, wenn jedes Tool anders funktioniert.

Die Smart-Contract-Sicherheit hat sich im Laufe der Geschichte von Ethereum radikal verbessert. Frühe Sicherheitsvorfälle wie der DAO-Hack motivierten das Ökosystem, sich zu professionalisieren und die Schutzmaßnahmen über den gesamten Software-Lebenszyklus hinweg zu verbessern, der dazu führt, dass Code onchain bereitgestellt wird. Zu den wichtigsten Fortschritten gehören:

• Sicherheitsaudits wurden zur Standardpraxis, wobei mehrere Sicherheitsfirmen in das Ökosystem eintraten und Fachwissen entwickelten.
• Tools, Tests und statische Analysesysteme reiften heran und wurden zur Standardpraxis.
• Bibliotheken mit vorab geprüften gemeinsamen Komponenten gaben Entwicklern standardmäßig sichere Bausteine.
• Formale Verifikationstechniken wurden übernommen, insbesondere für Brücken, Staking-Systeme und hochwertige Verträge.
• Die Sicherheitskultur und die Best Practices des Ökosystems haben sich verbessert.
• Die Schaffung bedeutender Bounty-Programme, die die App-Ebene gehärtet haben.

Es gibt jedoch weiterhin Schwachstellen und Verbesserungsbereiche in diesem Bereich.

2.1 Vertrags-Schwachstellen

Trotz der Fortschritte in der Smart-Contract-Sicherheit gibt es immer noch Schwachstellen, die zu erheblichen Sicherheitsproblemen führen können, darunter:

• Risiko von Vertrags-Upgrades. Einige Verträge sind so konzipiert, dass sie nach der Bereitstellung modifizierbar sind, um es einem Entwicklungsteam zu ermöglichen, eine Anwendung weiterhin zu aktualisieren und zu verbessern. Dies birgt jedoch Risiken. Upgrades könnten zu neuen Schwachstellen oder im Falle eines bösartigen Upgrades zum Totalverlust von Nutzergeldern führen.
• Re-Entrancy, wobei Vertrag A einen externen Vertrag B aufruft, bevor er seinen eigenen internen Zustand aktualisiert, und Vertrag B den ursprünglichen Vertrag A zurückruft, bevor der erste Aufruf beendet ist.
• Unsichere Nutzung externer Bibliotheken, wobei ein Vertrag eine externe Bibliothek aufruft, die möglicherweise ungeprüft, bösartig oder aktualisierbar ist.
• Ungeprüfte Komponenten. Während sich das Auditing und die Verwendung von Standardbibliotheken verbessert haben, verlassen sich Entwickler in ihren Anwendungen manchmal auf ungeprüfte Komponenten.
• Fehler bei der Zugriffskontrolle, wobei Berechtigungen falsch konfiguriert oder zu weit gefasst sind, was es Angreifern ermöglicht, bösartige Aktionen durchzuführen.
• Unbefugter Zugriff, wobei ein privater Schlüssel, der in der Lage ist, den Vertrag zu kontrollieren, von einem bösartigen Akteur erlangt wird.
• Brücken und Crosschain-Interaktionen. Brücken und Crosschain-Protokolle bringen zusätzliche Komplexität mit sich, und Angreifer können Schwachstellen in der Art und Weise ausnutzen, wie Crosschain-Nachrichten weitergeleitet oder validiert werden.
• Missbrauch von Delegation oder Signatur bei Externally Owned Accounts (EOA). Bösartige Anwendungen können Nutzer dazu verleiten, die vollständige Delegation ihres Kontos an eine andere Partei zu signieren, was Diebstahl ermöglicht. Bösartige Anwendungen können auch signierte Nachrichten des Nutzers auf unerwartete Weise verwenden, z. B. bei einem Replay-Angriff.
• Aufkommendes Risiko von Fehlern, die durch KI-Codegenerierung oder automatisierte Refactoring-Tools eingeführt werden.

2.2 Entwicklererfahrung, Tools und Programmiersprachen

Schwachstellen landen aufgrund von Entwicklerfehlern im bereitgestellten Code. Verbesserte Entwicklertools haben es erheblich einfacher gemacht, sichere Smart Contracts bereitzustellen. Dennoch bleiben Probleme bestehen.

• Mangel an sicheren Standardeinstellungen in beliebten Frameworks. Einige Tools priorisieren Flexibilität oder Geschwindigkeit gegenüber Sicherheit und legen unsichere Standardeinstellungen wie unbegrenzte Token-Genehmigungen in der Funktion approve() fest oder versäumen es, standardmäßig Zugriffskontrollmuster einzubeziehen.
• Benutzerdefinierter Code für erweiterte operative Kontrollen. Institutionelle Nutzer mit komplexen operativen Anforderungen müssen erforderliche Funktionen oft von Grund auf neu erstellen, was das Risiko von Schwachstellen erhöht. Es mangelt an standardisierten sicheren Komponenten oder Frameworks für erweiterte Sicherheits-Workflows.
• Inkonsistente Testabdeckung über Tooling-Stacks hinweg sowie ein Mangel an Normen für die Verwendung bewährter Techniken wie Fuzzing oder Invariantenprüfung.
• Geringe Akzeptanz formaler Verifikationsmethoden. Formale Verifikationstechniken sind leistungsstark, aber sie sind komplex, kostspielig, erfordern spezielles Fachwissen und sind nicht gut in Standard-Entwickler-Workflows integriert, wo sie viel früher in der Softwareproduktion eingesetzt werden könnten, um die Sicherheit bereits in der Spezifikationsphase zu verifizieren.
• Probleme im Zusammenhang mit der Vertragsverifizierung. Nutzer und Entwickler können die Vertrauenswürdigkeit bereitgestellter Verträge, den Umfang ihrer Sicherheitsvalidierung (z. B. Code-Audits) oder das Vorhandensein latenter Risiken nicht ohne Weiteres beurteilen. Obwohl es für diesen Zweck Lösungen gibt, bleiben viele Probleme bestehen. Tools, die diese Probleme angehen, sind nicht weit verbreitet, die Standards, die die Ansätze vereinheitlichen würden, bleiben fragmentiert, und einige der bestehenden Dienste sind selbst zentralisierte Abhängigkeiten.
• Compiler-Risiken. Compiler (die Software, die menschenlesbaren Code wie Solidity in den von der EVM selbst verwendeten Bytecode umwandelt) können Schwachstellen aufweisen, die Fehler in Smart Contracts einschleusen, bevor sie bereitgestellt werden. Das Ethereum-Ökosystem ist heute größtenteils vom solc-Compiler abhängig, was bedeutet, dass ein Fehler weitreichende Auswirkungen haben könnte.
• Vielfalt und Tiefe der Programmiersprachen. Während Solidity über ein tiefgreifendes Ökosystem an Tools verfügt, das darauf aufbaut, wünschen sich einige Entwickler modernere Sicherheitsfunktionen, die in anderen Programmiersprachen zu finden sind, wie z. B. Speichersicherheit.

2.3 Risikobewertung von Onchain-Code

Institutionen und Unternehmen verfügen über bestehende Prozesse, Standards und Anforderungen zur Bewertung der Sicherheit von Technologien und Systemen, von denen sie abhängig sind. Bestehende Frameworks lassen sich jedoch oft nicht nahtlos auf Smart Contracts übertragen, da sie in der Regel von veränderbarem Code, zentralisierter Änderungskontrolle und klaren Verantwortlichkeiten oder rechtlicher Haftung ausgehen. Systeme, die auf Smart Contracts basieren, können diese Annahmen manchmal durchbrechen, was es für Organisationen schwierig macht, Ethereum zu übernehmen und Risiken angemessen zu managen.

Diese Systeme stellen eine Angriffsfläche sowohl für die Wallet- und Anwendungsebene (z. B. RPC-Endpunkte für Wallets) als auch für das Ethereum-Protokoll selbst dar (z. B. werden viele Validatoren auf Cloud-Infrastruktur gehostet). Die Kompromittierung privater Schlüssel, Phishing und das Fehlen granularer Zugriffskontrollen können zu großflächigen Ausfällen, Diebstahl oder unbefugten Änderungen führen, selbst wenn das zugrunde liegende Blockchain-Protokoll sicher bleibt.

3.1 Layer-2-Chains

Layer-2-Chains (L2s) dienen als Erweiterungen für Ethereum und ermöglichen Umgebungen mit höherer Geschwindigkeit und niedrigeren Gebühren, während sie (je nach ihrem spezifischen Design) einige der charakteristischen Sicherheitsgarantien des Ethereum Mainnet beibehalten. Sie weisen jedoch auch ihre eigenen, spezifischen Angriffsflächen auf, darunter:

• Komplexität von über mehrere Hops überbrückten Vermögenswerten. Wenn Vermögenswerte zwischen L1 und mehreren L2s transferiert werden, sind sie mehreren Sätzen von Verträgen ausgesetzt, die alle sicher sein müssen. Fehlerhafte Buchführung oder Ausfälle in L2-Chains können Schwachstellen einführen, die von Angreifern ausgenutzt werden können.
• Rollup-L2s verlassen sich auf Beweissysteme, um die Korrektheit von Zustandsaktualisierungen durchzusetzen. Fehler oder Fehlkonfigurationen in diesen Systemen können die Endgültigkeit verzögern oder verhindern, oder die Endgültigkeit falscher Zustandsaktualisierungen ermöglichen, was zum Verlust von Nutzergeldern führt.
• Sicherheitsräte (Security Councils) sind Gruppen von Schlüsselinhabern, die als „Backup“-Mechanismus dienen, um L2-Software zu aktualisieren oder auf bestimmte Notfälle zu reagieren. Sicherheitsräte selbst bergen Risiken, da eine Kompromittierung oder geheime Absprachen unter den Mitgliedern Nutzergelder gefährden oder Vermögenswerte einfrieren könnten.

Siehe L2BEAT (opens in a new tab) für ein detailliertes Framework und Überwachungs-Dashboard, das die Leistung und Sicherheit von L2s bewertet und vergleicht.

3.2 RPC- und Knoten-Infrastruktur

Ethereum-Anwendungen hängen von einer kleinen Anzahl von Infrastrukturanbietern für RPC-Zugang, APIs und Knoten-Dienste ab. Dies umfasst krypto-spezifische Infrastrukturanbieter sowie traditionelle Cloud-Dienste, die üblicherweise zum Hosten von Knoten verwendet werden (z. B. AWS, Cloudflare, Hetzner).

Wenn diese Infrastrukturanbieter offline gehen oder versuchen würden, den Zugang zu zensieren oder zu drosseln, könnten viele Nutzer daran gehindert werden, über ihre Wallet oder Anwendung auf Ethereum zuzugreifen, bis sie zu einem neuen RPC- oder anderen Infrastrukturanbieter migrieren könnten. Einige dieser Anbieter haben in der Vergangenheit Konten im Zusammenhang mit Blockchain-Aktivitäten gesperrt oder geschlossen, was Bedenken hinsichtlich ihrer langfristigen Zuverlässigkeit für dezentrale Anwendungen aufwirft.

3.3 Schwachstellen auf DNS-Ebene

Das Domain Name System (DNS) ist eine grundlegende Schicht des Internets, aber es ist auch zentralisiert und kann kompromittiert werden. Viele Nutzer greifen über Web-Domains auf Apps zu, die anfällig sind für:

• DNS-Hijacking, bei dem ein Angreifer ein bösartiges, falsches Frontend einfügt.
• Domain-Beschlagnahmung, bei der eine Regierung oder ein Registrar Domains beschlagnahmen kann.
• Phishing über Lookalike-Domains, bei dem Angreifer nahezu identische Namen registrieren, um Nutzer zu täuschen.

3.4 Software-Lieferkette und Bibliotheken

Ethereum-Entwickler verlassen sich auf Open-Source-Bibliotheken, die oft direkt von Diensten wie npm, crates.io oder GitHub bezogen werden. Wenn diese Bibliotheken kompromittiert werden, können sie ein Vektor für Angriffe sein, wie z. B.:

• Einschleusen bösartiger Pakete, bei dem Angreifer ein weit verbreitetes Paket kompromittieren oder eines unter einem ähnlichen Namen veröffentlichen
• Gekaperte Abhängigkeiten, bei denen Maintainer die Kontrolle über ein Projekt verlieren und ein böswilliger Akteur schädlichen Code einführt
• Kompromittierung von Entwicklern, bei der installierte Pakete Code enthalten, der dem Angreifer die Kontrolle über den Computer des Entwicklers gibt.

3.5 Frontend-Bereitstellungsdienste und damit verbundene Risiken

Viele Ethereum-Anwendungen stellen ihre Frontends über ein Content Delivery Network (CDN) oder eine cloudbasierte Hosting-Plattform (z. B. Vercel, Netlify, Cloudflare) bereit. Wenn diese Dienste kompromittiert werden, können sie ein Vektor für Angriffe wie bösartige JavaScript-Injektionen sein, bei denen Angreifer den Nutzern ein verändertes Frontend ausliefern.

3.6 Zensur auf Ebene der Internetdienstanbieter

Internetdienstanbieter (ISPs) oder Nationalstaaten können die Kontrolle über die zugrunde liegende Internetinfrastruktur nutzen, um den Zugang zu Ethereum zu zensieren. Diese Angriffe könnten beispielsweise Folgendes umfassen:

• Blockieren oder Drosseln des Datenverkehrs zu gängigen Ethereum-Ports
• Filtern von DNS-Anfragen, die zu Ethereum-bezogenen Diensten auflösen
• Geofencing oder IP-Sperren gegen bekannte Ethereum-Knoten
• Deep Packet Inspection zur Identifizierung und Zensur von Datenverkehr im Zusammenhang mit dem Ethereum-Protokoll

Viele dieser grundlegenden Techniken werden bereits heute von autoritären Regierungen auf der ganzen Welt eingesetzt, um den Zugang zu Informationen, Protestwerkzeugen oder Kryptowährungen zu unterdrücken.

Das Konsens-Protokoll von Ethereum hat sich in der Praxis als robust erwiesen, mit null Ausfallzeiten seit dem ersten Start im Jahr 2015 und über mehrere Upgrades hinweg. Es gibt jedoch weiterhin langfristige Verbesserungsbereiche, um das System widerstandsfähiger und sicherer zu machen.

4.1 Konsens-Anfälligkeit und Wiederherstellungsrisiken

Die Fork-Choice- und Endgültigkeits-Regeln von Ethereum sind widerstandsfähig, aber nicht unverwundbar. Unter bestimmten Randbedingungen (wie anhaltende Uneinigkeit der Validatoren, Client-Fehler oder Netzwerkpartitionen) könnte der Konsens ins Stocken geraten oder vorübergehend abweichen. Unter extremen Bedingungen könnte dies zu kaskadierenden Strafen für Validatoren durch Inactivity Leaks oder Slashing führen, was wiederum zu Kapitalflucht von Validatoren führen könnte.

4.2 Client-Diversität

Die branchenführende Client-Diversität von Ethereum schützt das Netzwerk vor Fehlern in einem einzelnen Client. Die Client-Diversität könnte jedoch durch eine stärkere Akzeptanz von Minderheits-Clients noch weiter verbessert werden, um diese Risiken noch weiter zu reduzieren.

4.3 Staking-Zentralisierung und Pool-Dominanz

Ein erheblicher Teil des Validator-Gewichts konzentriert sich auf Liquid Staking-Protokolle, Verwahrungsdienste und große Knotenbetreiber. Diese Konzentration kann zu Risiken führen wie:

• Vereinnahmung oder Beeinflussung der Governance. Wenn Entitäten, die große Mengen an Stake kontrollieren (oder Entitäten mit der rechtlichen Befugnis, diese Entitäten zu beeinflussen), sich koordinieren würden, könnten sie einen übermäßigen Einfluss darauf haben, welche Blöcke vorgeschlagen und attestiert werden, was möglicherweise zur Zensur von Nutzern oder zur Beeinflussung von Protokoll-Upgrades führen könnte.
• Homogenität bei der Client-Wahl und dem Infrastruktur-Setup, was die Risiken korrelierter Ausfälle erhöhen kann.

4.4 Undefiniertes Soziales Slashing und Koordinationslücken

In einigen extremen Fehlermodi würde sich Ethereum auf „Soziales Slashing“ verlassen, um Validatoren zu bestrafen, die böswillig gehandelt haben, um das Netzwerk anzugreifen (siehe Abschnitt 6.1). Die Infrastruktur, Normen und erwarteten Prozesse für diese Art von Slashing sind jedoch unterentwickelt. Es gibt keinen etablierten Mechanismus, den die Community nutzen würde, um sich an diesem Prozess zu beteiligen.

4.5 Wirtschaftliche und spieltheoretische Angriffsvektoren

Viele potenzielle wirtschaftliche Angriffsvektoren sind noch unzureichend erforscht, darunter:

• Griefing-Angriffe oder Slash-Griefing. Validatoren können Kosten oder Slashing-Strafen nicht aufgrund eigener Fehler erleiden, sondern aufgrund von feindseligem Verhalten, das ausschließlich darauf abzielt, anderen zu schaden, wobei der Angreifer selbst Nettokosten trägt.
• Strategische Austritte oder zeitlich abgestimmte Inaktivität. Validatoren könnten absichtlich offline gehen oder zu kritischen Zeiten einen Austritt vollziehen, um Gewinne zu maximieren oder den Konsens mit minimalen Strafen zu stören.
• Geheime Absprachen zwischen Validatoren oder Relays. Koordiniertes Verhalten zwischen Validatoren oder zwischen Relays und Validatoren könnte die Dezentralisierung verringern oder MEV extrahieren.
• Ausnutzung von Edge-Case-Anreizen bei MEV, Proposer-Builder-Trennung (PBS) oder Liquid Staking-Design. Akteure könnten seltene Protokollbedingungen manipulieren, um übermäßige Belohnungen zu erhalten.

4.6 Quantenrisiko

Die Kern-Kryptographie von Ethereum (z. B. Signaturen über elliptische Kurven wie secp256k1) könnte eines Tages von Quantencomputern gebrochen werden. Obwohl dies kein unmittelbares Risiko darstellt, könnte eine glaubwürdige Bedrohung bestehende Wallets, Verträge und Staking-Schlüssel sofort angreifbar machen. Diese zukünftige Herausforderung schwächt die langfristigen Garantien von Ethereum gegenüber den Nutzern.

Migrationspfade zu quantenresistenter Kryptographie (z. B. über Post-Quanten-Signaturverfahren) müssen Jahre bevor sie benötigt werden entworfen, getestet und möglicherweise in das Protokoll eingebettet werden. Organisationen im gesamten Ethereum-Ökosystem, einschließlich der Ethereum Foundation, untersuchen diese Optionen aktiv und überwachen die Risiken.

Selbst ein idealisiertes Blockchain-Ökosystem wird Risiken, Angriffe und Schwachstellen aufweisen. Wenn Dinge schiefgehen, muss es effektive Systeme geben, um diese zu mindern, zu erkennen und darauf zu reagieren. Zu den Herausforderungen gehören hierbei:

• Erreichen des betroffenen Teams. Es kann schwierig sein, mit dem Team in Kontakt zu treten, dessen Anwendung kompromittiert wurde. Dies kann zu stundenlangen Verzögerungen führen, was die Fähigkeit der Einsatzkräfte einschränkt, Gelder zurückzugewinnen.
• Eskalation von Problemen bei verbundenen Organisationen. Wenn das Problem eine Plattform (wie ein soziales Netzwerk oder eine zentralisierte Börse) betrifft, kann es für die Einsatzkräfte eine Herausforderung sein, das Problem zu eskalieren, wenn sie keinen bestehenden Kontakt haben.
• Koordination der Reaktion. Es ist oft unklar, wie viele Incident-Response-Teams die betroffene Anwendung unterstützen, was zu Missverständnissen oder verschwendetem Aufwand führt, wenn eine gemeinsame Anstrengung effektiver gewesen wäre.
• Mangel an Überwachungsmöglichkeiten. Es kann schwierig sein, auf Onchain- und offchain-Probleme zu überwachen, was eine Frühwarnung bieten und eine schnelle Reaktion auf Bedrohungen gewährleisten würde.
• Zugang zu Versicherungen. Versicherungen sind ein wesentliches Instrument zur Minderung von Verlusten in den meisten traditionellen Systemen, die mit Geld, Finanzsystemen, Identität und anderen wertvollen Informationen umgehen. Heute stehen jedoch nur wenige Versicherungsoptionen von traditionellen Finanzdienstleistern für das Krypto-Ökosystem zur Verfügung.

Diese Risiken sind tendenziell eher langfristig orientiert und betreffen Ethereum als Ganzes und nicht die Sicherheit einzelner Nutzer oder Anwendungen.

6.1 Stake-Zentralisierung

Die Zentralisierung großer Mengen an Stake kann Risiken für Ethereum als Ganzes darstellen, wenn die Entitäten, die diesen Stake kontrollieren, beschließen, sich heimlich abzusprechen.
Diese wirtschaftliche Zentralisierung schafft das Potenzial für eine Vereinnahmung der sozialen Governance. Wenn eine kleine Gruppe von Validatoren eine Supermehrheit des Stakes kontrolliert, könnten sie:

• Sich bei Forks koordinieren oder sich diesen widersetzen.
• Bestimmte Transaktionen oder Verträge zensieren.
• Den Konsens der Community untergraben, indem sie mit einem Austritt oder Widerstand drohen.

Sollte dieses extreme Szenario eintreten, hat die Ethereum-Community vorgeschlagen, dass „Soziales Slashing“ die Antwort sein könnte. Soziales Slashing ist die Nutzung von offchain sozialem Konsens, um zu entscheiden, sich falsch verhaltende Validatoren zu slashen, als Kontrolle ihrer Macht. Es gibt jedoch keine klaren Normen, Verfahren oder Tools, um solche Maßnahmen umzusetzen (siehe Abschnitt 4.4).

6.2 Zentralisierung von offchain Vermögenswerten

Ethereum beherbergt erhebliche Mengen an reale Vermögenswerte (RWA), bei denen die Vermögenswerte offchain auf Bankkonten oder in anderen Depots gehalten werden, die dann onchain über Token gehandelt werden, die einen Anspruch auf die offchain Vermögenswerte darstellen. Viele große Stablecoins funktionieren beispielsweise auf diese Weise.

Die Institutionen, die die offchain Einlagen halten, können Einfluss auf das Ethereum-Ökosystem haben. In einem extremen Szenario, in dem es beispielsweise zu einem umstrittenen Fork oder Netzwerk-Upgrade kommt, können große Einleger beeinflussen, welche Chain weithin akzeptiert wird, indem sie sich entscheiden, Token nur auf der einen oder der anderen Chain anzuerkennen.

6.3 Regulatorischer Angriff oder Druck

Regierungen und Aufsichtsbehörden könnten Druck auf verschiedene Entitäten ausüben, die wichtige Komponenten des Ethereum-Stacks kontrollieren, um das Ethereum-Protokoll zu zensieren oder anderweitig zu stören. Institutionelle Nutzer von Ethereum könnten ebenfalls von diesem Druck betroffen sein, was weitere Konsequenzen für ihre Nutzer hätte (z. B. eine Bank, die aufgrund regulatorischer Verbote bestimmte Krypto-Produkte nicht mehr anbieten kann).

6.4 Organisatorische Vereinnahmung der Governance

Die Open-Source-Governance- und Entwicklungsprozesse von Ethereum werden von einer vielfältigen und globalen Gruppe von Teams und Unternehmen vorangetrieben, die die Kern-Client-Software, Infrastruktur und Tools pflegen.

Verschiedene Formen der Einflussnahme (Unternehmensübernahmen, Finanzierungsabhängigkeiten, Beschäftigung von Schlüsselakteuren, Interessenkonflikte innerhalb bestehender Organisationen) könnten die Kultur und die Prioritäten der Ethereum-Governance allmählich verschieben. Dies kann zu einer Ausrichtung auf spezifische kommerzielle oder externe Interessen führen, die vom gemeinschaftsgetriebenen Ethos und der etablierten Roadmap abweichen, was die Neutralität und Widerstandsfähigkeit von Ethereum im Laufe der Zeit schwächen könnte.