Übersicht der Sicherheitsherausforderungen

Ein entscheidendes Merkmal von Blockchains ist die atomare Natur von Transaktionen: Sobald eine Aktualisierung in die Blockchain eingetragen ist, gibt es keine Möglichkeit mehr, einzugreifen oder sie rückgängig zu machen. 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 überstürzte Genehmigung können zu einem irreversiblen Verlust führen.

Infolgedessen liegt eine erhebliche Sicherheitslast beim Benutzer. Um Ethereum sicher zu nutzen, müssen Einzelpersonen und Organisationen Schlüssel sicher aufbewahren und verwalten, mit On-Chain-Anwendungen interagieren und ihre Schlüssel verwenden, um Transaktionen zur Übertragung von Vermögenswerten zu signieren oder den Zustand von Ethereum anderweitig 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 zu leiten.

1.1 Schlüsselverwaltung

Viele Benutzer sind nicht in der Lage, kryptografische Schlüssel sicher zu verwalten.

Die meisten weit verbreiteten Software-Wallets setzen darauf, dass die Benutzer Seed-Phrasen sicher speichern, die ihren zugrunde liegenden kryptografischen privaten Schlüssel repräsentieren, was sie oft dazu verleitet, unsichere Umgehungen 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öglicht, einen kryptografischen 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 haben, 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 Benutzer verständlicherweise nervös, wenn es um die Selbstverwahrung geht, wenn diese durch physischen Diebstahl oder Übergriffe kompromittiert werden kann.

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

1.2 Blindes Signieren & Transaktionsunsicherheit

Benutzer genehmigen routinemäßig Transaktionen "blind", ohne zu verstehen, was sie tun. Wallets präsentieren oft rohe hexadezimale Daten, gekürzte 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, Kompromittierungen des Frontends 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 Tokens zu bewegen, um sie gegen ETH zu tauschen.

Diese Genehmigungen können betragsmäßige Beschränkungen haben, aber viele Wallets gewähren standardmäßig unbegrenzte Genehmigungen ohne Ablaufdatum. Es gibt für Benutzer keine Möglichkeit, ihre ausstehenden Genehmigungen in den meisten Wallets 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 zum Abziehen ihrer Gelder verwendet werden können. Selbst wenn ein Benutzer eine Genehmigung für einen legitimen Smart Contract erteilt, könnte der kompromittierte Vertrag die Gelder des Benutzers abziehen, wenn dieser Vertrag später kompromittiert wird, während die Genehmigung bestehen bleibt.

Dies ist gleichermaßen ein Risiko für organisationale Nutzer. Beispielsweise könnte eine Organisation aus betrieblichen Gründen einem DEX-Router eine unbegrenzte USDC-Genehmigung erteilen, was sie dann Risiken aussetzt, wenn der Router-Vertrag aktualisiert wird.

1.4 Kompromittierte Weboberflächen

Die meisten Benutzer interagieren nicht direkt mit einem Smart Contract, sondern über eine Weboberfläche auf ihrem mobilen Gerät oder Webbrowser.

Diese Frontends können durch bekannte Mittel wie DNS-Hijacking, bösartige JavaScript-Injektionen, 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 unterzeichnen.

1.5 Datenschutz

Datenschutz kann Sicherheitsrisiken für Nutzer aller Art mindern oder verstärken.

Schwächere Datenschutzmaßnahmen setzen einzelne Benutzer einer Vielzahl von gezielten 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 der Datenschutz oft eine grundlegende Geschäftsanforderung aus Compliance-Gründen oder für bestimmte Anwendungsfälle. Zusätzlich zu diesen Problemen kann er eine Anfälligkeit für spezifische Sicherheitsrisiken schaffen. 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, wie verschiedene Wallets Kernverhaltensweisen 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.

Benutzer können sich beispielsweise nicht auf konsistente UX-Hinweise verlassen, um sich vor Phishing und Spoofing zu schützen, da diese sich zwischen den Wallets unterscheiden. Benutzer können keine verlässlichen Erwartungen darüber bilden, wie Ethereum funktioniert, wenn jedes Werkzeug 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 zu verbessern, der zur Bereitstellung von Code auf der Chain führt. Zu den wichtigsten Fortschritten gehören:

