Ü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ückgängigmachungen. Dies bietet starke Garantien für Konsistenz und Sicherheit auf Protokollebene, setzt Benutzer 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 Benutzer. Um Ethereum sicher zu nutzen, müssen Einzelpersonen und Organisationen Schlüssel sicher aufbewahren und verwalten, mit Anwendungen auf der Blockchain interagieren und ihre Schlüssel verwenden, um Transaktionen zu signieren, um Vermögenswerte zu übertragen 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 Benutzer verlassen, um sie bei der Interaktion mit Ethereum zu informieren und anzuleiten.

1.1 Schlüsselverwaltung

Viele Benutzer sind nicht dafür gerüstet, kryptografische Schlüssel sicher zu verwalten.

Die meisten weit verbreiteten Software-Wallets verlassen sich darauf, dass Benutzer Seed-Phrasen sicher speichern, die ihren zugrunde liegenden kryptografischen Private-Key darstellen, was sie oft dazu verleitet, unsichere Workarounds zu verwenden, wie das Speichern von Seed-Phrasen im Klartext, in Cloud-Diensten oder das Aufschreiben auf Papier.

Hardware-Wallets sind eine Alternative, die es Benutzern ermöglichen, einen kryptografischen Schlüssel zu verwalten, der in einem speziellen physischen Gerät gespeichert ist. Hardware-Wallets haben jedoch ihre eigenen Schwächen 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 einem Software- oder Hardware-Wallet verwaltet werden, sind viele Benutzer verständlicherweise nervös wegen der Selbstverwahrung, wenn diese durch physischen Diebstahl oder Überfälle kompromittiert werden kann.

Unternehmens- und institutionelle Benutzer stehen bei der Schlüsselverwaltung vor zusätzlichen Herausforderungen. Wenn einzelne Mitarbeiter Schlüssel besitzen (z. B. als Teil eines Mehrfachsignatur-Wallets), 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 erfordern möglicherweise benutzerdefinierte Workflows oder Audit-Trails, die von der vorhandenen Wallet-Software nicht unterstützt werden. In einigen Fällen wenden sich Unternehmensbenutzer für digitale Vermögenswerte an Drittverwahrer, was eine weitere Ebene von Sicherheitsrisiken mit sich bringen kann, die berücksichtigt werden muss.

1.2 Blindes Signieren & Transaktionsunsicherheit

Benutzer 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 Benutzer nicht ausreichen, um die Konsequenzen einer bestimmten Transaktion zu verstehen. Dies macht Benutzer 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 Benutzer der zugrunde liegenden Anwendung im Rahmen der normalen Nutzung bestimmte Berechtigungen erteilen. Beispielsweise könnte ein Benutzer einer dezentralisierten Börse wie Uniswap die Erlaubnis erteilen, seine Token zu verschieben, um sie gegen ETH zu tauschen.

Diese Genehmigungen können betragsmäßig begrenzt sein, aber viele Wallets gewähren standardmäßig unbegrenzte Genehmigungen ohne Ablaufdatum. Für Benutzer gibt es in den meisten Wallets keine Möglichkeit, ihre ausstehenden Genehmigungen zu verwalten oder zu überprüfen.

Dies kann Benutzer bösartigen Apps oder kompromittierten Frontends aussetzen, da das Standardmuster für viele Benutzer darin besteht, unbegrenzte Genehmigungen zu erteilen, die verwendet werden können, um ihre Gelder abzuziehen. Selbst wenn ein Benutzer 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 Benutzers abziehen.

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

1.4 Kompromittierte Web-Schnittstellen

Die meisten Benutzer interagieren nicht direkt mit einem Smart Contract, sondern über eine Webschnittstelle über ihr Mobilgerät oder ihren 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 Benutzer aller Art zu bösartigen Smart Contracts umleiten oder sie dazu verleiten, irreführende Transaktionen zu signieren.

1.5 Datenschutz

Datenschutz kann Sicherheitsrisiken für Benutzer aller Art mindern oder vergrößern.

Schwächere Datenschutzvorkehrungen setzen einzelne Benutzer einer Vielzahl gezielter Bedrohungen wie Phishing, Ausbeutung, Betrug oder physischen Angriffen aus. Viele gängige UX-Muster setzen Benutzer Risiken aus, z. B. durch die Wiederverwendung von Adressen, KYC-Daten und andere Metadaten-Lecks.

Für Institutionen und Unternehmen ist Datenschutz aus Compliance-Gründen oder für bestimmte Anwendungsfälle oft eine grundlegende Geschäftsanforderung. Zusätzlich zu diesen Problemen kann dies zu einer Anfälligkeit für spezifische Sicherheitsrisiken führen. Beispielsweise kann ein Benutzer eines auf Ethereum basierenden Lieferkettensystems starke Datenschutzgarantien 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 Benutzer, den sicheren Umgang mit Wallets zu erlernen, und erhöht die Risiken.

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

