L'IA réduit considérablement le coût de la recherche de vulnérabilités, l'industrie de la cryptographie se divise en deux camps pour y faire face

By: foresightnews.pro|26/10/2026 08:01:08

La cryptographie se divise en deux voies de sécurité : le patching agile et l'immuable minimaliste.

Rédaction : @Bankless

Compilation : AididiaoJP, Foresight News

La capacité de l'IA à détecter des vulnérabilités est devenue si forte que l'industrie de la cryptographie doit réorganiser ses stratégies de sécurité.

Commençons par le réseau Bitcoin. Le 22 octobre, Bitcoin Core a fusionné un changement de stratégie de sécurité spécifiquement pour les vulnérabilités qui peuvent être découvertes par un simple prompt donné à un LLM (modèle de langage de grande taille). Auparavant, ce type de problème pouvait rester confidentiel pendant un an ; maintenant, les corrections et les publications doivent être accélérées. L'auteur du changement, Antoine Poinsot, a été très clair : les LLM « abaissent considérablement le seuil de découverte de certains types de problèmes ».

Ce n'est pas un cas isolé. Deux vulnérabilités critiques en PHP découvertes grâce à des modèles d'IA ont mis environ 1,3 million d'hôtes exposés sur Internet en danger. Initia a suspendu l'ensemble du réseau : des attaquants ont utilisé ce que le cofondateur Zon a appelé un « bug de jour 0 » pour frapper et transférer environ 2,7 millions de dollars entre chaînes. Il n'est pas encore possible de confirmer si cette attaque a utilisé l'IA, mais dire qu'elle y a participé dans une certaine mesure ne semble pas exagéré.

Les données vont également dans le même sens. La base de données des incidents de piratage de DefiLlama montre qu'il y a eu 112 attaques dépassant 1 million de dollars en 2026 jusqu'à présent ; en 2025, il y en avait 70. La recherche sur les contrats intelligents d'Anthropic a également révélé qu'en 2025, les modèles de pointe dans des environnements simulés avaient des « revenus d'exploitation de vulnérabilités » qui doublent environ tous les 1,3 mois.

Que faire lorsque les attaquants disposent de chasseurs de vulnérabilités infatigables et en constante évolution ? L'industrie de la cryptographie est en train de dégager deux réponses très différentes.

Camp agile : pouvoir modifier et arrêter à tout moment

La première réponse est de rester flexible : pouvoir rapidement appliquer des correctifs et également freiner rapidement.

Starknet est l'exemple le plus clair à l'heure actuelle. Jeudi, sa communauté a voté pour étudier la transformation en un L1 post-quantique indépendant. L'une des raisons est de pouvoir mettre à jour la cryptographie à son propre rythme. StarkWare déclare : « Nous ne pouvons pas compter sur Ethereum pour avancer assez vite afin de garantir notre sécurité. » Le PDG Eli Ben-Sasson estime que l'arrivée de l'informatique quantique est prévue dans « deux ans » et pense que l'IA accélère cette échéance.

Les chercheurs d'Ethereum sont également vigilants. Plus tôt ce mois-ci, Justin Drake a exhorté l'industrie à se préparer à un « mode bunker », c'est-à-dire à transférer des fonds vers de nouvelles adresses plus sécurisées. Le contexte est une vague de percées mathématiques alimentées par l'IA.

Mais la flexibilité a un coût. Chaque clé d'administrateur, chaque chemin de mise à jour, est à la fois une surface d'attaque et un point de dépendance. Changer les règles peut également créer de nouveaux bugs. Ainsi, Ethereum a retiré Glamsterdam du réseau de test Hoodi cette semaine, car des recherches ont montré que son changement de Gas pourrait modifier le comportement des contrats déjà déployés.

Camp minimaliste : réduire la surface d'attaque au minimum

La deuxième réponse est de réduire l'objectif.

L'énoncé de Ross (z0r0z), développeur d'Ethereum, jeudi était très direct : déplacer le code des infrastructures numériques critiques sur une chaîne publique, permettant à tout le monde de vérifier ce qui se passe ; ensuite, aller vers un modèle sans serveur ; voire écrire les applications dans le code de la blockchain, de sorte qu'elles fonctionnent de la même manière à chaque exécution. Cette idée semble soudain moins étrange.

C'est bien sûr un peu ambitieux. Mais c'est essentiellement le « test de lâcher prise » de Ross : si les bâtisseurs disparaissent demain, le système peut-il encore fonctionner en toute sécurité ? Moins le code est volumineux, plus il est certain et facile à vérifier, moins il y a d'endroits vulnérables et moins il y a d'entités à faire confiance. Ross a ajouté dans une réponse : « Les développeurs devraient concentrer leurs efforts sur un code plus simple. »

La même intuition apparaît également dans la cryptographie d'Ethereum. Vitalik a déclaré que la feuille de route d'Ethereum s'est tournée vers « uniquement le hachage », en partie parce que le hachage est conçu sans structure pouvant être exploitée par l'IA pour des utilisations mathématiques.

L'inconvénient est tout aussi évident. Le code public et immuable peut également être lu par des attaquants utilisant l'IA ; une fois en ligne, il n'est pas possible de le corriger. Ainsi, le minimalisme est préférable lorsque le code est suffisamment petit pour être vérifié exhaustivement.

La preuve par l'IA rend le « non réparable » moins effrayant

C'est ici qu'intervient la vérification formelle. La vérification formelle consiste à prouver mathématiquement que le code ne viole pas certaines règles.

Historiquement, la vérification formelle était horriblement coûteuse. La construction du noyau du système d'exploitation seL4 n'a nécessité que deux années-homme, mais la vérification a pris 20 années-homme. Cependant, de nouvelles recherches publiées jeudi par Anthropic et Theorem montrent que cette voie devient moins coûteuse : utiliser Claude pour vérifier 239 points d'entrée dans 123 bibliothèques open source, sous certaines hypothèses, peu importe l'entrée, jusqu'à 64 Mo, ces points d'entrée ne s'effondreront pas. L'ensemble du processus n'a pris que quelques semaines.

Il y a aussi un coût. L'échelle de la preuve augmentera avec l'expansion du code. Dans le travail mentionné ci-dessus, une preuve typique compte environ 600 000 lignes, correspondant à environ 18 000 instructions machine, et pourrait consommer des centaines de millions de tokens AI. De plus, la preuve ne couvre que les propriétés que vous spécifiez, ce qui ne signifie pas qu'elle exclut tous les bugs.

Mais il faut noter qui en bénéficie le plus : le code petit et à usage unique. C'est précisément le type de code que le camp minimaliste souhaite mettre sur la chaîne. Si l'IA continue à faire baisser le coût des preuves, le « non réparable » ne sera pas si grave, car le code nécessitera de moins en moins de corrections.

Bien sûr, les systèmes comme L1 et rollup, qui sont de grande taille et en constante évolution, ne peuvent toujours pas se passer de flexibilité. Cependant, dans le nouveau paradigme de l'IA, le « test de lâcher prise » ressemble de plus en plus à l'étalon central des stratégies de sécurité, et pas seulement à un idéal de décentralisation. Ces tendances méritent d'être suivies de près.

Prix de --

--
--
--

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.

Vous pourriez aussi aimer

iconiconiconiconiconiconiconicon
Assistance client:@weikecs
Collaborations commerciales:@weikecs
Trading quantitatif/Market makers:[email protected]
Programme VIP:[email protected]