L'IA comme « méchant » : les assurances DeFi ont besoin d'un test de résistance

Effectuer un test de collision sur les coffres DeFi : Firelight prévoit d'utiliser l'IA pour trouver le « prochain accident ».

Rédigé par : @jrdothoughts

Traduit par : AididiaoJP, Foresight News

Les angles morts de l'assurance DeFi : ne pas avoir explosé ne signifie pas être en sécurité

Écoutez d'abord une vente humoristique noire : « Notre nouvel avion est absolument sûr, il n'a jamais eu d'accident. »

« Depuis combien de temps vole-t-il ? »

« ... Environ deux fois. »

Remplacez l'avion par un coffre DeFi, et l'histoire devient familière : six mois de retraits sans problème, pas d'attaques, des rendements plutôt bons. C'est bien sûr une preuve. Mais pendant ces six mois, a-t-il rencontré des problèmes de congestion réseau, des liquidités qui se retirent en masse, ou des oracles qui ne se mettent pas à jour ? Très probablement non.

Un historique propre ne montre que ce qu'un système a supporté. L'assurance doit se demander : que pourrait-il rencontrer ensuite ?

C'est l'opportunité que voit Firelight : établir des prix en fonction de la manière dont les pertes se forment, et pas seulement en fonction de la survenue des pertes. L'histoire sert d'ancre, la simulation explore des scénarios alternatifs, l'IA identifie les faiblesses, et le capital garantit.

L'histoire est un instantané, mais le système peut changer

Les données historiques sur les pertes sont un instantané du fonctionnement d'une machine dans certaines conditions. Si la machine change, l'instantané doit être réévalué.

Un coffre qui ajoute un type de collatéral, change d'oracle, et augmente son levier. Le nom reste le même, le logo ne change pas, mais le risque est déjà très différent. Les emprunteurs, liquidateurs et LP à l'intérieur ne sont pas des chiffres immobiles dans un tableau. Ils réagiront aux incitations, et en cas de problème, ils voudront tous sortir par la même porte.

C'est comme une carte de circulation dessinée selon les habitudes de circulation d'un mardi ordinaire. Elle semble précise, mais dès qu'un pont principal est fermé, elle devient inutile. La carte elle-même n'est pas mal dessinée, c'est la situation qui a changé.

Ainsi, pour Firelight, la véritable question n'est pas seulement « ce protocole a-t-il été piraté ? », mais : quelles autorisations existent ? Quelles dépendances sont réellement importantes ? Quand tout le monde se précipite pour sortir, quels chemins de liquidation restent ouverts ? Le cadre public de Firelight a déjà séparé les vulnérabilités techniques des fragilités économiques, au lieu de les amalgamer en un score de sécurité.

L'assurance concerne la structure actuelle du système et ses relations de dépendance, et non le nom de marque qu'il a conservé jusqu'à présent.

Les assureurs de catastrophes ont déjà écrit le scénario

Les compagnies d'assurance traditionnelles n'ont pas abandonné la modélisation de l'incertitude. Les assureurs de catastrophes font une chose : simuler comment les catastrophes se produisent, quels actifs seront exposés, à quel point la structure est fragile, et combien le contrat devra finalement indemniser. Les ouragans passés ne représentent pas tous les ouragans qui pourraient survenir à l'avenir.

DeFi a également besoin de son propre modèle de catastrophe. Sauf que la catastrophe passe d'un ouragan à une défaillance d'oracle, les victimes passent de bâtiments à des positions de prêt, la fragilité passe de la qualité de construction à la marge de collatéral et à la conception de liquidation, et enfin, les paiements sont calculés selon les termes de couverture.

Le modèle de catastrophe pose la question : que se passe-t-il lorsqu'un ouragan balaie une ville ? Le modèle DeFi demande : que se passe-t-il lorsqu'une défaillance se propage le long d'un graphique de dépendance ?

Firelight a discuté publiquement de la décomposition des risques, de l'étalonnage historique, de la simulation de Monte Carlo, des modèles linguistiques et de l'apprentissage par renforcement, le tout intégré dans un laboratoire de tests de collision financière. Il convient de préciser qu'il s'agit d'une direction proposée, et non d'une affirmation selon laquelle chaque élément est déjà en ligne.

Un autre point à préciser : Firelight définit son produit comme une couverture basée sur des protocoles, et non comme un contrat d'assurance traditionnel. Les comparaisons faites avec l'assurance concernent la discipline de couverture, sans impliquer la qualification juridique du produit.

Comment construire un laboratoire de tests de collision financière

La première étape consiste à fixer l'état initial pour garantir la reproductibilité. La version du contrat, les soldes, les positions de collatéral, ainsi que les réglages d'oracle, les règles de liquidation et la liquidité du marché doivent tous être verrouillés. Sinon, deux résultats de simulation ne correspondront pas, simplement parce que le point de départ est différent, et ce n'est pas le même système qui est mesuré.