Die Sicherheit von Smart Contracts 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 Sicherheitsvorkehrungen über den gesamten Software-Lebenszyklus hinweg zu verbessern, der dazu führt, dass Code auf der Blockchain 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 Verifizierungstechniken wurden übernommen, insbesondere für kettenübergreifende 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 Anwendungsebene gehärtet haben.

Es gibt jedoch weiterhin Schwächen und Verbesserungsbedarf in diesem Bereich.

2.1 Vertrags-Schwachstellen

Trotz Fortschritten bei der Sicherheit von Smart Contracts 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 geändert werden können, damit ein Entwicklungsteam eine Anwendung weiterhin aktualisieren und verbessern kann. Dies birgt jedoch Risiken. Upgrades könnten zu neuen Schwachstellen oder im Falle eines bösartigen Upgrades zum Totalverlust von Benutzergeldern 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 Verwendung 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 die Prüfung und Verwendung von Standardbibliotheken verbessert hat, 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 Private-Key, der den Vertrag kontrollieren kann, von einem bösartigen Akteur erlangt wird.
• Kettenübergreifende Brücken und Cross-Chain-Interaktionen. Kettenübergreifende Brücken und Cross-Chain-Protokolle bringen zusätzliche Komplexität mit sich, und Angreifer können Schwächen in der Art und Weise ausnutzen, wie Cross-Chain-Nachrichten weitergeleitet oder validiert werden.
• Delegation von extern verwalteten Konten (EOA) oder Signaturmissbrauch. Bösartige Anwendungen können Benutzer 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 Benutzers 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. Es bleiben jedoch 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 einzuschließen.
• Benutzerdefinierter Code für erweiterte operative Kontrollen. Institutionelle Benutzer mit komplexen betrieblichen 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 Verifizierungsmethoden. Formale Verifizierungstechniken 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 in der Spezifikationsphase zu überprüfen.
• Probleme im Zusammenhang mit der Vertragsverifizierung. Benutzer und Entwickler können die Vertrauenswürdigkeit bereitgestellter Verträge, den Umfang ihrer Sicherheitsvalidierung (z. B. Code-Audits) oder das Vorhandensein latenter Risiken nicht einfach 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 für Menschen lesbaren Code wie Solidity in den von der EVM selbst verwendeten Bytecode umwandelt) können Fehler aufweisen, die Fehler in Smart Contracts einführen, bevor sie bereitgestellt werden. Das Ethereum-Ökosystem hängt heute größtenteils vom solc-Compiler ab, was bedeutet, dass ein Fehler weitreichende Auswirkungen haben könnte.
• Vielfalt und Tiefe der Programmiersprachen. Während Solidity über ein tiefes Tooling-Ökosystem verfügt, wünschen sich einige Entwickler modernere Sicherheitsfunktionen, die in anderen Programmiersprachen zu finden sind, wie z. B. Speichersicherheit.

2.3 Risikobewertung von Code auf der Blockchain

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 sauber 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 einzuführen und Risiken angemessen zu verwalten.

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 von Private-Keys, 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 Ebene-2-Chains

Ebene-2-Chains (L2s) dienen als Erweiterungen für Ethereum und ermöglichen schnellere Umgebungen mit niedrigeren Gebühren, während sie einige der charakteristischen Sicherheitsgarantien des Ethereum-Mainnets beibehalten (abhängig von ihrem spezifischen Design). Sie haben jedoch auch ihre eigenen, unterschiedlichen Angriffsflächen, darunter:

• Komplexität von Multi-Hop-überbrückten Vermögenswerten. Wenn Vermögenswerte zwischen L1 und mehreren L2s wandern, sind sie mehreren Sätzen von Verträgen ausgesetzt, die alle sicher sein müssen. Nicht übereinstimmende Buchhaltung 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 Finalität verzögern oder verhindern oder die Finalität falscher Zustandsaktualisierungen ermöglichen, was zum Verlust von Benutzergeldern führt.
• Sicherheitsräte 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 Absprache unter den Mitgliedern Benutzergelder gefährden oder Vermögenswerte einfrieren könnte.

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

3.2 RPC- und Blockchain-Knoten-Infrastruktur

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

Wenn diese Infrastrukturanbieter offline gehen oder versuchen würden, den Zugriff zu zensieren oder zu drosseln, könnten viele Benutzer daran gehindert werden, über ihr Wallet oder ihre 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 dezentralisierte 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 Benutzer 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 denen Angreifer nahezu identische Namen registrieren, um Benutzer zu verwirren.

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 sind, können sie ein Vektor für Angriffe sein, wie:

• Injektion bösartiger Pakete, wobei Angreifer ein weit verbreitetes Paket kompromittieren oder eines unter einem ähnlichen Namen veröffentlichen
• Gekaperte Abhängigkeiten, wobei Maintainer die Kontrolle über ein Projekt verlieren und ein bösartiger Akteur schädlichen Code einführt
• Kompromittierung von Entwicklern, wobei 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 Cloud-basierte Hosting-Plattform (z. B. Vercel, Netlify, Cloudflare) bereit. Wenn diese Dienste kompromittiert sind, können sie ein Vektor für Angriffe wie bösartige JavaScript-Injektion sein, bei denen Angreifer den Benutzern ein verändertes Frontend bereitstellen.

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-Blockchain-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 Finalitätsregeln 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 Inaktivitätslecks oder Slashing führen, was wiederum zu Kapitalflucht von Validatoren führen könnte.

