Comment nous détectons les failles de sécurité dans la DeFi en moins d'une seconde

Quicknode

21 avril 2026 — 7 min de lecture

Partager

Ajouter comme source préférée

Par Arseniy Reutov, directeur technique et cofondateur de Decurity Publié sur le blog « Quicknode »

J'ai passé plus d'une décennie à développer des systèmes de détection d'attaques ; d'abord dans le Web2, où j'ai travaillé sur l'analyse du trafic et les pare-feu d'applications Web (WAF), puis dans le Web3, où ces mêmes problèmes liés aux attaques se manifestent plus rapidement et où les enjeux financiers sont plus importants. J'ai cofondé Decurity en 2022. Nous auditons les protocoles DeFi et développons les outils permettant de les surveiller en production. Defimon est le volet « surveillance » : un système de détection d’exploits en temps réel auquel font confiance les équipes de protocoles, les entreprises de sécurité et les gestionnaires de risques sur l’ensemble des chaînes où la DeFi est réellement déployée. Il déclenche des alertes avant même que les piratages ne fassent la une des journaux. Sinon, c’est qu’il ne remplit pas sa mission. Développer une solution fonctionnant à cette vitesse, sur un tel nombre de chaînes, s’est avéré être un défi d’infrastructure plus complexe qu’un simple problème de sécurité. Voici ce que cette expérience nous a appris.

Pourquoi la vitesse de détection est un élément fondamental de la sécurité

Dans la DeFi, un protocole peut être entièrement vidé en une seule transaction atomique. Cependant, il existe très souvent un délai entre les premiers signes d’une faille et le vidage complet du protocole. L’incident Balancer. Le piratage de Yearn. Dans chaque cas, la question n’était pas de savoir si quelqu’un surveillait le protocole, mais s’il avait détecté ces premiers signes et réagi à temps.

Pour que la réponse automatisée aux incidents fonctionne, l'alerte doit arriver à temps pour permettre d'agir : suspendre des contrats, avertir les détenteurs de signatures multiples, transférer des fonds. Un retard de deux secondes dans le traitement des blocs peut sembler insignifiant. Au niveau du protocole, cela fait toute la différence entre un avertissement et un bilan a posteriori.

La rapidité de détection n'est pas une fonctionnalité. C'est le produit lui-même.

Le problème des sondages

Lorsque nous avons commencé à développer Defimon, nous récupérions les données de la chaîne de blocs de manière classique : par interrogation via RPC, en demandant sans cesse à la blockchain de nouveaux blocs, des transactions, des journaux et des traces.

Ça a marché jusqu'à ce que ça ne marche plus.

Avec des millions d'adresses de portefeuille et d'interactions avec des contrats à surveiller, le système d'interrogation a soulevé deux problèmes que nous n'avons pas pu contourner par des solutions techniques.

Latence. Chaque cycle d'interrogation ajoutait environ deux secondes de latence de blocage. Pour un produit où le délai de détection détermine si un « equipe » du protocole est averti à temps, ces deux secondes constituent un problème structurel, et non un simple problème d'optimisation des performances.

Évolutivité. Notre liste de surveillance des adresses surveillées ne cessait de s’allonger. Nous avons intégré les données de la blockchain dans des pipelines SQL Apache Flink fonctionnant sur AWS, avec des listes d’adresses dynamiques stockées en mémoire. À mesure que la couverture s’étendait, les erreurs de mémoire insuffisante sont devenues monnaie courante. Le système ne parvenait pas à s’adapter à l’ampleur de ce que nous devions surveiller. De plus, toute modification apportée au pipeline SQL nécessitait un redémarrage complet d’Apache Flink, entraînant à chaque fois jusqu’à 20 minutes d’indisponibilité.

Au pire, nous dépensions 4 000 dollars par mois sur AWS pour gérer trois chaînes, avec trois à quatre ingénieurs chargés d’assurer le bon fonctionnement des pipelines. L’expertise de notre equipe réside dans la logique de détection. Or, nous consacrions ces ressources à l’infrastructure.

Pourquoi nous avons opté pour Push Data

Le changement majeur a consisté à remplacer le modèle « polling » par un modèle « push » utilisant Quicknode Streams .

Au lieu de demander des données à la blockchain, celles-ci sont disponibles dès qu’un bloc est enregistré sur la chaîne. La latence des blocs est passée d’environ deux secondes à moins de 0,5 seconde. Les alertes Telegram se déclenchent désormais en moins d’une seconde après la détection. Il ne s’agit pas d’une simple amélioration progressive. C’est un produit d’une tout autre catégorie.

Mais la latence n'était qu'une partie du problème. Le principal avantage résidait dans le filtrage en amont.

Notre ancien pipeline Apache Flink fonctionnait sous SQL. La logique de détection reposait sur une seule grande requête composée de nombreuses sous-requêtes, facile à écrire au départ grâce à son caractère déclaratif, mais dont la maintenance devenait fastidieuse à mesure qu’elle prenait de l’ampleur. Lorsque nous sommes passés à Streams, nous avons également transféré notre logique de détection de SQL vers JavaScript, les filtres s’exécutant directement au sein du nœud de la blockchain. Ce changement nous a apporté trois avantages :

Flexibilité. Toute modification apportée à la logique de détection est mise en production sans temps d'arrêt. Nous disposons d'une suite de tests complète, élaborée à partir d'incidents DeFi passés, qui vérifie que notre logique reste intacte malgré les modifications. Les outils de test de filtres JS de Quicknode nous permettent d'exécuter l'intégralité de la suite avant le déploiement.