• Sicherheitsaudits wurden zur Standardpraxis, wobei mehrere Sicherheitsfirmen in das Ökosystem eintraten und Expertise entwickelten.
• Tooling-, Test- und statische Analysesysteme reiften heran und wurden zur Standardpraxis.
• Bibliotheken mit vorab geprüften gängigen Komponenten gaben Entwicklern standardmäßig sichere Bausteine an die Hand.
• Formale Verifizierungstechniken wurden übernommen, insbesondere für kettenübergreifende Brücken, Staking-Systeme und Verträge mit hohem Wert.
• Die Sicherheitskultur und die bewährten Praktiken des Ökosystems haben sich verbessert.
• Die Schaffung bedeutender Kopfgeldprogramme, die die App-Ebene gehärtet haben.

Dennoch gibt es in diesem Bereich weiterhin Schwachstellen und Verbesserungspotenzial.

2.1 Vertragsschwachstellen

Trotz der Fortschritte bei der Sicherheit von Smart Contracts gibt es immer noch Schwachstellen, die zu erheblichen Sicherheitsproblemen führen können, darunter:

• Risiko bei 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 zum Totalverlust von Benutzergeldern im Falle eines bösartigen Upgrades führen.
• Wiedereintritt, 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 abgeschlossen ist.
• Unsichere Verwendung externer Bibliotheken, bei dem ein Vertrag eine externe Bibliothek aufruft, die ungeprüft, bösartig oder aktualisierbar sein kann.
• Nicht geprüfte Komponenten. Obwohl die Prüfung und Verwendung von Standardbibliotheken verbessert wurde, verlassen sich Entwickler manchmal auf ungeprüfte Komponenten in ihren Anwendungen.
• Fehler bei der Zugriffskontrolle, bei denen Berechtigungen falsch konfiguriert oder zu weit gefasst sind, was Angreifern erlaubt, bösartige Aktionen durchzuführen.
• Unbefugter Zugriff, bei dem ein privater Schlüssel, der den Vertrag kontrollieren kann, von einem böswilligen 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 bei der Übermittlung oder Validierung von Cross-Chain-Nachrichten ausnutzen.
• Delegierung von extern verwalteten Konten (EOA) oder Missbrauch von Signaturen. Bösartige Anwendungen können Benutzer dazu verleiten, die volle Delegierung ihres Kontos an eine andere Partei zu unterzeichnen, 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-Code-Generierung oder automatisierte Refactoring-Tools eingeführt werden.

2.2 Entwicklererfahrung, Tooling und Programmiersprachen

Schwachstellen landen als Ergebnis von Entwicklerfehlern in bereitgestelltem Code. Verbessertes Entwickler-Tooling hat die Bereitstellung sicherer Smart Contracts erheblich erleichtert. Dennoch bleiben Probleme bestehen.

• Fehlen sicherer Standardeinstellungen in gängigen Frameworks. Einige Tools priorisieren Flexibilität oder Geschwindigkeit gegenüber Sicherheit und legen unsichere Standardeinstellungen wie unbegrenzte Token-Genehmigungen in der approve()-Funktion fest oder versäumen es, standardmäßig Zugriffskontrollmuster einzubeziehen.
• Benutzerdefinierter Code für erweiterte Betriebskontrollen. Institutionelle Benutzer mit komplexen betrieblichen Anforderungen müssen oft erforderliche Funktionen von Grund auf neu erstellen, was das Risiko von Schwachstellen erhöht. Es mangelt an standardisierten, sicheren Komponenten oder Frameworks für fortgeschrittene 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 von formalen 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 zur Überprüfung der Sicherheit auf Spezifikationsebene eingesetzt werden könnten.
• Probleme im Zusammenhang mit der Vertragsverifizierung. Benutzer und Entwickler können die Vertrauenswürdigkeit von bereitgestellten Verträgen, den Umfang ihrer Sicherheitsvalidierung (z. B. Code-Audits) oder das Vorhandensein latenter Risiken nicht einfach bewerten. Obwohl es für diesen Zweck Lösungen gibt, bleiben viele Probleme bestehen. Tooling, das diese Probleme angeht, ist 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 vom EVM selbst verwendeten Bytecode umwandelt) können Fehler aufweisen, die Fehler in Smart Contracts einführen, bevor diese bereitgestellt werden. Das Ethereum-Ökosystem hängt heute hauptsächlich vom solc-Compiler ab, was bedeutet, dass ein Fehler weitreichende Auswirkungen haben könnte.
• Vielfalt und Tiefe der Programmiersprachen. Obwohl Solidity ein tiefes Tooling-Ökosystem hat, 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 On-Chain-Code

Institutionen und Unternehmen haben bestehende Prozesse, Standards und Anforderungen zur Bewertung der Sicherheit von Technologien und Systemen, von denen sie abhängen. Bestehende Frameworks lassen sich jedoch oft nicht sauber auf Smart Contracts abbilden, 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 in Cloud-Infrastrukturen gehostet). Die Kompromittierung privater Schlüssel, Phishing und ein Mangel an granularen Zugriffskontrollen können zu großflächigen Ausfällen, Diebstahl oder unbefugten Änderungen führen, selbst wenn das zugrundeliegende Blockchain-Protokoll sicher bleibt.