4.2 Client-Vielfalt

Die branchenführende Client-Vielfalt von Ethereum schützt das Netzwerk vor Fehlern in einem einzelnen Client. Die Client-Vielfalt 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 Blockchain-Knoten-Betreiber. Diese Konzentration kann zu Risiken führen wie:

• Governance-Übernahme oder -Einfluss. Wenn Entitäten, die große Mengen an Einsatz kontrollieren (oder Entitäten mit rechtlicher Befugnis, diese Entitäten zu beeinflussen), sich koordinieren würden, könnten sie einen übergroßen Einfluss darauf haben, welche Blöcke vorgeschlagen und bestätigt werden, was möglicherweise Benutzer zensiert oder Protokoll-Upgrades beeinflusst.
• Homogenität bei der Client-Wahl und der Infrastruktureinrichtung, 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 auf Nettokosten des Angreifers zu schaden.
• Strategische Exits oder zeitgesteuerte Inaktivität. Validatoren könnten absichtlich offline gehen oder zu kritischen Zeiten aussteigen, um Gewinne zu maximieren oder den Konsens mit minimalen Strafen zu stören.
• 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 in MEV, Proposer-Builder-Trennung oder Liquid-Staking-Design. Akteure können seltene Protokollbedingungen manipulieren, um übergroße Belohnungen zu erhalten.

4.6 Quantenrisiko

Die Kernkryptografie von Ethereum (z. B. elliptische Kurvensignaturen wie secp256k1) könnte eines Tages von Quantencomputern geknackt 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 für Benutzer.

Migrationspfade zu quantenresistenter Kryptografie (z. B. über Post-Quanten-Signaturschemata) 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, prüfen diese Optionen aktiv und überwachen die Risiken.

Selbst ein idealisiertes Blockchain-Ökosystem wird Risiken, Angriffe und Schwachstellen aufweisen. Wenn etwas schief geht, muss es effektive Systeme geben, um dies zu mindern, zu erkennen und darauf zu reagieren. Zu den Herausforderungen gehören hier:

• 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 und die Fähigkeit der Einsatzkräfte einschränken, Gelder zurückzugewinnen.
• Eskalation von Problemen bei verwandten 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 vorherigen Kontakt haben.
• Reaktionskoordination. Es ist oft unklar, wie viele Incident-Response-Teams die betroffene Anwendung unterstützen, was zu Fehlkommunikation oder verschwendetem Aufwand führt, wenn eine Gruppenanstrengung möglicherweise effektiver gewesen wäre.
• Mangel an Überwachungsfunktionen. Es kann schwierig sein, Probleme auf der Blockchain und Off-Chain 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 sich mit Geld, Finanzsystemen, Identität und anderen wertvollen Informationen befassen. 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 Benutzer oder Anwendungen.

6.1 Einsatz-Zentralisierung

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

• Forks koordinieren oder sich ihnen widersetzen.
• Bestimmte Transaktionen oder Verträge zensieren.
• Den Konsens der Community untergraben, indem sie mit Ausstieg oder Opposition drohen.

Sollte dieses extreme Szenario eintreten, hat die Ethereum-Community vorgeschlagen, dass „soziales Slashing“ die Antwort sein könnte. Soziales Slashing ist die Nutzung des sozialen Off-Chain-Konsenses, 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 zu ergreifen (siehe Abschnitt 4.4).

6.2 Zentralisierung von Off-Chain-Vermögenswerten

Ethereum beherbergt erhebliche Mengen an realen Vermögenswerten, wobei die Vermögenswerte Off-Chain auf Bankkonten oder anderen Einlagen gehalten werden, die dann auf der Blockchain über Token gehandelt werden, die einen Anspruch auf die Off-Chain-Vermögenswerte darstellen. Beispielsweise funktionieren viele große Stablecoins auf diese Weise.

Die Institutionen, die die Off-Chain-Einlagen halten, können Einfluss auf das Ethereum-Ökosystem haben. Beispielsweise können große Einleger in einem extremen Szenario, in dem es zu einem umstrittenen Fork oder Netzwerk-Upgrade kommt, beeinflussen, welche Chain weithin akzeptiert wird, indem sie sich dafür entscheiden, Token nur auf der einen oder 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 in dieses einzugreifen. Institutionelle Benutzer von Ethereum könnten ebenfalls von diesem Druck betroffen sein, was weitere Konsequenzen für ihre Benutzer hätte (z. B. eine Bank, die aufgrund regulatorischer Verbote bestimmte Krypto-Produkte nicht mehr anbieten kann).

6.4 Organisatorische Übernahme 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üsselmitwirkenden, 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 Community-gesteuerten Ethos und der etablierten Roadmap abweichen, was möglicherweise die Neutralität und Widerstandsfähigkeit von Ethereum im Laufe der Zeit schwächt.