La deuxième étape consiste à séparer l'exécution et les hypothèses. Les forks de blockchain peuvent exécuter la logique des contrats réels, mais ils ne peuvent pas générer de manière aléatoire la liquidité de demain, les prix hors chaîne et le comportement humain. Ceux-ci doivent être modélisés explicitement. Les tests basés sur des forks et des agents pilotés ont déjà des précédents dans la recherche DeFi.

La troisième étape consiste à organiser divers participants dans l'environnement de simulation. Les emprunteurs, liquidateurs, déposants et LP ont tous des limites de fonds et des incitations. Mais il ne faut donner à personne le rôle principal : les liquidateurs ne doivent pas effectuer des transactions déficitaires juste pour obtenir une fin satisfaisante. Les rôles ne doivent pas tous utiliser de grands modèles de langage ; des règles simples et transparentes peuvent parfois être meilleures, plus rapides et plus faciles à reproduire. Les échecs techniques doivent toujours être gérés par des tests de fuzzing, des revues de code et des injections de pannes, ces méthodes étant parallèles à la simulation économique, et non substitutives.

La quatrième étape consiste à provoquer des perturbations. Les sauts de prix, les retards de mise à jour des oracles, l'amincissement de la liquidité et les interruptions d'exécution doivent tous être testés. Il ne suffit pas de modifier l'amplitude, il faut aussi changer l'ordre. Les LP qui retirent leur liquidité avant un choc de prix et ceux qui le font après peuvent avoir des résultats complètement différents.

Ce que la simulation doit finalement fournir, ce n'est pas un score de sécurité général, mais une chaîne de pertes : quelle position échoue en premier, combien est récupéré, et comment le manque se propage. Avec cette chaîne, il devient possible de déterminer les limites de couverture et les exigences en capital, ou simplement de donner une réponse « non couvert ».

Laisser l'IA jouer le rôle du « méchant », mais sans changer les lois de la physique

L'utilisation la plus intuitive de l'IA est de lire le code et la documentation. Les modèles linguistiques peuvent clarifier les dépendances, expliquer les mises à jour et proposer des scénarios d'échec. Mais une histoire qui semble crédible ne signifie pas qu'une vulnérabilité a été trouvée, elle nécessite toujours des preuves.

Plus intéressant encore, c'est de laisser l'IA chercher activement divers scénarios possibles. La simulation de Monte Carlo échantillonne à partir de distributions prédéfinies, ce qui est bien sûr utile ; mais les combinaisons réellement mauvaises peuvent être trop rares, et l'échantillonnage aléatoire ne fait souvent que redécouvrir des situations ordinaires.

Les tests de résistance adaptatifs fonctionnent à l'envers : les agents choisissent des facteurs de perturbation dans le simulateur, cherchant activement des chemins d'échec crédibles. Dans les tests de conduite autonome, des gens ont déjà démontré cette approche avec l'apprentissage par renforcement. Les agents peuvent changer la météo, mais ne peuvent pas réécrire les lois de la physique.

Dans la configuration proposée par Firelight, les agents peuvent ajuster les retards d'oracle, les retraits de liquidité et le taux de présence des liquidateurs dans les limites de la réalité. Trouver des chemins destructeurs est récompensé, tricher est puni. Un méchant avec un capital illimité et des pouvoirs divins n'est pas un modèle d'assurance utile.

Ensuite, laissez l'IA regrouper les trajectoires d'échec, sélectionnant les prochaines expériences qui réduisent le plus l'incertitude. Des centaines de catastrophes apparemment différentes peuvent partager le même goulet d'étranglement de liquidation. C'est là que réside la valeur d'action.

La vitesse est également importante. Les méthodes d'approximation à faible coût filtrent d'abord de nombreux scénarios, puis des tests d'exécution coûteux sont effectués dans plusieurs environnements de test indépendants pour reproduire des scénarios importants. Mais les raccourcis doivent être vérifiés. Accélérer un simulateur erroné ne fera que le rendre plus confiant dans ses erreurs.

L'IA joue le rôle de conducteur dans les tests adverses, et non de juge de sécurité. Elle indique ce qu'il faut vérifier, tandis que le moteur d'exécution, les experts du domaine et les preuves déterminent si cette découverte est valable.

De la trajectoire de perte aux termes de couverture

Imaginons un coffre de prêt hypothétique : le prix des collatéraux chute, les LP se retirent en masse, et les mises à jour des oracles sont retardées. Bien que les liquidateurs interviennent, le glissement a englouti la valeur récupérée, et finalement, la dette de l'emprunteur dépasse le prix réel auquel le collatéral peut être vendu.

Faisons quelques comparaisons : laissons le prix chuter ; retirons la liquidité en même temps que le prix chute ; combinons plusieurs facteurs. Cela permet de voir si la véritable faiblesse réside dans le prix, dans la profondeur du marché, ou dans l'interaction entre les deux.

Supposons qu'une exécution d'exemple génère 2 millions de dollars de pertes admissibles, avec une franchise de 500 000 dollars et une limite de couverture de 1 million de dollars. La couche de franchise absorbe 500 000, supposons que la couverture indemnise 1 million, il reste 500 000 en dehors de la limite.

