Quand l'agent IA obtient le pouvoir d'exécution sur la chaîne : qui vérifie les informations qu'il voit et les instructions qu'il émet ?

I. Que révèle l'incident de KelpDAO

Le 18 avril 2026, le pont inter-chaînes rsETH de KelpDAO a été attaqué, entraînant la libération anormale de 116 500 rsETH, d'une valeur d'environ 292 millions de dollars à l'époque. Le rapport d'incident de LayerZero indique que l'attaquant a obtenu la clé de session du développeur par ingénierie sociale, contaminant le RPC interne sur lequel reposait LayerZero Labs DVN, et a réprimé le RPC externe par une attaque par déni de service, permettant au service de signature de délivrer des preuves pour des messages falsifiés basés sur des données erronées. À l'époque, KelpDAO avait modifié le chemin de validation de 2-of-2 à 1-of-1 DVN. Une fois qu'un DVN désigné émet une preuve erronée, le système n'a plus besoin d'un deuxième DVN indépendant pour valider le même message. CrowdStrike et Mandiant attribuent l'incident avec une forte confiance à TraderTraitor (UNC4899) lié à la Corée du Nord.

Ce type d'incident n'est pas un cas isolé. De nombreux événements de sécurité majeurs sur la chaîne ne remettent souvent pas en question les hypothèses cryptographiques elles-mêmes, mais plutôt le contrôle des clés, les sources de données, la configuration des validateurs, la mise en œuvre des protocoles et les permissions opérationnelles. Le système doit non seulement répondre à la question "Cette signature est-elle valide ?", mais aussi à "Qui a le droit de signer, sur quelle base, et l'état correspondant à la signature s'est-il réellement produit ?".

De plus en plus d'agents IA obtiennent des capacités d'exécution sur la chaîne via des comptes intelligents, des portefeuilles stratégiques ou des services de signature restreints. Une signature valide ne prouve qu'un chemin d'autorisation a été appelé, mais ne prouve pas que les données sur lesquelles l'agent s'est basé sont fiables, que la décision est conforme à la stratégie établie, ou que cette transaction aurait dû se produire à ce moment-là. L'objet de la vérification s'étend de "l'authenticité de la signature" à "l'unité entre l'entrée, la décision et l'exécution".

II. Que résolvent les solutions existantes et que laissent-elles derrière elles

Les quelques solutions existantes résolvent une partie des problèmes de confiance, mais chacune confie le reste de la confiance à différents rôles :

Oracles et arbitrage des litiges : Les résultats du marché de Polymarket sont d'abord proposés par les participants, et ne sont soumis à un vote des détenteurs de jetons UMA que s'ils sont contestés pendant la période de contestation. Le problème ne réside pas dans le fait qu'il n'y ait pas de révision, mais dans la fiabilité de cette révision. Lorsque les règles sont floues, que des événements réels peuvent avoir plusieurs interprétations, ou que le droit de vote est concentré entre quelques adresses, le système confie en réalité la question "Qui définit les faits ?" à une autre structure de gouvernance.

Multi-signature de pont inter-chaînes et DVN : Bien que leurs modes de mise en œuvre soient différents, les deux exigent que les applications configurent clairement un ensemble de validateurs et un seuil. Après que KelpDAO a configuré le chemin en 1-of-1 DVN, tout le chemin de validation dépendait d'un seul service de validation ; et les sources de données et les mécanismes de réponse aux pannes sur lesquels ce service repose peuvent également créer un point unique de défaillance.

Gestion MPC : L'argument de la signature par seuil est que la clé ne sera pas entièrement stockée à un seul endroit, mais le fractionnement cryptographique ne conduit pas automatiquement à une décentralisation du pouvoir au niveau organisationnel. Selon les révélations de l'équipe Multichain, après que le fondateur a été arrêté par la police chinoise, l'équipe a immédiatement perdu l'accès aux serveurs des nœuds MPC concernés, qui fonctionnaient sous le compte cloud personnel du fondateur. Si le compte cloud, les permissions opérationnelles et la réponse d'urgence sont concentrés entre les mains d'une seule personne, la conception par seuil de la MPC peut encore laisser un point unique au niveau organisationnel.

TEE : L'environnement d'exécution de confiance peut isoler le code et les données sensibles, mais il n'élimine pas la confiance, il change simplement le point de confiance. La confiance racine matérielle et les mises à jour de microcode dépendent généralement des fabricants de puces, tandis que le code enclave, les permissions de mise à jour et les politiques d'authentification peuvent être contrôlés par le projet ou l'opérateur. Le TEE peut protéger le processus de calcul, mais ne peut pas automatiquement décentraliser ces permissions de gouvernance.

Ces modèles de défaillance des solutions ne sont pas les mêmes, mais ils pointent tous vers le même type de problème : les seuils et la décentralisation écrits dans les livres blancs ne peuvent constituer de véritables frontières de sécurité que s'ils sont réellement appliqués aux sources de données, aux permissions de compte, aux clés de mise à niveau et aux processus de gouvernance.

III. CRVA : redéfinir la manière dont les droits de validation sont attribués

DeepSafe a été renommé Bool Network en 2025. Le CRVA prolonge l'idée technique proposée par les chercheurs de Bool Network en 2022. Le document connexe a été publié dans les IEEE Transactions on Information Forensics and Security (IEEE TIFS, Document ID 9903072), proposant une plateforme de notarisation inter-chaînes basée sur un "comité caché évolutif" (evolving hidden committee).