3.1 Layer-2-Ketten

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

• Komplexität von Multi-Hop-überbrückten Vermögenswerten. Wenn Vermögenswerte zwischen L1 und mehreren L2s reisen, sind sie mehreren Sätzen von Verträgen ausgesetzt, die alle sicher sein müssen. Abweichende Buchführung oder Ausfälle in L2-Ketten können Schwachstellen einführen, die von Angreifern ausgenutzt werden können.
• Rollup-L2s stützen sich auf Beweissysteme, um die Korrektheit von Zustandsaktualisierungen durchzusetzen.. Fehler oder Fehlkonfigurationen in diesen Systemen können die Finalisierung verzögern oder verhindern oder die Finalisierung falscher Zustandsaktualisierungen ermöglichen, was zum Verlust von Benutzergeldern führt.
• Sicherheitsräte sind Gruppen von Schlüsselhaltern, die als "Backup"-Mechanismus dienen, um L2-Software zu aktualisieren oder auf bestimmte Notfälle zu reagieren. Sicherheitsräte selbst stellen Risiken dar, da Kompromittierung oder Absprachen unter den Mitgliedern die Gelder der Benutzer gefährden oder Vermögenswerte einfrieren könnten.

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

3.2 RPC- und Node-Infrastruktur

Ethereum-Anwendungen sind für RPC-Zugang, APIs und Node-Dienste von einer kleinen Anzahl von Infrastrukturanbietern abhängig. Dazu gehören krypto-spezifische Infrastrukturanbieter sowie traditionelle Cloud-Dienste, die üblicherweise zum Hosten von Nodes verwendet werden (z. B. AWS, Cloudflare, Hetzner).

Wenn diese Infrastrukturanbieter offline gingen oder versuchten, den Zugang zu zensieren oder zu drosseln, könnten viele Benutzer daran gehindert werden, über ihre Wallet oder Anwendung auf Ethereum zuzugreifen, bis sie zu einem neuen RPC- oder anderen Infrastrukturanbieter migrieren konnten. 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-Beschlagnahme, bei der eine Regierung oder ein Registrar Domains beschlagnahmen kann.
• Phishing über ähnlich aussehende Domains, bei denen Angreifer fast 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 werden, können sie ein Vektor für Angriffe sein wie:

• Injektion bösartiger Pakete, bei der Angreifer ein weit verbreitetes Paket kompromittieren oder eines unter einem ähnlichen Namen veröffentlichen
• Übernommene Abhängigkeiten, bei der Maintainer die Kontrolle über ein Projekt verlieren und ein böswilliger Akteur schädlichen Code einfügt
• 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 Benutzern ein verändertes Frontend bereitstellen.

3.6 Zensur auf Ebene des Internetdienstanbieters

Internetdienstanbieter (ISPs) oder Nationalstaaten können die Kontrolle über die zugrunde liegende Internetinfrastruktur nutzen, um den Zugang zu Ethereum zu zensieren. Solche Angriffe könnten beispielsweise 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-Nodes
• Tiefenpaketinspektion zur Identifizierung und Zensur von Ethereum-Protokoll-bezogenem Datenverkehr

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

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

4.1 Brüchigkeit des Konsenses und Wiederherstellungsrisiken

