📝 Salut tout le monde, je suis 𝟏𝟎, pour être honnête, j'ai un peu peur. Ce n'est jamais la technologie en elle-même qui m'inquiète, mais plutôt que nous continuons à utiliser de vieilles stratégies de défense face à un nouvel adversaire déjà armé par l'IA.

Les données parlent d'elles-mêmes : au premier trimestre 2026, les attaques sur DeFi atteindront un nouveau sommet ; au deuxième trimestre, à peine commencé, nous sommes déjà proches du pic. Dans le passé, je pensais que les attaques de niveau étatique étaient un peu exagérées, mais avec KelpDAO, Step Finance et WazirX, ce risque devient de plus en plus concret.

KelpDAO est un exemple typique. Le problème ne réside pas dans une vulnérabilité de code, mais dans l'héritage. Ils ont utilisé la configuration par défaut de LayerZero, qui permet à un seul valideur de confirmer les messages inter-chaînes, et qui n'est pas soumis à un audit. Le résultat est que 292 millions de dollars ont disparu en un temps record.

Les risques actuels ne concernent plus seulement les erreurs de code, mais aussi le fait que tu ignores peut-être les risques que tu as hérités.

👇👇👇

Un, depuis l'arrivée de l'IA, l'attaque et la défense ne sont plus équilibrées.

Avant, je pensais que tant que l'audit était suffisant, que les multi-signatures étaient sécurisées, et avec des mesures comme des contrats de temps, tout était déjà stable et je me sentais tranquille.

Mais maintenant, la situation a un peu changé, les humains pourraient passer des semaines à examiner minutieusement les configurations de centaines de protocoles ; mais l'IA peut accomplir ce travail en quelques heures. Et des IA comme Mythos d'Anthropic peuvent même transformer une vulnérabilité connue en un outil d'attaque exploitable en moins de 24 heures, pour moins de 50 dollars.

Cela a en fait entraîné deux changements très réels :

Premièrement, les vulnérabilités que tu pensais être difficilement détectables peuvent maintenant être trouvées en masse par l'IA.

Deuxièmement, pendant que tu essaies d'éviter toutes les vulnérabilités, les attaquants utilisent déjà l'IA pour scanner à grande échelle.

Donc, je penche de plus en plus vers une approche plus pragmatique : plutôt que de supposer que le système est forcément sûr, mieux vaut partir du principe qu'il sera attaqué tôt ou tard. Il est plus important de penser à comment arrêter rapidement les pertes en cas de problème.

En d'autres termes : plutôt que de tout bloquer à tout prix, réfléchis à comment minimiser les pertes si une porte est ouverte.

Deux, le plus effrayant n'est pas la vulnérabilité du contrat, mais la vulnérabilité humaine.

Cette phrase n'est pas de moi, c'est ce que les données nous disent. D'ici le premier trimestre 2026, les pertes dans l'ensemble de l'industrie dues au phishing et aux attaques d'ingénierie sociale représenteront plus de 65%, soit environ 306 millions de dollars.

Par exemple, dans l'affaire de WazirX de 230 millions de dollars, le problème ne résidait pas dans le contrat intelligent lui-même, mais dans la clé privée de l'administrateur du portefeuille multi-signatures qui a été volée. Une fois que l'attaquant a obtenu les droits, il a directement modifié la logique du portefeuille.

En d'autres termes : le contrat est sécurisé, le processus est bien conçu, mais si une personne ayant des droits est dupée ou compromise, alors tout est perdu.

Ne te fie pas seulement à un portefeuille multi-signatures, sépare les fonds en fonction de leur utilisation, utilise différentes structures multi-signatures pour contrôler les risques. Et un point encore plus crucial : ne mélange pas les clés avec tes appareils quotidiens.

Si ton ordinateur ou ton téléphone se connecte à Internet, reçoit des mails, utilise Slack, ou clique sur des liens suspects, ces appareils ne peuvent plus être considérés comme des environnements sûrs.

Pour faire simple : tant qu'il est connecté à Internet, considère qu'il y a un risque. Ça peut sembler exagéré, voire un peu trop prudent. Mais à ce stade, la sécurité, c'est être un peu méfiant, c'est juste un niveau normal.

Troisièmement, le kill switch n'est pas un gadget, c'est ton dernier frein.

Beaucoup de gens pensent que le kill switch n'est utilisé qu'en dernier recours, mais en réalité, il devrait être conçu dès le départ.

Pour être franc : plus ton chemin de sortie est large, plus ta limite de perte est grande. Une fonction de mint sans limite de bloc, c'est comme donner un chèque en blanc pour un bug d'impression illimitée.

De plus, le kill switch ne doit pas seulement être sur l'UI. Tu dois avoir un script qui gèle tous les mouvements de valeur d'un seul coup, exécuté de manière atomique. Et avant d'appuyer, il vaut mieux avoir un système d'alerte déjà en place, un moniteur hors chaîne surveillant tes invariants. Dès qu'ils sont brisés, il faut passer à l'escalade humaine.

Pourquoi insister sur l'humain, c'est parce que l'IA peut détecter, mais la décision finale doit encore être prise par un humain. Personne ne veut laisser un algorithme décider si des fonds de plusieurs milliers ou millions de dollars doivent être gelés.

Quatre, un concept technique que j'apprécie : les invariants.

Une variable est une règle que tu établis dans la conception du système, peu importe ce qui se passe, elle doit toujours être respectée. Par exemple : dépôt total ≤ dettes totales.

Tu peux coder ces règles, pour que le système vérifie automatiquement après chaque fonction clé. Si cette règle est brisée, le système s'arrête immédiatement ou signale une erreur, sans continuer à exécuter les transactions.

De nombreuses attaques DeFi (comme les prêts flash ou les oracles manipulés) reposent sur le fait que l'attaquant a altéré le processus d'exécution de la fonction, plongeant le système dans un état erroné pendant un temps très court.

Mais si tu vérifies les invariants dans l'état final, même si des modifications ont eu lieu en cours de route, il doit revenir à un état valide à la fin, sinon c'est échec direct. Tu peux entrer, mais tu ne peux pas sortir avec un résultat erroné.

Bien sûr, avoir trop d'invariants n'est pas nécessairement mieux. Si tu veux tout restreindre, le système devient rigide, et même les opérations normales ne peuvent pas être effectuées.

Une bonne pratique est de ne choisir que les deux ou trois règles clés, comme la sécurité des fonds et l'équilibre des actifs, comme objets de protection prioritaires.

Ensuite, utilise une vérification formelle ou des tests de fuzzing d'état pour les valider, cela couvre généralement la plupart des risques.

Cinq, l'essence de la sécurité est de laisser de l'espace pour le contrôle.

Je pense de plus en plus que la sécurité n'est pas une affaire d'audit unique ou d'un rapport. C'est plutôt un processus qui doit tourner tous les jours, avec une vigilance constante.

Il y a une phrase qui dit très bien : l'absence de preuves de piratage ne signifie pas que tu ne seras pas piraté. Le plus grand danger n'est souvent pas la vulnérabilité elle-même, mais le moment où tu penses que tout va bien.

Donc, mon état d'esprit actuel est le suivant : accepte que tu seras piraté, mais ne te laisse pas emporter par une seule vague. Pense à l'avance, fais des exercices, prépare ton portefeuille de gardiens, et liste les processus de négociation et de suivi. Ce n'est pas pour être parfait, mais pour le jour où cela arrive réellement, tu ne seras pas pris au dépourvu.

On ne cherche pas à éviter les problèmes à tout prix, mais à rester stable quand ils surviennent.