#newt $NEWT L’impasse des agents d’IA sur la blockchain : Newton Protocol est-il le déblocage, ou un jouet coûteux ?
Après plus de dix ans de développement en couche basse, je suis toujours convaincu que laisser un agent d’IA prendre directement le contrôle d’un portefeuille est profondément contre-intuitif. Les solutions du marché sont soit stupides, soit mauvaises : soit elles tournent sur des serveurs centralisés en pariant que l’équipe ne fera pas de mal, soit elles affrontent de front le calcul on-chain, qui finit par se retourner contre vous avec les frais de Gas.
Newton Protocol (
$NEWT ) cherche à remplacer les « boîtes aveugles » de la nature humaine par une « confiance technologique ». L’idée est très juste, mais en tant que développeur, après avoir disséqué sa logique de fond, j’y ai vu des défauts structurels qu’on ne peut pas ignorer.
Une architecture idéalement parfaite
Le cœur de Newton repose sur trois piliers : l’autonomie limitée, l’intégrité vérifiable et l’accumulation de réputation. Il déporte le calcul de l’IA dans le TEE (Trusted Execution Environment), compresse les résultats avec des ZKP (preuves à connaissance nulle), puis valide par échantillonnage via les nœuds EigenLayer AVS. Les opérateurs mettent en gage des NEWT : en cas de mauvaise conduite, la sanction tombe directement. Cette boucle fermée fondée à la fois sur la théorie des jeux et sur des contraintes cryptographiques est indéniablement supérieure aux équipes « d’appoint » qui promettent la sécurité en lançant des annonces.
La réalité brutale de la couche technique
L’idéal est beau, mais dès qu’on passe au vrai environnement d’exécution EVM, tout se révèle :
Un faille d’attaque par relecture mortelle : c’est le design de la logique du code qui me met le plus mal à l’aise. Newton utilise des clés de session pour gérer les permissions, mais la conception de l’automate d’état comporte des angles morts. Si un attaquant intercepte une preuve ZK qui est sur le point d’expirer, et que le système ne dispose pas d’un mécanisme strict de Nullifier (identifiant d’annulation) ou d’une validation forte des horodatages on-chain, un nœud malveillant peut alors soumettre indéfiniment la preuve en boucle avant son expiration, vidant ainsi le quota d’autorisations des utilisateurs. La cryptographie peut prouver que « le calcul est correct », mais le système actuel ne peut pas vérifier si « cette preuve a été utilisée de manière abusive ».
Conclusion
L’automatisation vérifiable est une voie incontournable pour combiner Web3 et IA, mais la forme que montre actuellement Newton Protocol ressemble davantage à une expérience de geek précoce. Tant que le coût de la vérification ZK on-chain n’aura pas vraiment été abaissé à un niveau de rupture, et que les failles de transition d’état de base ne seront pas corrigées complètement, investir massivement est extrêmement risqué. La technique ne ment pas : je vais continuer à suivre de près les données réelles d’appels on-chain, sans me laisser berner.
#NEWT #Web3 #ZKML @NewtonProtocol