Gains :
- Capacité à comprendre les éléments constitutifs de DeFi tels que l'AMM, le pool de liquidité, le prêt Oracle et Flash et à utiliser l'intelligence artificielle dans l'explication des mécanismes et la rédaction de scénarios.
- Être capable de distinguer que la plupart des risques DeFi sont des vulnérabilités de logique économique/commerciale, et non des bugs de code, et que l'intelligence artificielle est faible dans la vulnérabilité économique d'origine
- Être capable de comprendre que la sécurité économique se prouve par la simulation, pas par la réflexion, et que la dépendance aux oracles est le point le plus fragile.
DeFi (Decentralized Finance) est le domaine de valeur la plus élevée et le plus attaqué du Web3. Les échanges, les protocoles de prêt, les pools de liquidités fonctionnent tous comme du code et déplacent tous des millions de dollars dans un environnement hostile. Dans cette unité, nous utiliserons l’IA comme assistant d’analyse de protocole ; Nous apprendrons à comprendre la liquidité, les prix, le MEV et les attaques économiques, ainsi que les domaines dans lesquels l'IA est utile et inadéquate dans ce domaine contextuel.
Éléments de base de DeFi
- AMM (Automated Market Maker) : mécanisme d'échange qui fixe les prix selon une formule (par exemple x·y=k) plutôt que de faire correspondre les acheteurs et les vendeurs.
- Pool de liquidité : un fonds commun dans lequel les utilisateurs déposent des jetons et effectuent des échanges.
- Protocole de prêt : emprunt contre garantie ; La liquidation se produit lorsque la valeur de la garantie diminue.
- Oracle : la source de données qui apporte le prix mondial extérieur au protocole – la dépendance la plus critique et la plus fragile de DeFi.
- Prêt Flash : Un prêt contracté sans garantie en une seule transaction et restitué au cours de la même transaction ; Il a à la fois des utilisations légitimes et un outil d’attaque.
MEV et attaques économiques
MEV (Maximal Extractable Value — la valeur extraite par l'autorité pour commander/ajouter/supprimer des transactions) est une classe de risque spécifique à DeFi. Les transactions en attente apparaissent dans le pool public (mempool) ; Cette visibilité ouvre la porte aux attaques suivantes :
- Front-running : Voir une transaction rentable et insérer sa propre transaction devant celle-ci.
- Attaque sandwich : effectuer des transactions avant et après l'achat de la victime et profiter de la différence de prix.
- Manipulation d'Oracle : Tromper le protocole en modifiant instantanément le prix d'un pool, généralement avec un prêt flash.
Ces attaques ne proviennent pas du « bug » du code, mais de l’exploitabilité de la conception économique. C’est là que l’IA rencontre le plus de difficultés : une IA qui sait analyser le code technique ne peut souvent pas détecter une vulnérabilité économique spécifique au protocole.
Attention : La majorité des vulnérabilités DeFi ne sont pas des « bugs de code » mais des vulnérabilités de logique économique/métier. L'analyse de code standard de l'IA ne les oublie pas ; C’est le domaine qui requiert le plus d’expertise humaine, de simulation et de modélisation.
Le rôle de l'IA dans l'analyse DeFi
1. Description du mécanisme. L’IA est puissante pour expliquer en langage simple le fonctionnement d’un protocole complexe (par exemple un AMM basé sur une courbe). Cela permet une entrée rapide dans l’analyse.
2. Générer un scénario/contre-hypothèse. "A quel mouvement de prix ce protocole de dette entrera-t-il dans une crise de liquidation ?" L'IA produit des ébauches de scénarios avec des questions telles que : ceux-ci sont testés par simulation.
3. Rappel des modèles d'attaque connus. L’IA évoque les schémas des attaques DeFi passées (manipulation d’oracle, réentrée, spirale de liquidation) comme une liste de contrôle.
4. Ébauche du plan de simulation. L’IA peut élaborer un plan pour quels scénarios tester ; mais la simulation elle-même se fait avec l'outil (Foundry, Tenderly).
Invite faible/Invite forte
Invite faible :
Ce protocole DeFi est-il sûr ?
Invite puissante :
Votre rôle : analyste du protocole DeFi. Examinez le mécanisme du protocole ci-dessous. Considérons un à un les vecteurs d’attaque économique suivants : manipulation d’oracle (avec prêt flash), sandwich/front-running, spirale de liquidation, effet de retrait de liquidité. Pour chaque vecteur : comment déclencher, quelle condition est requise, impact possible. Ce sont les hypothèses à tester PAR SIMULATION ; Ne dites pas « sécurisé/dangereux » avec certitude. GÉNÉRER le code d'attaque réel ; Décrivez le risque à des fins défensives uniquement.
Quatre modèles copiables
1) Description du mécanisme :
Expliquez en langage simple, étape par étape, le mécanisme de tarification/liquidité de ce protocole : que se passe-t-il lorsqu'un utilisateur effectue une transaction, comment le prix est-il déterminé, quelles sont les dépendances externes ? Marquez la partie que vous ne comprenez pas ou que vous laissez floue.
2) Surface d’attaque économique :
Cartographier la surface d'attaque économique de ce protocole : quelles hypothèses peuvent être exploitées en oracle, liquidité, collatéral, liquidation, gouvernance ? Écrivez chaque risque avec une condition (« et si »). Présentez-le comme une hypothèse à confirmer par simulation.
3) Scénario de stress :
Considérez les scénarios suivants : si le jeton de garantie chute de 50 %, si le prix de l'oracle s'écarte momentanément de 30 %, si 80 % de la liquidité est retirée, quel sera le protocole ? Notez les répercussions de chaque scénario. Ne prétendez pas à la précision numérique ; Précisez que la simulation est requise.
4) Correspondance du modèle d'attaque de l'historique :
La conception de ce protocole comporte-t-elle des conditions similaires à celles des modèles d'attaque DeFi connus (par exemple, oracle à source unique, prix d'ouverture du prêt flash) ? Souligner les similitudes à des fins défensives ; Ne franchissez pas l'étape d'exploitation, cela ne fera que produire un point d'attention.
Trois mini-cases (en chiffres)
Cas 1 : Le risque Oracle est détecté tôt. Une équipe concevait un nouveau protocole de dette. Lors de l'explication du mécanisme, YZ a émis l'hypothèse selon laquelle "le prix provient d'un seul pool et peut être manipulé avec des prêts flash". L'équipe l'a confirmé dans la simulation et est passée à TWAP + multi-sourcing. Perte estimée évitée : la totalité de la valeur verrouillée du protocole. Leçon : L'IA est précieuse pour évoquer des modèles connus.
Cas 2 – L'IA a raté la vulnérabilité d'origine. Dans un autre protocole, la vulnérabilité était une erreur économique unique résultant de l'interaction de deux mécanismes (récompense + liquidation). L'IA a trouvé chaque mécanisme « impeccable » un par un ; Je n'ai pas pu voir l'interaction. Modeleur humain et simulation capturés. Leçon : si les composants sont bons, l’économie de l’ensemble constitue le point aveugle de l’IA.
Cas 3 — Le plan de simulation a permis de gagner du temps. Un analyste a rédigé 15 scénarios de stress différents dans l’IA au lieu de les planifier à la main ; puis je l'ai exécuté à Foundry. La planification est passée de 1 jour à 2 heures ; mais l'interprétation des résultats et la décision appartenaient à l'homme. Leçon : plans d'IA, mesures des véhicules, décisions humaines.
Le caractère indispensable de la simulation
Dans DeFi, la sécurité ne se prouve pas par la « réflexion » ; Il est testé par simulation. La robustesse économique d’un protocole peut être comprise en exécutant numériquement différents scénarios de prix, de liquidité et d’attaque. L’IA peut planifier et rédiger le code de ces simulations ; mais ce sont les outils et les personnes qui produisent et interprètent les résultats. L’énoncé « probablement durable » produit par l’IA n’est pas un résultat de simulation et ne peut être présenté comme tel.
Astuce : Lorsque vous recevez une évaluation des risques DeFi de l'IA, vous devez demander à chaque hypothèse « avec quelle simulation dois-je tester cela ? Transformez-le en question. Une affirmation de sécurité qui ne peut pas être testée n’est pas une garantie dans DeFi.
Erreurs courantes
- Scanner le déficit économique comme un bug de code. Les risques DeFi relèvent principalement de la logique métier.
- Faire confiance à l'IA pour dire « sûr » et ignorer la simulation. Des tests sont nécessaires.
- Valider les composants un par un et ignorer les interactions. L’économie dans son ensemble est critique.
- Faire confiance à Oracle à partir d'une source unique. Le désastre DeFi le plus courant.
- Ignorer MEV/front-running. Oublier le fait du pool de mémoire public.
- Génération de code d'exploitation. Seule une analyse défensive est légitime.
En résumé
- DeFi est un espace hostile et de grande valeur ; Les risques relèvent principalement de la logique économique/commerciale.
- MEV, front-running, sandwich et oracle manipulation sont des classes d’attaques spécifiques à DeFi.
- L'IA est forte dans l'explication des mécanismes et la rédaction de scénarios ; Le déficit économique initial est faible.
- La sécurité économique se prouve par la simulation et non par la réflexion ; Plans d'IA, mesures des véhicules.
- La dépendance à Oracle est le point le plus vulnérable de DeFi ; plusieurs ressources et TWAP requis.
Tâche de candidature
Choisissez un AMM ou un protocole de prêt (avec une documentation claire). Appliquez les invites « description du mécanisme » et « surface d’attaque économique » à l’IA. Pour chaque hypothèse de risque produite par l’IA, « avec quelle simulation devrais-je tester cela ? Répondez à la question. Recherchez ensuite le rapport d'audit réel de ce protocole et comparez les résultats réels avec les risques signalés par l'IA : qu'est-ce que l'IA a capturé, qu'a-t-elle manqué ?
liste de contrôle
- [ ] J'ai discuté des risques en deux dimensions : code + économie.
- [ ] J'ai évalué MEV/front-running.
- [ ] J'ai également examiné la dépendance Oracle.
- [ ] J'ai remis en question l'interaction des composantes (l'économie dans son ensemble).
- [ ] J'ai relié chaque hypothèse à un plan de simulation.
- [ ] J'ai remplacé le "coffre-fort" de l'IA par la simulation.
- [ ] Je n'ai analysé qu'à des fins défensives.