Vous avez vu les petits billets sur le Newton Protocol ces derniers jours ? Leur principal argument de vente, qu’ils répètent sans arrêt, c’est soi-disant “une couche d’automatisation décentralisée et vérifiable”. Ça sonne très “hardcore”, très Web3, non ?
J’ai une petite manie : quand je vois ce genre de mots très “haute gamme”, j’ai envie d’aller gratter l’architecture technique en dessous. Résultat : en suivant leur documentation de développement, j’ai fouillé tout un tour, et je suis resté carrément bouche bée. Il y a là un enchaînement logique fondamental qui ne colle pas : Newton ne cesse de dire d’aller vers la décentralisation, mais au niveau du TEE (environnement d’exécution de confiance) — toute la couche de base — tout tourne sur AWS (Amazon Web Services). Autrement dit : vous pensez faire confiance à la blockchain, mais en réalité, vous finissez par confier toutes les clés de sécurité à Amazon.
Aujourd’hui, on va en parler avec des mots simples, sans aucun filtre de jargon de secteur : découvrons combien d’« arrière-pensées » se cachent dans cette prétendue « automatisation décentralisée ».
Premièrement, la soi-disant « vérifiabilité » : la dernière étape doit en fait dépendre de l’accord d’Amazon.
D’abord, tout le monde doit comprendre la logique du TEE. Le code est bien inaltérable, et les preuves générées peuvent bien être envoyées sur la chaîne pour vérification : ça, ça ne semble pas poser problème. Mais le souci, c’est que le TEE utilisé par Newton tourne dans AWS Nitro Enclaves, chez Amazon ; au final, le document de preuve de quantification à distance est délivré par AWS !
Que signifie cela ?
Qu’AWS reconnaisse, et alors seulement ta vérification est considérée comme valide.
Si AWS ne reconnaît pas, ou s’il est demandé pour une raison quelconque de ne pas reconnaître, tes opérations automatisées se transforment directement en une blague.
N’est-ce pas exactement un « transfert de confiance » ? Tu ne fais que transférer ta confiance dans l’équipe du projet vers le plus grand géant traditionnel d’Internet — Amazon. Si cela s’appelle la décentralisation, alors autant que tout le monde n’utilise plus de blockchain : développons directement avec des serveurs Web2.
Deuxièmement, en cas de force majeure, Newton n’a tout simplement pas de Plan B.
Ce qui inquiète encore plus, c’est que j’ai retourné de fond en comble la documentation technique officielle et que je n’ai absolument rien vu concernant une « solution matérielle de secours » ou un mécanisme de résilience multi-cloud/anti-panne.
Ce n’est pas moi qui m’inquiète pour rien. Les gens qui font de la technique savent tous que ce type d’architecture reposant très fortement sur un seul fournisseur de services ne peut pas être résolu par le code : le risque est déterminé par les intérêts commerciaux derrière, ou par la géopolitique externe.
Supposons un scénario extrême : un jour, pour des raisons de conformité réglementaire ou une autre force majeure, le gouvernement américain exige qu’AWS coopère à une inspection. AWS n’a qu’à lever la main et arrêter l’émission de toutes les preuves TEE qui tournent sur Nitro Enclaves ; et à ce moment-là, la capacité de vérification du réseau Newton s’effondre instantanément, au point d’être totalement paralysée.
Face à un cygne noir aussi extrêmement destructeur, le projet semble ne disposer pour l’instant de quelque prévision ou plan que ce soit.
Quelqu’un pourrait répliquer : « Au moins, avec l’isolation matérielle TEE, c’est mieux que de dépendre entièrement du projet pour faire des opérations en boîte noire, non ? »
On ne peut pas dire ça comme ça. Quand tu transfères le point d’ancrage de la confiance du projet vers Amazon, tu remplaces en réalité un monstre énorme dont tu connais moins bien les tenants et aboutissants, et que tu ne peux pas contrôler. Tu ne peux pas savoir, en tant qu’utilisateur ordinaire, les politiques internes d’exploitation d’AWS, les standards de conformité, ni même l’historique de pannes. Dans l’histoire d’Internet, combien de fois AWS a-t-il connu des pannes massives ? À chaque fois, est-ce que ce n’était pas avec des centaines de services dépendants qui s’écroulaient ensemble ? Si AWS tombe en panne, il est impossible de générer les preuves TEE : les stratégies d’automatisation des utilisateurs se bloquent directement en chemin, dans une impasse.
Troisièmement : la chaîne de confiance est trop longue, et tout le milieu devient des « poupées russes matérielles » d’une entreprise américaine.
Tu penses n’avoir qu’à faire confiance à Amazon, et c’est tout ? Décortiquons soigneusement la chaîne de confiance de ce TEE, et tu verras à l’intérieur ces « poupées russes » incroyablement profondes.
La sécurité fondamentale du matériel TEE dépend, au final, des clés racines injectées par le fabricant de puces au moment de la production. Aujourd’hui, le matériel grand public principal est Intel (Intel) et AMD. Donc, si nous voulons réaliser une prétendue « transaction automatisée vérifiable », son chemin de confiance réel est en fait le suivant :
Étape 1 : Vous confiez vos instructions de trading automatisé au protocole Newton.
Deuxième étape : Newton fait exécuter les stratégies sur le serveur cloud d’AWS.
Étape 3 : L’environnement d’exécution TEE d’AWS dépend de clés matérielles injectées par des puces Intel ou AMD pour réaliser l’isolation par chiffrement.
Étape 4 : Une fois l’exécution terminée, le système de conformité d’AWS délivre une preuve de quantification à distance.
Étape 5 : Envoyer la preuve sur la chaîne Newton et finaliser la dernière validation on-chain.
Calculons : il y a pas moins de cinq couches dans la chaîne de confiance ! Dans tout ça, seule la dernière couche — c’est-à-dire l’étape où la preuve est vérifiée on-chain — est rendue publique et transparente sur la blockchain. Les quatre premières couches (nœuds Newton, plateforme cloud AWS, puce Intel, puce AMD) sont toutes des entités centralisées à 100 %. Après avoir fait tout ce détour, on passe simplement de « faire confiance à l’équipe Newton » à « faire confiance à la fois à Amazon + Intel + AMD ». Pour une communauté crypto qui cherche la décentralisation, est-ce vraiment une amélioration en termes d’expérience ?
Quatrièmement : ce soi-disant « passage à l’avenir », c’est plutôt du rêve de loin, très lointain, sans fin.
En fait, dans la communauté, des frères l’ont découvert très tôt et ont adressé des doutes au projet : « Puisque Newton se présente comme une couche d’automatisation décentralisée, pourquoi ne construit-il pas lui-même un cluster distribué de matériel physique TEE ? Pourquoi passer par AWS, pour faire plus simple ? »
À l’époque, la réponse officielle disait en substance : « Pour l’efficacité du développement et de l’exécution à un stade précoce, nous avons d’abord choisi une solution auprès d’un fournisseur cloud mature. À l’avenir, nous passerons progressivement à un réseau entièrement décentralisé de matériel physique. »
C’est là que ça devient intéressant. « L’avenir » est-il à quelle distance ? Trois mois, un an, ou bien seulement quand le projet ne pourra plus continuer et qu’on ne verra plus rien ? Dans sa feuille de route officielle (Roadmap) publique, Newton n’a même pas écrit un seul jalon temporel concret pour cette période de transition cruciale de « décentralisation du matériel ». Autrement dit, d’ici là, chaque « stratégie vérifiable » qui s’exécute sur le réseau et que l’on encense comme quelque chose d’extraordinaire garde, pour finir, la porte de validation fermement sous le contrôle de l’entreprise centralisée.
En résumé
Un réseau qui se décrit avec insistance comme « décentralisé », et dont le module d’automatisation de vérification le plus central tourne en réalité sur le plus grand serveur cloud centralisé du monde : voilà en soi une contradiction énorme.
Le TEE est effectivement une bonne technologie, utile pour le calcul préservant la confidentialité. Mais tout le monde doit rester lucide : la technologie TEE ne résout pas, à elle seule, le problème de « décentralisation / suppression de la confiance » de Web3. Elle fait simplement passer la confiance que nous accordons aux « personnes » vers les « géants du matériel » et les « fournisseurs de services cloud ». Si tu joues dans le milieu crypto précisément pour un contrôle absolu et une résistance à la censure, alors pour toi l’architecture technique actuelle de Newton, qui dépend lourdement d’AWS, est un risque que tu ne peux pas ignorer.
(Cet article est une tâche de plateforme et ne constitue aucun conseil en investissement.)