La méthode spécifique est la suivante : les nœuds participent à un tirage au sort aléatoire via Ring-VRF, les sélectionnés soumettent une preuve et une clé publique temporaire, les observateurs externes peuvent vérifier leur qualification, mais il est difficile d'identifier leur identité à long terme. Le comité temporaire sélectionné signe ensuite collectivement via MPC par seuil, aucun nœud unique ne pouvant produire un résultat de manière indépendante. Les processus clés tels que la gestion des clés fonctionnent selon la conception du document dans un TEE (par exemple, Intel SGX), afin de réduire la possibilité que l'opérateur de l'hôte lise ou altère les parts de clés. Le comité sera également renouvelé par époque, la nouvelle session obtenant de nouvelles parts par un transfert de clés vérifiable, les anciennes parts devenant alors invalides, la période de renouvellement étant déterminée par les paramètres réels du réseau.

Le projet espère également, grâce au TEE, cacher l'état de travail du comité, rendant difficile pour les opérateurs de nœuds de déterminer si leur nœud a participé à une validation donnée. Dans quelle mesure cet objectif peut être atteint dépend du code du réseau actuel, de l'authentification à distance, des métadonnées côté hôte et de la protection contre les canaux latéraux, et ce n'est pas une conclusion automatique que "l'utilisation du TEE" suffit.

Cependant, ces mécanismes résolvent la question "Qui valide et comment produire des résultats de manière sécurisée", mais ne définissent pas automatiquement "quel résultat est correct". Dans le contexte des agents IA, le comité doit toujours tirer des conclusions en fonction de stratégies prédéfinies, de sources de données et de règles de jugement exécutables. Si ces règles sont problématiques, si les sources de données sur lesquelles elles reposent ne sont pas fiables, ou si l'objet de la validation n'a pas de réponse objectivement déterminable, même le comité le plus sécurisé peut confirmer collectivement une conclusion erronée.

Le CRVA tente de réduire les risques liés à l'exposition à long terme des validateurs fixes et à la concentration des droits de signature, mais ne peut pas éliminer complètement les points uniques au niveau de la gouvernance et de la mise en œuvre. L'admission des nœuds, les mises à niveau des protocoles, l'authentification TEE et la sécurité logicielle doivent encore être soumises à un audit continu. Sous la condition que les anciennes parts deviennent effectivement invalides et que le nouveau comité reste suffisamment indépendant, le renouvellement peut réduire la fenêtre d'attaque contre un groupe de signatures fixes, mais ne peut pas couvrir les risques systémiques tels que la chaîne d'approvisionnement logicielle ou les permissions de mise à niveau.

IV. Fondements techniques et progrès de mise en œuvre

La lignée technique du CRVA peut être retracée jusqu'à l'article publié dans le volume 17 des IEEE TIFS (2022), DOI 10.1109/TIFS.2022.3209546. Le modèle de protocole, les preuves de sécurité et l'évaluation des prototypes présentés dans l'article ont été soumis à une révision par les pairs, fournissant une base académique pour des conceptions telles que le comité caché dynamique, Ring-VRF, la gestion des clés par seuil et la protection TEE. Il est important de faire la distinction entre le fait que la révision par les pairs concerne les modèles et les mises en œuvre dans l'article ; la manière dont le CRVA déployé par DeepSafe correspond aux solutions de l'article doit encore être jugée en fonction des spécifications techniques actuelles, des audits de code et des paramètres du réseau.

Selon les révélations de DeepSafe en octobre 2025, le réseau avait alors traité près de 120 millions de validations, avec plus de 2,65 millions de comptes actifs. Le projet a également déclaré que ses relations écologiques dépassaient 70, impliquant des compatibilités de portefeuille, des intégrations techniques, des investissements et des collaborations sur le marché.

En octobre 2025, DeepSafe a annoncé avoir levé 3 millions de dollars lors d'un tour de financement par capital-risque, avec des investisseurs tels qu'Antalpha Global, ViaBTC Capital et Gate. D'après la chronologie, ce tour de financement correspond principalement à la recherche et au développement technologique et à l'expansion de l'écosystème après le changement de marque.

V. De la solution de validation à l'infrastructure générale

Avec la modularisation progressive des infrastructures blockchain, le consensus, l'exécution, la disponibilité des données, l'interopérabilité et le système de comptes commencent à être pris en charge par différents composants. La modularisation n'a pas fait disparaître les problèmes de confiance, mais a rendu les frontières de sécurité de chaque couche plus claires. Les développeurs doivent non seulement choisir quelle technologie utiliser, mais aussi déterminer qui fournit la garantie de sécurité à ce niveau et qui est responsable en cas de problème. Une fois que les agents IA obtiennent des capacités d'exécution sur la chaîne, de nouveaux problèmes émergent : qui confirme que les données qu'ils lisent sont fiables, que les décisions ne dépassent pas les autorisations, et que la transaction finale est conforme à l'autorisation de l'utilisateur ? Ces questions ne trouveront pas automatiquement de réponse grâce à une signature valide.

DeepSafe souhaite abstraire la capacité de validation d'un module auxiliaire interne à une application, en tant qu'infrastructure pouvant être appelée par différents protocoles et agents IA - "Preuve, pas promesses", remplaçant les promesses de l'exécutant par des preuves vérifiables. Le CRVA a déjà combiné le tirage anonyme, la collaboration par seuil et le TEE en un chemin technique ; sa capacité à couvrir davantage de scénarios tels que les oracles, les ponts inter-chaînes et les agents IA, et à évoluer vers une infrastructure de validation générale, dépendra de l'accumulation continue de capacités sur le réseau actuel, d'audits indépendants et d'intégrations réelles.

Cet article provient d'une soumission et ne représente pas l'avis de BlockBeats.