Hier soir, je me suis plongé dans le livre blanc de @NewtonProtocol jusqu’à trois heures du matin : plus je le lisais, plus j’étais éveillé. L’idée de ce projet est de mettre en place une « couche d’automatisation vérifiable » : que des agents IA exécutent des actions on-chain à votre place, et que chaque étape apporte une preuve montrant qu’il n’y a pas eu d’abus. L’ambition est audacieuse, mais en la décomposant, il y a pas mal de questions.
La logique centrale de Newton repose sur trois couches : le registre de modèles gère l’identité des agents, le Keystore gère les autorisations des utilisateurs, et les intentions d’automatisation gèrent les conditions d’exécution. Parmi elles, c’est le Keystore qui m’inquiète le plus : le livre blanc dit qu’il s’agit de « a specialized rollup responsible for storing and updating user permissions », autrement dit que la capacité de tous les agents à bouger vos actifs dépend entièrement de lui. Et ce module tourne sur un déploiement PoS délégué : les validateurs misent NEWT pour garantir la sécurité. La chaîne logique paraît parfaite : environnement d’exécution TEE → ZKP sort une preuve → Keystore stocke les autorisations → vérification on-chain.
Mais le « mur » du TEE est plus fragile que je ne l’imaginais. J’ai lu le rapport de Binance Research : ils écrivent noir sur blanc que « currently utilizes Phala's cloud environment », donc à l’heure actuelle le TEE tourne dans l’environnement cloud de Phala. La clé privée, les clés de session et les autorisations de transaction se trouvent toutes dans une enclave exécutée par un tiers. Lors de l’attaque TEE.Fail en 2025, des chercheurs avec moins de 1000 dollars ont réussi à extraire des clés critiques depuis Intel TDX et AMD SEV. Phala elle-même reconnaît que l’enclave pourrait être clonée. Un agent falsifié peut quand même générer un « Quote » affirmant que tout est normal, et le smart contract on-chain valide et enregistre la transaction sans sourciller.
Ce qui me rend encore plus mal à l’aise, c’est que, dans la phase initiale, le réseau est dominé par des serveurs TEE appartenant à la fondation, pas par un réseau distribué : c’est la fondation qui décide.
Je ne suis pas fermé à l’idée ; au contraire, c’est parce que je la trouve prometteuse que je reste plus vigilant. Le TEE n’a pas supprimé la confiance : il l’a simplement déplacée du projet vers Intel et AMD. Ma stratégie est simple : rester attentif, sans bouger la position principale. Attendons que Newton fonctionne sans dépendre d’un TEE tiers. #newt $NEWT
La logique centrale de Newton repose sur trois couches : le registre de modèles gère l’identité des agents, le Keystore gère les autorisations des utilisateurs, et les intentions d’automatisation gèrent les conditions d’exécution. Parmi elles, c’est le Keystore qui m’inquiète le plus : le livre blanc dit qu’il s’agit de « a specialized rollup responsible for storing and updating user permissions », autrement dit que la capacité de tous les agents à bouger vos actifs dépend entièrement de lui. Et ce module tourne sur un déploiement PoS délégué : les validateurs misent NEWT pour garantir la sécurité. La chaîne logique paraît parfaite : environnement d’exécution TEE → ZKP sort une preuve → Keystore stocke les autorisations → vérification on-chain.
Mais le « mur » du TEE est plus fragile que je ne l’imaginais. J’ai lu le rapport de Binance Research : ils écrivent noir sur blanc que « currently utilizes Phala's cloud environment », donc à l’heure actuelle le TEE tourne dans l’environnement cloud de Phala. La clé privée, les clés de session et les autorisations de transaction se trouvent toutes dans une enclave exécutée par un tiers. Lors de l’attaque TEE.Fail en 2025, des chercheurs avec moins de 1000 dollars ont réussi à extraire des clés critiques depuis Intel TDX et AMD SEV. Phala elle-même reconnaît que l’enclave pourrait être clonée. Un agent falsifié peut quand même générer un « Quote » affirmant que tout est normal, et le smart contract on-chain valide et enregistre la transaction sans sourciller.
Ce qui me rend encore plus mal à l’aise, c’est que, dans la phase initiale, le réseau est dominé par des serveurs TEE appartenant à la fondation, pas par un réseau distribué : c’est la fondation qui décide.
Je ne suis pas fermé à l’idée ; au contraire, c’est parce que je la trouve prometteuse que je reste plus vigilant. Le TEE n’a pas supprimé la confiance : il l’a simplement déplacée du projet vers Intel et AMD. Ma stratégie est simple : rester attentif, sans bouger la position principale. Attendons que Newton fonctionne sans dépendre d’un TEE tiers. #newt $NEWT