Ce sont des exemples de clauses fictives, pas une offre de Firelight, et pas des résultats de simulation réels. L'admissibilité, la récupération, les exclusions et la couverture chevauchante doivent encore être clarifiées.

L'essentiel est que : avoir une perte économique ne signifie pas qu'on peut obtenir une indemnisation. La simulation n'est réellement utile que si elle influence la décision de couverture - par exemple, en abaissant la limite de couverture, en exigeant un contrôle des risques plus strict, en conservant plus de capital, ou en refusant simplement la couverture. Peu importe à quel point l'animation de la catastrophe est bien faite, ce n'est pas encore une décision financière.

Trouver des chemins d'échec ne signifie pas calculer des probabilités

Supposons qu'un agent adversaire ait réussi à percer le système dans 30 % des tests. Cela signifie-t-il que le système a une probabilité d'échec de 30 % ? Pas nécessairement. Cet agent est spécifiquement conçu pour trouver des vulnérabilités.

Découvrir un échec répond à la question « comment cela pourrait-il mal tourner, à quel point cela pourrait-il mal tourner ? ». Estimer une probabilité répond à la question « quelle est la fréquence d'apparition de ces conditions pendant la période de couverture ? ». Confondre les deux, c'est créer une fausse précision.

Conceptuellement, le paiement attendu est le montant de l'indemnisation pour chaque scénario, multiplié par la probabilité d'apparition de ce scénario, puis additionné. Ces probabilités doivent être soutenues par des preuves, et les hypothèses doivent être clairement énoncées. En l'absence d'estimations fiables, il faut utiliser des intervalles, des limites conservatrices et des contraintes de pression, plutôt que d'inventer des chiffres précis.

Le paiement attendu n'est pas égal à la totalité des primes. Le capital doit également couvrir les risques extrêmes, les coûts d'exploitation et l'incertitude, et les risques extrêmes sont souvent très difficiles à gérer. Au niveau du portefeuille, des dépendances partagées peuvent également déclencher simultanément des paiements sur plusieurs contrats.

Le cadre de capital public de Firelight a déjà pris en compte la concentration et le retrait de collatéral. La simulation doit également tester les deux extrêmes : d'une part, une augmentation des réclamations, et d'autre part, un soutien des actifs qui se déprécient simultanément, voire deviennent plus difficiles à vendre. Si un grand désastre survient et que le capital se réduit également, le pool de couverture ne peut pas être estimé uniquement sur la base de la perte moyenne.

Qui teste la « machine à tester » ?

Un simulateur peut être logiquement cohérent, mais ses conclusions peuvent être complètement erronées. Exécuter un million de fois avec des paramètres de liquidateur irréalistes ne fait que répéter la même erreur un million de fois. Exécuter plusieurs fois peut réduire l'erreur d'échantillonnage, mais l'erreur du modèle lui-même ne diminuera pas automatiquement.

Un laboratoire fiable fera quatre choses : examiner des événements connus, tester avec des données hors échantillon, comparer des modèles construits indépendamment par différentes équipes, et ajuster les hypothèses sur le comportement des participants. Les instantanés, les graines aléatoires et les enregistrements d'exécution doivent être archivés, afin que les découvertes clés puissent être reproduites. Il faut aussi se poser la question : ce que l'IA a trouvé, ce sont les faiblesses du protocole ou un bug du simulateur ?

Aucun test ne peut prouver qu'il a trouvé tous les chemins de catastrophe. C'est précisément en raison des dépendances inconnues et des comportements jamais vus qu'il faut des réserves de capital, des exclusions et une retenue en matière de couverture.

Les limites du contrat doivent également être clairement définies. De nouvelles preuves peuvent influencer la tarification et la capacité futures, mais ne devraient pas transformer la couverture existante en cible mobile. Le cadre public de Firelight traite séparément la surveillance continue des risques et les taux fixes pendant la période de couverture. L'apprentissage continu et le respect des engagements peuvent coexister ; mais modifier les engagements après l'apparition d'un danger n'est pas acceptable.

Conclusion : apprendre avant que les pertes n'apparaissent

La plus grande valeur réside dans l'intégration de la couverture dans le processus de développement. Lorsqu'un changement majeur se produit dans le système, des tests correspondants sont déclenchés ; les résultats des tests influencent les nouvelles décisions de couverture ; les événements réels aident à améliorer la prochaine version du modèle. Plus le travail est bien fait, plus cela se reflétera finalement dans les prix de couverture et leur disponibilité.

Les réclamations historiques sont des leçons tirées après coup. La simulation permet à Firelight de comprendre à l'avance comment ce système pourrait échouer.

L'IA est responsable d'élargir le champ de recherche, les preuves contraignent ses conclusions, et le capital est responsable de tenir ses promesses. L'objectif n'est pas de prédire chaque catastrophe, mais de comprendre ce à quoi on pourrait faire face, puis d'investir du capital pour supporter les pertes inévitables.