Antworten>Erfahren Sie mehr über die Grundlagen der Blockchain-Sicherheit>Häufige Fehlerquellen bei Blockchains
Häufige Fehlerquellen bei Blockchains
// Tags
Blockchain-AusfallBlockchain-Angriffe
TL;DR: Die Ausfallmodi von Blockchains erstrecken sich über drei verschiedene Ebenen: Ausfälle auf der Konsens-Ebene (Fehler bei Validatoren, Netzwerkpartitionen, 51-Prozent-Angriffe), Ausfälle auf der Anwendungsebene (Schwachstellen in Smart Contracts, Manipulation von Oracles, Ausnutzung von Governance-Lücken) und Ausfälle auf der Infrastruktur-Ebene (Knotenausfälle, Ausfälle von Anbietern, Cloud-Vorfälle). Jede Ebene weist eigene Angriffsvektoren, Risikoprofile und Strategien zur Risikominderung auf. Das Verständnis dieser Ausfallarten ist für die Entwicklung robuster Blockchain-Anwendungen unerlässlich, da die Folgen eines Ausfalls in einem System, das mit realen finanziellen Werten umgeht, weitaus schwerwiegender sind als bei herkömmlicher Software.
Die einfache Erklärung
Blockchains werden oft als vertrauensunabhängig und unveränderlich beschrieben, doch das bedeutet nicht, dass sie unfehlbar sind. Wie jedes komplexe verteilte System können auch Blockchains auf vielfältige Weise und auf verschiedenen Ebenen ausfallen. Die entscheidende Erkenntnis für Entwickler ist, dass Blockchain-Ausfälle vielschichtig sind: Selbst ein absolut sicherer Smart Contract kann noch immer zu einem Verlust von Nutzergeldern führen, wenn das Orakel, das ihm Daten liefert, manipuliert wird, und selbst eine perfekt programmierte Anwendung kann noch immer ausfallen, wenn die zugrunde liegende Knoteninfrastruktur ausfällt.
Stellen Sie sich das wie ein Gebäude vor. Das Fundament (Konsensschicht) könnte Risse bekommen. Die Wasser- und Stromleitungen (Anwendungsschicht) könnten undicht werden oder einen Kurzschluss verursachen. Die Hausverwaltung (Infrastrukturschicht) könnte in Konkurs gehen. Jede dieser Ausfallmöglichkeiten erfordert eine andere Art von Schutz, und echte Ausfallsicherheit setzt voraus, dass man sich gleichzeitig gegen alle drei absichert.
Ausfälle der Konsensschicht
Die Konsensschicht bildet das Fundament jeder Blockchain. Sie ist der Mechanismus, durch den sich die Validatoren darauf einigen, welche Transaktionen gültig sind und welche Blöcke der Kette hinzugefügt werden sollen. Wenn der Konsens scheitert, sind die Folgen äußerst schwerwiegend: Die Kette kann zum Stillstand kommen, sich neu organisieren oder widersprüchliche Blöcke erzeugen.
Fehler bei Validatoren gehören zu den häufigsten Ausfallursachen auf der Konsens-Ebene. Blockchain-Client-Software ist komplex, und Fehler bei der Blockerzeugung, der Beglaubigungslogik oder der Berechnung von Zustandsübergängen können dazu führen, dass Validatoren ungültige Blöcke erzeugen, während Konsensrunden abstürzen oder sich mit anderen Validatoren über den korrekten Zustand uneinig sind. Das Risiko wird noch verstärkt, wenn eine einzige Client-Implementierung das Netzwerk dominiert. Wenn 70 % der Validatoren denselben Client verwenden und dieser Client einen Fehler aufweist, sind 70 % des Netzwerks gleichzeitig betroffen. Aus diesem Grund ist die Client-Vielfalt – also der Einsatz mehrerer Implementierungen desselben Protokolls – ein immer wiederkehrendes Thema in der Blockchain-Sicherheit.
Netzwerkpartitionen treten auf, wenn Gruppen von Validatoren die Fähigkeit verlieren, miteinander zu kommunizieren – typischerweise aufgrund von Problemen mit der Internetinfrastruktur, gezielten DDoS-Angriffen oder geografischen Routing-Fehlern. Wenn durch eine Partition so viele Validatoren voneinander getrennt werden, dass keine der beiden Seiten die Konsensschwelle (in der Regel zwei Drittel des gestakten Gewichts) erreichen kann, kommt die Blockproduktion zum Stillstand. Handelt es sich um eine partielle Partition (beide Seiten können die Schwelle unabhängig voneinander noch erreichen), kann es zu einer vorübergehenden Gabelung der Blockchain kommen, wobei jede Partition ihre eigenen Blöcke produziert. Wenn die Partition behoben ist, wird die Gabelung durch eine Reorganisation aufgelöst, wobei Transaktionen in der kürzeren Gabelung rückgängig gemacht werden.
51 %-Angriffe (bzw. 34 %-Angriffe auf BFT-basierte Blockchains) ermöglichen es einem Angreifer mit mehrheitlicher Konsensmacht, den jüngsten Verlauf der Blockchain umzuschreiben. Der Angreifer erstellt eine private Blockchain, die von der öffentlichen Blockchain abweicht, sammelt mehr Proof-of-Work oder Validator-Bestätigungen und sendet diese anschließend an das Netzwerk. Da die Blockchain des Angreifers ein größeres kumulatives Gewicht aufweist, übernimmt das Netzwerk sie als kanonisch, wodurch die jüngsten Blöcke der öffentlichen Blockchain zu Waisenblöcken werden. Dies ermöglicht Doppelausgaben: Der Angreifer sendet Gelder auf der öffentlichen Blockchain, wartet auf die Bestätigung und veröffentlicht anschließend seine private Blockchain, die die Transaktion nicht enthält – so erhält er effektiv die Waren und behält gleichzeitig das Geld.
Ausfälle auf Anwendungsebene
Die Anwendungsschicht umfasst Smart Contracts, DeFi-Protokolle, Oracles und die On-Chain-Logik, die Nutzergelder in Höhe von mehreren Milliarden Dollar verwaltet. Ausfälle auf der Anwendungsschicht sind die häufigste und kostspieligste Ursache für Verluste im Blockchain-Bereich.
Reentrancy-Angriffe nutzen eine Schwachstelle aus, bei der ein Smart Contract einen externen Aufruf an einen anderen Contract sendet, bevor er seinen eigenen Zustand aktualisiert. Der aufgerufene Contract kann in den ursprünglichen Contract „zurückkehren“ und dieselbe Funktion erneut ausführen, bevor die Zustandsaktualisierung erfolgt, wodurch möglicherweise Gelder abgezogen werden. Der DAO-Hack im Jahr 2016, der zur Abspaltung von Ethereum und Ethereum Classic führte und Verluste in Höhe von etwa 60 Millionen US-Dollar zur Folge hatte, war ein Reentrancy-Angriff. Obwohl diese Schwachstellen seit Jahren bekannt sind, tauchen sie weiterhin in neuen Verträgen auf, die das Muster „Prüfung – Auswirkung – Interaktion“ nicht befolgen.
Schwachstellen durch Integer-Überlauf und -Unterlauf treten auf, wenn arithmetische Operationen Ergebnisse außerhalb des Bereichs des Datentyps liefern, wodurch es zu einem Wertumbruch kommt. Eine Subtraktion, die eigentlich eine negative Zahl ergeben sollte, könnte stattdessen eine astronomisch große positive Zahl liefern, wodurch ein Angreifer mehr Token beanspruchen könnte, als ihm zustehen. Solidity 0.8.0 hat integrierte Überlaufprüfungen hinzugefügt, die bei einem Überlauf die Transaktion rückgängig machen; Verträge, die mit älteren Versionen kompiliert wurden oder ungeprüfte arithmetische Blöcke verwenden, bleiben jedoch anfällig.
Fehler bei der Zugriffskontrolle treten auf, wenn bei Verwaltungsfunktionen keine ordnungsgemäßen Berechtigungsprüfungen stattfinden, sodass unbefugte Benutzer Funktionen aufrufen können, die ausschließlich für Vertragsinhaber oder bestimmte Rollen vorgesehen sind. Dazu gehören ungeschützte Upgrade-Funktionen (die es jedem ermöglichen, die Logik des Vertrags zu ersetzen), fehlende Eigentumsprüfungen bei Auszahlungsfunktionen sowie falsch konfigurierte rollenbasierte Zugriffsrechte.
Die Manipulation von Orakeln ist ein besonders heimtückischer Angriffsvektor, da sie die Schnittstelle zwischen On-Chain- und Off-Chain-Daten ausnutzt. Smart Contracts, die für Kreditvergabe, Liquidation oder Derivate auf Preisorakel angewiesen sind, können dazu verleitet werden, auf manipulierte Preise zu reagieren. Flash-Loan-Angriffe sind dabei das häufigste Mittel: Ein Angreifer leiht sich eine große Menge an Token aus, nutzt diese, um den Preis auf einer DEX zu manipulieren, auf die sich das Orakel bezieht, löst bei dem manipulierten Preis eine gewinnbringende Aktion auf dem Zielprotokoll aus und zahlt den Flash-Loan zurück – alles in einer einzigen atomaren Transaktion. Der Smart Contract des Zielprotokolls funktionierte genau wie vorgesehen. Der Fehler lag im Design des Orakels, das kurzfristige Manipulationen nicht berücksichtigt hatte.
Governance-Exploits zielen auf die dezentralen Governance-Mechanismen von DAOs und DeFi-Protokollen ab. Ein Angreifer verschafft sich genügend Governance-Token (oft mithilfe von Flash-Krediten), um einen böswilligen Vorschlag durchzusetzen, der Gelder aus der Kasse entzieht, Protokollparameter so ändert, dass ausnutzbare Bedingungen entstehen, oder Zugriffskontrollen so verändert, dass der Angreifer Administratorrechte erhält.
Ausfälle auf der Infrastrukturebene
Ausfälle auf der Infrastrukturebene beeinträchtigen zwar nicht die Blockchain selbst, behindern jedoch die Interaktion von Anwendungen und Nutzern mit ihr. Für Endnutzer und Entwickler ist ein Infrastrukturausfall unter Umständen nicht von einem Ausfall auf Blockchain-Ebene zu unterscheiden, da das praktische Ergebnis dasselbe ist: Die Anwendung funktioniert nicht.
Knotenausfälle und Synchronisierungsfehler führen dazu, dass einzelne Knoten offline gehen oder veraltete Daten ausgeben. Ein Knoten, der mehrere Blöcke hinter der Kettenspitze zurückgefallen ist, gibt veraltete Guthaben an, übersieht aktuelle Transaktionen und lehnt möglicherweise gültige Transaktionen ab, die von den jüngsten Zustandsänderungen abhängen. Anwendungen, die auf einen einzelnen Knoten angewiesen sind (ohne Failover), fallen vollständig aus, wenn dieser Knoten ausfällt.
Ausfälle bei Anbietern betreffen alle Kunden eines bestimmten Infrastrukturanbieters gleichzeitig. Wenn es bei einem großen RPC-Anbieter zu einem Ausfall kommt, verliert jede Anwendung, die die Endpunkte dieses Anbieters nutzt, den Zugriff auf die Blockchain. Dies stellt ein Zentralisierungsrisiko innerhalb eines vermeintlich dezentralen Ökosystems dar: Tausende von Anwendungen, die denselben Infrastrukturanbieter nutzen, schaffen einen Single Point of Failure.
Störungen bei Cloud-Anbietern wirken sich ebenso auf die Blockchain-Infrastruktur aus wie auf jeden anderen in der Cloud gehosteten Dienst. Wenn es bei AWS, GCP oder einem anderen Cloud-Anbieter zu einem regionalen Ausfall kommt, gehen alle in dieser Region betriebenen Blockchain-Knoten offline. Da eine unverhältnismäßig große Anzahl von Blockchain-Knoten bei einer geringen Anzahl von Cloud-Anbietern betrieben wird, können Cloud-Ausfälle überproportionale Auswirkungen auf den Zustand des Netzwerks und die Verfügbarkeit von Anwendungen haben.
DNS- und Netzwerkausfälle können dazu führen, dass Anwendungen ihre RPC-Endpunkte nicht erreichen können, selbst wenn diese normal funktionieren. DNS-Hijacking, Probleme beim BGP-Routing und Probleme mit TLS-Zertifikaten können die Verbindung zwischen einer Anwendung und ihrer Blockchain-Infrastruktur unterbrechen.
Maßnahmen zur Risikominderung
Um sich gegen Ausfallarten der Blockchain zu schützen, ist ein mehrschichtiger Ansatz erforderlich, der alle drei Ebenen berücksichtigt.
Auf der Konsensschicht ist die Vielfalt der Clients die wirksamste Einzelmaßnahme zum Schutz vor Angriffen. Durch den Einsatz mehrerer Client-Implementierungen wird sichergestellt, dass ein Fehler in einem Client nicht das gesamte Netzwerk beeinträchtigt. Auch die Stake-Verteilung spielt eine wichtige Rolle: Die Förderung einer breiten, dezentralen Validatorengruppe verringert das Risiko koordinierter Ausfälle und 51-Prozent-Angriffe. Auf der Anwendungsschicht sind Sicherheitsaudits, formale Verifikation und Bug-Bounty-Programme die wichtigsten Schutzmaßnahmen.
Smart Contracts sollten vor ihrer Bereitstellung von mehreren unabhängigen Unternehmen geprüft werden. Die formale Verifikation beweist mathematisch, dass der Vertragscode mit seiner Spezifikation übereinstimmt, und deckt so Fehler auf, die bei einer manuellen Überprüfung möglicherweise übersehen würden. Bug-Bounty-Programme bieten White-Hat-Hackern Anreize, Schwachstellen zu finden und verantwortungsbewusst offenzulegen. Zeitgesteuerte Upgrades geben der Community Zeit, vorgeschlagene Änderungen zu prüfen, bevor sie in Kraft treten, und verhindern so, dass böswillige oder fehlerhafte Upgrades sofort bereitgestellt werden. Multi-Signatur-Anforderungen für administrative Funktionen stellen sicher, dass kein einzelner kompromittierter Schlüssel privilegierte Vorgänge ausführen kann.
Auf der Infrastrukturebene bildet die Redundanz über Anbieter, Regionen und Cloud-Plattformen hinweg die Grundlage für die Ausfallsicherheit. Anwendungen sollten niemals von einem einzigen RPC-Anbieter, einem einzigen Rechenzentrum oder einem einzigen Cloud-Anbieter abhängig sein. Circuit Breaker verhindern Kettenausfälle, indem sie ausgefallene Komponenten automatisch trennen, bevor diese vorgelagerte Systeme lahmlegen. Durch „Graceful Degradation“-Konzepte können Anwendungen weiterhin Kernfunktionen (wie die Anzeige von Kontoständen) bereitstellen, selbst wenn einige Infrastrukturkomponenten nicht verfügbar sind.
Wie Quicknode Widerstandsfähigkeit aufbaut
Die Infrastruktur von Quicknode ist darauf ausgelegt, Ausfälle auf der Infrastrukturebene zu minimieren – durch geografische Verteilung auf mehr als 14 Regionen und mehr als 5 Cloud- und Bare-Metal-Anbieter, durch Kundenvielfalt, soweit möglich, durch automatisches Failover, das Anfragen von ausgefallenen Knoten umleitet, sowie durch eine Rund-um-die-Uhr-Überwachung durch ein spezielles Blockchain-Betriebsteam.
Quicknode Streams sorgt für Ausfallsicherheit bei Datenpipelines durch garantierte Zustellung, Verarbeitung in der Reihenfolge der Finalität und automatische Behandlung von Reorgs. Wenn Ereignisse auf der Konsens-Ebene wie Reorgs auftreten, erkennt und korrigiert Streams die betroffenen Daten automatisch. Für die Überwachung auf Anwendungsebene ermöglicht Streams Entwicklern, bestimmte Vertragsereignisse, ungewöhnliche Transaktionsmuster und Zustandsänderungen zu überwachen, die auf einen laufenden Angriff hindeuten könnten.
Für Teams mit höchsten Anforderungen an die Zuverlässigkeit bieten die dedizierten Cluster von Quicknode eine isolierte Infrastruktur mit SLAs für garantierte Verfügbarkeit, unabhängig vom Datenverkehr anderer Nutzer. Dadurch wird das Risiko eines „Noisy Neighbor“ vermieden, bei dem ein Datenverkehrsanstieg bei einem anderen Kunden Ihre Leistung beeinträchtigen könnte, und es wird die für geschäftskritische Blockchain-Anwendungen erforderliche Isolation gewährleistet.
Was sind die häufigsten Arten von Blockchain-Ausfällen?
Die oben beschriebenen Fehlerarten lassen sich nach der Ebene gruppieren, in der sie auftreten; daraus lässt sich auch ableiten, wer für die Abwehr der jeweiligen Fehlerart zuständig ist. Die folgende Tabelle fasst die häufigsten Fehler, ein repräsentatives Beispiel sowie die entsprechenden Abwehrmaßnahmen zusammen.
Ebene
Häufige Fehler
Beispiel
Wo Klimaschutz gelebt wird
Konsens
51-Prozent-Angriff oder Reorg
Die Mehrheit schreibt die jüngste Geschichte neu
Protokoll und Validator-Set
Konsens
Netzwerkpartitionierung oder Systemabschaltung
Validatoren können die Schwelle nicht erreichen
Protokoll- und Client-Vielfalt
Anwendung
Reentrancy oder Manipulation des Orakels
Ein Flash-Kredit zehrt einen Kreditpool auf
Smart Contracts und Audits
Anwendung
Ausnutzung von Zugriffskontroll- oder Governance-Schwachstellen
Ungeschützte Admin-Funktion
Smart Contract und Multisig
Infrastruktur
Knotenausfall oder Ausfall des Anbieters
Der RPC-Endpunkt gibt veraltete Daten zurück
Redundante Infrastruktur
Wie lassen sich Blockchain-Ausfälle erkennen, bevor sie zu Verlusten führen?
Die Erkennung macht den Unterschied zwischen einem eingedämmten und einem katastrophalen Vorfall aus. Durch die kontinuierliche Überwachung der Blockchain-Infrastruktur werden Verzögerungen bei den Knoten, Fehlerspitzen und Synchronisationslücken in Echtzeit aufgedeckt, während eine umfassendere Beobachtbarkeit diese Signale mit dem Anwendungsverhalten verknüpft, sodass Sie erkennen können, wenn sich ein Sicherheitslückenausnutzen oder ein Ausfall anbahnt, noch bevor die Nutzer davon etwas bemerken.
Was ist der Unterschied zwischen einem „Chain Halt“ und einer „Chain Reorg“?
Diese beiden Fehler auf der Konsens-Ebene werden oft verwechselt. Bei einem „Chain Halt“ wird die Blockproduktion vollständig eingestellt, da die Validatoren die Konsensschwelle nicht erreichen können, sodass keine neuen Transaktionen bestätigt werden. Bei einer Blockchain-Reorganisation werden weiterhin Blöcke produziert, jedoch werden kürzlich akzeptierte Blöcke durch eine konkurrierende Kette ersetzt, wodurch Transaktionen, die bereits als bestätigt galten, rückgängig gemacht werden können.
Inwiefern verringert die Redundanz der Infrastruktur das Ausfallrisiko?
Die meisten Ausfälle auf der Infrastrukturebene lassen sich auf einen einzigen Fehlerpunkt zurückführen. Das Verständnis dafür, warum Redundanz in der Infrastruktur wichtig ist, führt direkt zu Konzepten mit mehreren Anbietern und Regionen sowie zu einer automatischen Ausfallsicherung, die einen ausgefallenen Knoten umgeht, bevor es zu Fehlern bei den Anfragen kommt.
Häufig gestellte Fragen
Was sind die drei Ebenen eines Blockchain-Ausfalls?
Störungen entstehen entweder auf der Konsensschicht (Fehler bei Validatoren, Partitionen, 51-Prozent-Angriffe), der Anwendungsschicht (Fehler in Smart Contracts, Manipulation von Oracles, Ausnutzung von Schwachstellen im Governance-System) oder der Infrastrukturschicht (Knotenausfälle, Ausfälle von Anbietern und Cloud-Diensten). Ausfallsichere Systeme schützen vor allen drei Arten von Störungen.
Was ist die häufigste Ursache für Verluste im Zusammenhang mit der Blockchain?
Fehler auf Anwendungsebene, insbesondere Schwachstellen in Smart Contracts und die Manipulation von Oracles, sind am häufigsten und verursachen die höchsten Kosten. Die zugrunde liegende Blockchain funktioniert oft genau wie vorgesehen, während fehlerhafte Vertrags- oder Oracle-Logik ausgenutzt wird.
Kann ein Ausfall eines einzelnen RPC-Anbieters dazu führen, dass meine App ausfällt?
Ja. Wenn Ihre Anwendung von einem einzigen Anbieter, einem einzigen Rechenzentrum oder einer einzigen Cloud-Region abhängig ist, führt ein Ausfall an dieser Stelle dazu, dass Sie nicht mehr erreichbar sind. Durch die Verteilung des Datenverkehrs auf redundante Anbieter und Regionen mit automatischer Ausfallsicherung wird dieser einzelne Ausfallpunkt beseitigt.
Ist ein 51-Prozent-Angriff dasselbe wie eine Netzwerkpartition?
Nein. Ein 51-Prozent-Angriff ist ein gezielter Versuch einer Mehrheit der Konsensmacht, die Historie umzuschreiben, während eine Netzwerkpartition ein versehentlicher Verlust der Kommunikation zwischen den Validatoren ist. Beides kann zu Reorgs führen, doch ihre Ursachen und Abwehrmaßnahmen unterscheiden sich.
Wie schützt man sich vor Oracle-Manipulation?
Verwenden Sie Oracles, die Preise aus verschiedenen Quellen und über einen bestimmten Zeitraum hinweg aggregieren, vermeiden Sie es, sich auf einen einzigen DEX-Spotpreis zu verlassen, und richten Sie Plausibilitätsprüfungen und Circuit Breaker ein. Diese Maßnahmen schwächen Flash-Loan-Angriffe ab, die einen Preis-Feed kurzzeitig verzerren.
