Wie wir DeFi-Exploits in weniger als einer Sekunde erkennen

Quicknode

21. April 2026 – 7 Minuten Lesezeit

Teilen

Als bevorzugte Quelle hinzufügen

Von Arseniy Reutov, CTO und Mitbegründer von Decurity Veröffentlicht auf dem Blog „ Quicknode “

Ich habe über ein Jahrzehnt damit verbracht, Systeme zur Erkennung von Angriffen zu entwickeln; zunächst im Web2, wo ich mich mit Traffic-Analyse und WAFs befasste, dann im Web3, wo sich dieselben Probleme mit Angreifern schneller abspielen und um höhere Summen geht. Im Jahr 2022 war ich Mitbegründer von Decurity. Wir prüfen DeFi-Protokolle und entwickeln die Tools, um sie im Produktivbetrieb zu überwachen. Defimon ist die Überwachungskomponente: ein Echtzeit-System zur Erkennung von Exploits, auf das Protokollteams, Sicherheitsunternehmen und Risikomanager über alle Blockchains hinweg vertrauen, auf denen DeFi tatsächlich läuft. Es löst Warnmeldungen aus, noch bevor Hacks in den Nachrichten erscheinen. Sonst erfüllt es seinen Zweck nicht. Etwas zu entwickeln, das mit dieser Geschwindigkeit und über so viele Blockchains hinweg funktioniert, erwies sich als ein schwierigeres Infrastrukturproblem als ein Sicherheitsproblem. Das haben wir bei der Entwicklung gelernt.

Warum die Erkennungsgeschwindigkeit eine Sicherheitsgrundkomponente ist

In der DeFi kann ein Protokoll in einer einzigen atomaren Transaktion vollständig leergeräumt werden. Allerdings gibt es sehr oft ein Zeitfenster zwischen den ersten Anzeichen eines Exploits und der vollständigen Ausbeutung des Protokolls. Der Balancer-Vorfall. Der Yearn-Hack. In beiden Fällen ging es nicht darum, ob jemand zugeschaut hat. Es ging darum, ob diese ersten Anzeichen erkannt wurden und rechtzeitig reagiert wurde.

Damit die automatisierte Reaktion auf Vorfälle funktioniert, muss die Warnmeldung rechtzeitig eintreffen, damit Maßnahmen ergriffen werden können: Verträge aussetzen, Multisig-Inhaber benachrichtigen, Gelder transferieren. Eine Verzögerung von zwei Sekunden bei der Blockverarbeitung klingt nicht nach viel. Auf Protokollebene ist dies jedoch der Unterschied zwischen einer Warnung und einer nachträglichen Analyse.

Die Erkennungsgeschwindigkeit ist kein Merkmal. Sie ist das Produkt.

Das Problem mit Umfragen

Als wir mit der Entwicklung von Defimon begannen, haben wir On-Chain-Daten auf die übliche Weise abgerufen: durch Abfragen über RPC, wobei wir die Blockchain wiederholt nach neuen Blöcken, Transaktionen, Protokollen und Trace-Daten abgefragt haben.

Es hat funktioniert, bis es nicht mehr funktionierte.

Angesichts von Millionen von Wallet-Adressen und Vertragsinteraktionen, die überwacht werden mussten, führte das Polling zu zwei Problemen, die wir technisch nicht umgehen konnten.

Latenz. Jeder Abfragezyklus führte zu einer Blocklatenz von etwa zwei Sekunden. Bei einem Produkt, bei dem der Zeitpunkt der Erkennung darüber entscheidet, ob ein Protokoll equipe rechtzeitig gewarnt wird, stellen zwei Sekunden ein strukturelles Problem dar und sind kein Problem der Leistungsoptimierung.

Skalierbarkeit. Unsere Beobachtungsliste mit überwachten Adressen wuchs stetig weiter. Wir speisten Blockchain-Daten in Apache-Flink-SQL-Pipelines ein, die auf AWS liefen, wobei dynamische Adresslisten im Arbeitsspeicher gespeichert wurden. Mit zunehmender Abdeckung traten regelmäßig „Out-of-Memory“-Fehler auf. Das System konnte nicht mit dem Umfang der zu überwachenden Daten Schritt halten. Und jede Änderung an der SQL-Pipeline erforderte einen vollständigen Neustart von Apache Flink, was jedes Mal bis zu 20 Minuten Ausfallzeit bedeutete.