Die Fork-Choice- und Finalitätsregeln von Ethereum sind widerstandsfähig, aber nicht unverwundbar. Unter bestimmten Randbedingungen (wie lang andauernde Meinungsverschiedenheiten zwischen 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 einer Kapitalflucht von Validatoren führen könnte.

4.2 Client-Diversität

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 verbessert werden, um diese Risiken weiter zu reduzieren.

4.3 Zentralisierung des Stakings und Pool-Dominanz

Ein erheblicher Teil des Validator-Gewichts ist in Liquid-Staking-Protokollen, Depotdiensten und großen Node-Betreibern konzentriert. Diese Konzentration kann zu Risiken führen wie:

• Übernahme oder Beeinflussung der Governance. Wenn Entitäten, die große Mengen an Stake kontrollieren (oder Entitäten mit rechtlicher Macht, diese Entitäten zu beeinflussen), koordiniert zusammenarbeiten, könnten sie einen übermäßigen Einfluss darauf haben, welche Blöcke vorgeschlagen und bestätigt werden, was potenziell zur Zensur von Benutzern oder zur Beeinflussung von Protokoll-Upgrades führen könnte.
• Homogenität bei der Client-Wahl und dem Infrastrukturaufbau, was das Risiko 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 für diesen Prozess nutzen würde.

4.5 Ökonomische und spieltheoretische Angriffsvektoren

Viele potenzielle ökonomische Angriffsvektoren sind noch unzureichend untersucht, darunter:

• Griefing-Angriffe oder Slash-Griefing. Validatoren können Kosten oder Slashing-Strafen erleiden, die nicht auf eigene Fehler zurückzuführen sind, sondern auf feindseliges Verhalten, das ausschließlich dazu dient, anderen auf Kosten des Angreifers zu schaden.
• Strategische Ausstiege 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 Anreizen in Grenzfällen bei MEV, Trennung von Proposer und Builder oder Liquid-Staking-Design. Akteure können seltene Protokollbedingungen manipulieren, um übermäßige Belohnungen zu erhalten.

4.6 Quantenrisiko

Die Kernkryptographie von Ethereum (z. B. Signaturen auf elliptischen Kurven wie secp256k1) könnte eines Tages von Quantencomputern gebrochen werden. Obwohl dies kein unmittelbares Risiko ist, könnte eine glaubwürdige Bedrohung bestehende Wallets, Verträge und Staking-Schlüssel sofort anfällig machen. Diese zukünftige Herausforderung schwächt die langfristigen Garantien von Ethereum für die Benutzer.

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

Selbst ein idealisiertes Blockchain-Ökosystem wird Risiken, Angriffe und Schwachstellen aufweisen. Wenn etwas schief geht, müssen effektive Systeme zur Minderung, Erkennung und Reaktion vorhanden sein. Die Herausforderungen hierbei sind:

• Das betroffene Team erreichen. 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 Helfer, Gelder wiederherzustellen, einschränken.
• Eskalation von Problemen bei verbundenen Organisationen. Wenn das Problem eine Plattform betrifft (wie ein soziales Netzwerk oder eine zentralisierte Börse), kann es für Helfer schwierig sein, das Problem zu eskalieren, wenn sie keinen bestehenden Kontakt haben.
• Koordinierung der Reaktion. Es ist oft unklar, wie viele Incident-Response-Teams die betroffene Anwendung unterstützen, was zu Missverständnissen oder verschwendeter Mühe führt, wenn eine gemeinsame Anstrengung effektiver gewesen wäre.
• Mangelnde Überwachungsmöglichkeiten. Es kann schwierig sein, On-Chain- und Off-Chain-Probleme zu überwachen, was eine frühzeitige Warnung ermöglichen und eine schnelle Reaktion auf Bedrohungen sicherstellen 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 zu tun haben. Heute sind jedoch nur wenige Versicherungsoptionen von traditionellen Finanzdienstleistern für das Krypto-Ökosystem verfügbar.

Diese Risiken sind tendenziell eher langfristig orientiert und betreffen Ethereum als Ganzes und nicht die Sicherheit einzelner Benutzer 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, zusammenzuarbeiten.
Diese wirtschaftliche Zentralisierung schafft das Potenzial für eine soziale Übernahme der Governance. Wenn eine kleine Gruppe von Validatoren eine Supermehrheit des Stakes kontrolliert, könnten sie:

• Forks koordinieren oder sich ihnen 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 eines Off-Chain-Sozialkonsenses, um zu entscheiden, sich fehlverhaltende Validatoren zu slashen, als Kontrolle ihrer Macht. Aber es gibt 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, bei denen die Vermögenswerte außerhalb der Chain in Bankkonten oder anderen Einlagen gehalten werden, die dann auf der Chain ü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 während eines extremen Szenarios, bei dem es zu einem umstrittenen Fork oder Netzwerk-Upgrade kommt, beeinflussen, welche Kette weithin akzeptiert wird, indem sie sich nur dafür entscheiden, Token auf der einen oder der anderen Kette anzuerkennen.

6.3 Regulatorischer Angriff oder Druck

Regierungen und Regulierungsbehörden könnten verschiedene Entitäten, die wichtige Komponenten des Ethereum-Stacks kontrollieren, unter Druck setzen, 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 Kryptoprodukte 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 Tooling warten.

Verschiedene Formen des Einflusses (Unternehmensübernahmen, Finanzierungsabhängigkeiten, Anstellung von Schlüssel-Mitwirkenden, 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-getriebenen Ethos und der etablierten Roadmap abweichen, was die Neutralität und Widerstandsfähigkeit von Ethereum im Laufe der Zeit potenziell schwächen könnte.