Économie. Nous ne traitons plus l'intégralité des données de la blockchain. Streams se charge du filtrage au niveau des nœuds et ne nous transmet que les données dont nous avons besoin. La bande passante a considérablement diminué.

Vitesse. Les données sont transmises dès qu'un nouveau bloc apparaît. Pas d'intervalle d'interrogation. Pas de délai aller-retour.

L'architecture de détection

Voici à quoi ressemble notre pipeline aujourd'hui.

Un bloc est enregistré sur l'une des huit chaînes que nous surveillons. Streams le filtre au niveau du nœud à l'aide de JavaScript, en ne transmettant en aval que les données pertinentes. Le magasin clé-valeur intégré à Quicknode Streams contient notre liste de surveillance, composée de millions d'adresses suivies auxquelles les filtres JavaScript peuvent se référer directement. La logique de détection des exploits s'applique aux données filtrées dans notre service en amont. Si un motif correspond, une alerte est déclenchée.

L'ensemble de la séquence se déroule en moins d'une seconde.

Un exemple concret : en analysant les traces de transactions à l’aide d’ Streams, nous pouvons détecter les tentatives d’introduction de portes dérobées dans des contrats intelligents proxy non initialisés. Ce modèle d’attaque, que nous appelons CPIMP (Clandestine Proxy In the Middle of Proxy), se produit lorsqu’un proxy est déployé mais n’est pas initialisé de manière atomique au cours de la même transaction. Cette faille permet à un acteur malveillant de prendre le contrôle du proxy et de mettre en place un contrat d’implémentation malveillant. Pour le détecter, il faut examiner les données de trace très tôt et très rapidement. C’est ce que permet Streams .

Évoluer vers huit chaînes sans équipe opérationnelle equipe

Nous avons lancé Defimon sur trois chaînes. Nous en surveillons désormais huit : Ethereum, BNB Smart Chain, Arbitrum, Base, Polygon, Avalanche, Optimism et HyperEVM.

Dans l'ancien système, l'ajout d'une chaîne impliquait la mise en place d'une nouvelle infrastructure, de nouveaux serveurs, de nouveaux pipelines et une augmentation des effectifs. Chaque nouvel ajout entrait en concurrence directe avec les tâches de détection pour le temps de travail des ingénieurs.

Avec Streams, l'ajout d'une chaîne se résume à une modification de configuration. L'intégration d'HyperEVM a pris moins d'une journée. Nous avons adapté certaines constantes et adresses pertinentes, ce qui a constitué l'essentiel du travail.

Aujourd'hui, l'ensemble du pipeline est géré par un seul ingénieur. Tous les autres se concentrent sur la logique de détection. Dans l'ancienne configuration, il fallait trois à quatre personnes rien que pour assurer le bon fonctionnement de l'infrastructure.

Que se passe-t-il après l'alerte ?

Les abonnés à Defimon ne se contentent pas de surveiller les failles. Ils mettent en place des processus automatisés de réponse aux incidents à partir de nos alertes. Plus l'alerte est rapide, plus ils disposent de temps pour agir.

Un client gestionnaire de fonds spéculatifs, gérant une position DeFi de plusieurs centaines de millions, s'est connecté à notre système via WebSockets afin de liquider automatiquement ses positions dès que nous détectons les premiers signes d'une attaque visant les protocoles qu'il a configurés. Les particuliers et les traders utilisent nos alertes pour ajuster leurs positions lorsqu'un incident en cours est identifié.

Le cas d'utilisation le plus significatif reste toutefois l'intervention active de type « white hat ». Nous exploitons un bot « white hat » qui a déjà permis de récupérer plus de 2 millions de dollars au total. Récemment, il a récupéré 512 000 dollars pour un utilisateur qui avait accidentellement mal configuré ses autorisations de jetons. Nous avons réagi suffisamment vite pour agir avant que les acteurs malveillants ne s'en aperçoivent. C'est la rapidité du pipeline sous-jacent qui a rendu cette intervention possible.

Clôture

Tout protocole DeFi doit savoir en temps réel ce qui se passe au niveau de ses contrats. À une époque où l'IA accélère le volume et la sophistication des attaques, détecter les premiers signes d'une attaque n'est pas une option. C'est une exigence minimale.

Le rôle de Defimon est de déclencher l'alerte suffisamment tôt pour que les équipes puissent réagir. Le pipeline de données peut soit faciliter cette tâche, soit la compliquer.

Si votre equipe fonctionne toujours en mode « polling », la question n’est pas de savoir si la latence aura une incidence, mais quand. Recompiler à partir du code source n’est pas une partie de plaisir. Mais appliquer des correctifs à une architecture fondamentalement lente ne permet pas d’atteindre une détection en moins d’une seconde. Pour nous, le passage à un modèle « push » n’était pas un simple choix technique. C’était la seule façon de garantir le bon fonctionnement du produit.

Arseniy Reutov est directeur technique et cofondateur de Decurity, une entreprise spécialisée dans la sécurité Web3 à laquelle font confiance 1inch, Gearbox et la Fondation Arbitrum . Defimon est la plateforme de détection d'exploits en temps réel de Decurity, qui surveille huit chaînes EVM pour plus de 3 500 abonnés.