Im schlimmsten Fall gaben wir monatlich 4.000 Dollar für AWS aus, um drei Ketten abzudecken, wobei drei bis vier Ingenieure dafür sorgten, dass die Pipelines am Laufen blieben. Das Fachwissen unseres „ equipe “ liegt im Bereich der Erkennungslogik. Wir haben es jedoch für die Infrastruktur ausgegeben.

Warum wir auf „Push Data“ umgestiegen sind

Die wesentliche Änderung bestand darin, das Polling-Verfahren durch ein Push-Modell zu ersetzen, das auf Quicknode Streams basiert.

Anstatt Daten von der Blockchain abzufragen, liegen diese bereits in dem Moment vor, in dem ein Block in die Blockchain aufgenommen wird. Die Block-Latenz sank von etwa zwei Sekunden auf unter 0,5 Sekunden. Telegram-Benachrichtigungen werden nun innerhalb von weniger als einer Sekunde nach der Erkennung ausgelöst. Das ist keine schrittweise Verbesserung. Es handelt sich um eine ganz andere Produktkategorie.

Doch die Latenz war nur ein Teil des Problems. Der größere Gewinn lag in der Upstream-Filterung.

Unsere alte Apache-Flink-Pipeline lief auf SQL. Die Erkennungslogik bestand aus einer einzigen großen Abfrage, die aus vielen Unterabfragen zusammengesetzt war – anfangs deklarativ zu schreiben, aber mit zunehmendem Umfang mühsam zu warten. Als wir auf Streams umstellten, haben wir auch unsere Erkennungslogik von SQL auf JavaScript umgestellt, wobei die Filter nun direkt im Blockchain-Knoten ausgeführt werden. Diese Umstellung brachte uns drei Vorteile:

Flexibilität. Jede Änderung an der Erkennungslogik wird ohne Ausfallzeiten in Betrieb genommen. Wir verfügen über eine umfassende Testsuite, die auf früheren DeFi-Vorfällen basiert und sicherstellt, dass unsere Logik auch bei Änderungen intakt bleibt. Mit den JS-Filter-Testtools von Quicknode können wir die gesamte Testsuite vor der Bereitstellung ausführen.

Wirtschaftlichkeit. Wir verarbeiten nicht mehr alle Blockchain-Daten. „ Streams “ übernimmt die Filterung auf Knotenebene und liefert nur die Daten, die wir benötigen. Der Bandbreitenbedarf ist deutlich gesunken.

Geschwindigkeit. Die Daten werden sofort übertragen, sobald ein neuer Block erscheint. Kein Abfrageintervall. Keine Round-Trip-Verzögerung.

Die Erkennungsarchitektur

So sieht unsere Pipeline derzeit aus.

Ein Block wird auf einer der acht von uns überwachten Blockchains erfasst. Streams filtert ihn auf Knotenebene mithilfe von JavaScript und leitet nur relevante Daten an nachgelagerte Systeme weiter. Der in Quicknode Streams integrierte Schlüssel-Wert-Speicher enthält unsere Beobachtungsliste mit Millionen von überwachten Adressen, auf die die JavaScript-Filter direkt zugreifen können. Die Logik zur Erkennung von Exploits wird auf die gefilterten Daten in unserem vorgelagerten Dienst angewendet. Bei einer Musterübereinstimmung wird eine Warnmeldung ausgelöst.

Der gesamte Vorgang dauert weniger als eine Sekunde.

Ein konkretes Beispiel: Durch die Auswertung von Transaktionsverläufen mit Streams können wir Versuche aufdecken, nicht initialisierte Proxy-Smart-Contracts mit einer Hintertür auszustatten. Dieses Angriffsmuster, das wir als CPIMP (Clandestine Proxy In the Middle of Proxy) bezeichnen, tritt auf, wenn ein Proxy bereitgestellt, aber nicht atomar in derselben Transaktion initialisiert wird. Diese Lücke ermöglicht es einem böswilligen Akteur, den Proxy zu übernehmen und einen böswilligen Implementierungs-Smart-Contract festzulegen. Um dies zu erkennen, müssen die Trace-Daten frühzeitig und schnell ausgewertet werden. „ Streams “ macht dies möglich.

