La première question qui m’est venue à l’esprit en lisant @NewtonProtocol w était, de façon surprenante, très simple : que se passe-t-il si chaque validateur voit une version légèrement différente de la réalité ?
Au début, je pensais que ce n’était pas un problème majeur. La plupart des systèmes décentralisés s’appuient déjà sur de nombreux opérateurs indépendants, donc je me suis dit que chaque nœud pouvait récupérer des informations externes, évaluer une politique, signer le résultat, puis passer à autre chose. Mais plus je me suis penché sur Newton Mainnet Beta et sa documentation technique, plus je me suis rendu compte que cette hypothèse s’effondre discrètement dès qu’on introduit l’agrégation de signatures BLS. Les signatures BLS sont extrêmement efficaces : des centaines de signatures peuvent être regroupées en une preuve compacte unique. Cependant, il y a un piège facile à manquer. Tous les participants doivent signer exactement le même message. Même une infime différence dans les données récupérées crée un message entièrement différent, rendant l’agrégation impossible.
Cette contrainte a complètement changé la façon dont j’ai regardé l’architecture de Newton. La partie difficile n’est pas de collecter des signatures. La partie difficile consiste à faire en sorte que des machines fonctionnant indépendamment parviennent à une vue identique des informations externes, sans donner à un seul participant l’autorité complète sur la réponse. Cet équilibre entre indépendance et accord semble être l’un des choix d’ingénierie les plus intéressants derrière @NewtonProtocol.
Le protocole aborde cela via un processus de consensus à deux phases en mode streaming. Pendant la première étape, les opérateurs exécutent indépendamment des fournisseurs de données WASM sandboxés en utilisant leurs propres connexions réseau. Ils peuvent récupérer des informations de sanctions, des prix de marché ou d’autres entrées de politique sans s’appuyer sur un serveur partagé. Chaque opérateur produit aussi une attestation décrivant ce qu’il a réellement observé. Au lieu de forcer tout le monde à faire confiance à un seul oracle dès le début, le protocole permet l’observation indépendante d’abord, puis l’accord ensuite.
Au départ, je me suis demandé pourquoi cette étape supplémentaire existait. Ne serait-ce pas beaucoup plus rapide si la passerelle distribuait simplement un seul jeu de données approuvé à tout le monde ? Cela semble certainement plus simple d’un point de vue ingénierie. Le problème, c’est que cette simplicité introduirait discrètement une dépendance centrale. Si chaque valideur reçoit une information identique provenant d’une seule source, la décentralisation devient davantage une question de collecte de signatures qu’une vérification indépendante. Newton semble éviter ce raccourci en permettant aux opérateurs de rassembler l’information eux-mêmes avant que le consensus ne détermine le jeu de données canonique.
Ce n’est qu’après cette phase de préparation que l’évaluation commence. Une fois qu’un jeu de données de consensus a été formé, chaque opérateur charge exactement la même version de politique grâce à son identifiant de contenu IPFS, évalue des entrées identiques, crée le même digest et produit enfin une signature BLS. À ce stade, l’agrégation devient possible parce que chaque participant signe enfin un message identique, plutôt que des observations légèrement différentes.
Ce qui m’a particulièrement intéressé, c’est que cette conception sépare deux problèmes qui finissent souvent par être mélangés. Le premier est de décider à quoi ressemble actuellement le monde extérieur. Le second est d’évaluer des règles d’autorisation déterministes. Newton semble éviter de résoudre ces deux aspects en même temps. D’abord, il parvient à un accord sur les données, puis il évalue la politique. Cela ressemble à une distinction subtile, mais les systèmes distribués deviennent souvent beaucoup plus faciles à raisonner quand les entrées non déterministes sont isolées avant que le calcul déterministe ne commence.
Un exemple concret m’a aidé à comprendre pourquoi c’est important. Imaginez un émetteur de stablecoin qui vérifie si une adresse de destination apparaît sur une liste de sanctions mise à jour avant d’autoriser un transfert. Différents opérateurs peuvent interroger des miroirs différents ou recevoir des mises à jour à quelques secondes d’intervalle. Sans coordination, un opérateur pourrait approuver tandis qu’un autre refuserait. Leurs signatures ne pourraient alors jamais être combinées en une seule preuve, ce qui retarderait la transaction ou produirait une autorisation incohérente. En s’accordant sur un jeu de données canonique avant l’évaluation, le réseau d’opérateurs produit un résultat d’autorisation unifié que les smart contracts en aval peuvent vérifier efficacement.
En lisant plus en profondeur, j’ai aussi remarqué une dépendance facile à manquer. La passerelle calcule le jeu de données de consensus avant que la phase d’évaluation ne commence. À première vue, cela ressemble à une responsabilité importante, et je me suis demandé si cela introduit une nouvelle hypothèse de confiance. La documentation explique que les opérateurs attestent indépendamment des données qu’ils ont observées : la passerelle ne peut pas forger les signatures des opérateurs, et le rôle d’orchestration est conçu pour tourner dans le temps plutôt que de rester durablement centralisé. Il existe aussi des mécanismes de forçage d’inclusion destinés à contourner la censure de la passerelle si nécessaire. Malgré tout, la passerelle reste opérationnellement importante parce que la coordination elle-même est un travail difficile. Cela ne diminue pas forcément la décentralisation, mais cela signifie que la qualité de l’implémentation compte autant que la cryptographie.
Un autre détail que je n’arrêtais pas d’analyser concerne la latence. La collecte de données indépendante, la formation du consensus, l’évaluation de la politique, la collecte du quorum et l’agrégation des signatures se déroulent toutes avant que l’autorisation ne soit totalement terminée. Pour des informations très dynamiques comme des prix de marché en mouvement rapide, le timing pourrait devenir de plus en plus important. Le protocole inclut un mode simplifié à une phase pour des données déterministes ou mises en cache afin de réduire les surcoûts inutiles, ce qui suggère que les concepteurs reconnaissent que chaque demande d’autorisation ne mérite pas forcément le même coût de coordination. Le fait que les applications choisissent le bon mode deviendra peut-être une responsabilité significative pour les développeurs.
Cela met aussi en évidence un principe d’ingénierie plus général qui dépasse largement @NewtonProtocol. Les systèmes distribués échouent rarement parce que la cryptographie est faible. Plus souvent, ils ont du mal parce que des participants indépendants observent des réalités différentes. Les algorithmes de consensus sont fréquemment décrits comme des méthodes pour s’entendre sur des blocs ou des transactions, mais l’accord sur des informations externes peut être tout aussi difficile. La conception des oracles, l’évaluation des politiques, l’IA décentralisée, la messagerie inter-chaînes et les cadres d’autorisation finissent tous par rencontrer la même question : comment des machines indépendantes peuvent-elles agir avec confiance sur des données qui changent constamment ?
Cette question me semble de plus en plus pertinente à mesure que des agents d’IA commencent à interagir directement avec l’infrastructure blockchain. Les humains tolèrent naturellement l’ambiguïté et des informations incomplètes. Les machines, elles, ne le peuvent généralement pas. Si un système autonome reçoit des entrées externes contradictoires, l’exécution déterministe devient étonnamment fragile. Une infrastructure qui standardise ces entrées avant que des décisions importantes ne soient prises pourrait finir par être tout aussi précieuse que l’exécution plus rapide elle-même.
Je ne pense pas non plus que cette conception élimine tous les compromis. Le consensus basé sur la médiane fonctionne bien pour de nombreuses valeurs numériques, mais toutes les sources de données externes ne s’intègrent pas aussi bien dans ce modèle. Certaines entrées de politique sont qualitatives, d’autres peuvent dépendre de bases de données qui changent rapidement, et la documentation ne peut naturellement pas anticiper tous les cas limites que des développeurs pourraient introduire via des fournisseurs de données WASM personnalisés. Ces questions opérationnelles restent intéressantes précisément parce qu’il n’existe pas encore de réponses universellement acceptées.
Après avoir passé du temps à étudier cette partie de Newton Mainnet Beta, j’ai cessé de considérer l’agrégation BLS comme une simple optimisation cryptographique. Elle façonne discrètement l’ensemble du modèle de coordination du réseau. Une fois que des messages identiques deviennent une exigence, l’observation indépendante ne suffit plus. Le consensus doit exister avant même que les signatures ne commencent.
Je me demande alors si la prochaine génération d’infrastructure décentralisée passera moins de temps à prouver que les calculs ont été exécutés correctement et plus de temps à prouver que chaque participant est bien parti de la même version partagée de la réalité.