Skalierung auf acht Ketten ohne Ops equipe

Wir haben Defimon zunächst auf drei Blockchains gestartet. Mittlerweile überwachen wir acht: Ethereum, BNB Smart Chain, Arbitrum, Base, Polygon, Avalanche, Optimism und HyperEVM.

Unter den bisherigen Rahmenbedingungen bedeutete das Hinzufügen einer Kette neue Infrastruktur, neue Server, neue Pipelines und mehr Personal. Jede Erweiterung stand in direkter Konkurrenz zur Erkennungsarbeit, was die Arbeitszeit der Entwickler betraf.

Bei „ Streams “ ist das Hinzufügen einer Chain lediglich eine Konfigurationsänderung. Die Integration von HyperEVM dauerte weniger als einen Tag. Wir haben einige Konstanten und relevante Adressen angepasst – das war bereits der Großteil der Arbeit.

Heute wird die gesamte Pipeline von einem einzigen Ingenieur betreut. Alle anderen konzentrieren sich auf die Erkennungslogik. Unter der alten Konfiguration waren drei bis vier Mitarbeiter allein dafür erforderlich, den Betrieb der Infrastruktur aufrechtzuerhalten.

Was passiert nach der Warnmeldung?

Defimon-Abonnenten halten nicht nur Ausschau nach Sicherheitslücken. Sie bauen auf der Grundlage unserer Warnmeldungen automatisierte Vorfallreaktionsprozesse auf. Je schneller die Warnmeldung erfolgt, desto mehr Zeit bleibt zum Handeln.

Ein Hedgefonds-Kunde, der eine DeFi-Position im neunstelligen Bereich verwaltet, hat sein System über WebSockets mit unserem System verknüpft, um Positionen automatisch zu schließen, sobald wir die ersten Anzeichen eines Angriffs auf die von ihm konfigurierten Protokolle erkennen. Privatanleger und Trader nutzen unsere Warnmeldungen, um ihre Positionen anzupassen, sobald ein laufender Vorfall identifiziert wird.

Der wichtigste Anwendungsfall ist jedoch das aktive Eingreifen durch „Whitehats“. Wir betreiben einen „Whitehat“-Bot, der insgesamt bereits mehr als 2 Millionen Dollar gerettet hat. Vor kurzem hat er 512.000 Dollar für einen Nutzer zurückgewonnen, der versehentlich seine Token-Zuteilungen falsch konfiguriert hatte. Wir konnten schnell genug reagieren, bevor böswillige Akteure davon Notiz nahmen. Die Geschwindigkeit der zugrunde liegenden Pipeline hat dieses Eingreifen erst möglich gemacht.

Abschluss

Jedes DeFi-Protokoll sollte in Echtzeit wissen, was mit seinen Kontrakten geschieht. In einer Zeit, in der KI das Ausmaß und die Raffinesse von Angriffen beschleunigt, ist das Erkennen früher Anzeichen eines Angriffs keine Option mehr. Es ist die Grundvoraussetzung.

Defimons Aufgabe ist es, die Warnmeldung so rechtzeitig auszulösen, dass die Teams noch Zeit haben, zu reagieren. Die Datenpipeline ist entweder das, was dies ermöglicht, oder das, was dem im Wege steht.

Wenn Ihr „ equipe “ immer noch auf Polling basiert, stellt sich nicht die Frage, ob die Latenz eine Rolle spielen wird, sondern wann. Eine Neuerstellung aus dem Quellcode ist mühsam. Aber das Flicken einer von Grund auf langsamen Architektur ist kein Weg zu einer Erkennung innerhalb von weniger als einer Sekunde. Für uns war die Umstellung auf ein Push-Modell keine technische Präferenz. Es war der einzige Weg, auf dem das Produkt tatsächlich funktionieren konnte.

Arseniy Reutov ist CTO und Mitbegründer von Decurity, einem Web3-Sicherheitsunternehmen, dem 1inch, Gearbox und die „ Arbitrum “-Stiftung ihr Vertrauen schenken. Defimon ist die Echtzeit-Plattform von Decurity zur Erkennung von Exploits, die acht EVM-Chains für mehr als 3.500 Abonnenten überwacht.