Une conversation avec un ami est restée dans mon esprit beaucoup plus longtemps que je ne l’avais prévu.
Il se préparait pour son premier marathon, et environ quatre mois avant le jour de la course, il m’avait dit avec assurance qu’il finirait en moins de quatre heures.
Son raisonnement était simple.
Il a calculé l’allure qu’il devait maintenir, l’a multipliée par la distance totale, et tout s’est parfaitement aligné. En regardant les chiffres, il était difficile de ne pas être d’accord avec lui. Les calculs étaient justes. Son plan d’entraînement semblait organisé. Son kilométrage hebdomadaire progressait, et chaque tableau indiquait qu’il était sur la bonne voie.
Puis le jour de la course est arrivé.
Il a franchi la ligne d’arrivée en quatre heures et quarante minutes.
Son calcul était-il faux ?
Pas du tout.
Les calculs étaient exacts.
Ce que le tableur n’avait pas pu prédire, c’est comment ses jambes se sentiraient après vingt miles, comment la fatigue affecterait sa cadence, comment la météo influencerait la performance, ou comment son corps réagirait lorsque la théorie rencontrerait la réalité.
Cette expérience m’a rappelé quelque chose d’important.
Un plan bien conçu et un résultat prouvé ne sont pas la même chose.
J’ai réfléchi à cette leçon en lisant la feuille de route de scalabilité du protocole Newton.
Une affirmation en particulier continuait de se démarquer pour moi.
Newton pense que la vérification agrégée des preuves permettra à terme au réseau de prendre en charge de nombreux agents autonomes exécutant des actions vérifiables, tout en maintenant des coûts économiquement durables.
C’est une vision enthousiasmante.
C’est aussi un point qui mérite une discussion attentive.
Pas parce que je pense que c’est irréaliste.
Mais parce que je pense qu’il existe une différence significative entre la logique d’ingénierie et la performance démontrée.
Trop souvent, dans la cryptographie, les gens classent immédiatement les nouvelles idées dans l’un des deux catégories.
Soit elles sont garanties de tout changer.
Ou bien on les rejette comme du marketing avant même qu’elles aient une chance de mûrir.
Personnellement, je ne pense pas que l’une ou l’autre réaction soit très utile.
La question la plus utile est beaucoup plus simple.
Qu’est-ce qui a réellement été démontré aujourd’hui, et qu’est-ce qui reste encore une projection pour demain ?
D’après ce que j’ai étudié, le raisonnement derrière l’approche de Newton semble solidement fondé techniquement.
La vérification agrégée des preuves n’est pas une idée imaginaire.
C’est déjà utilisé dans l’ensemble de l’écosystème plus large de la connaissance à divulgation nulle (zero-knowledge).
L’idée de base est relativement simple.
Au lieu de vérifier chaque preuve de manière indépendante, plusieurs preuves peuvent être regroupées et vérifiées en lot.
Plutôt que de payer le coût total de vérification pour chaque transaction individuelle, ce coût devient partagé entre de nombreuses opérations.
À mesure que le volume des transactions augmente, le coût moyen de vérification par transaction peut diminuer.
C’est une propriété attrayante pour n’importe quel système blockchain qui s’attend à une automatisation à grande échelle.
Imaginez maintenant la vision à long terme de Newton.
Des milliers—voire peut-être des millions—d’agents IA autonomes interagissant avec des smart contracts.
Chaque action nécessite une autorisation.
Chaque autorisation nécessite une vérification.
Chaque vérification consomme des ressources informatiques.
Si chaque autorisation nécessitait une vérification entièrement indépendante, les coûts finiraient par devenir difficiles à gérer à mesure que l’activité augmente.
La vérification agrégée des preuves tente précisément de résoudre ce problème.
Au lieu d’augmenter linéairement les coûts de vérification en même temps que l’activité, le regroupement (batching) permet à plusieurs autorisations de partager la surcharge de vérification.
Sur le plan conceptuel, c’est parfaitement logique.
Si cela fonctionne, cela crée le type d’efficacité dont les systèmes financiers autonomes auraient probablement besoin.
Cette partie de la feuille de route me paraît raisonnable.
Ce qui devient vraiment plus intéressant, c’est quand la théorie d’ingénierie rencontre la réalité de la production.
Un détail que j’ai apprécié en lisant la feuille de route de Newton, c’est qu’elle ne présente pas la vérification agrégée des preuves comme quelque chose déjà en fonctionnement à pleine échelle de production.
Au lieu de cela, on la décrit comme une amélioration de scalabilité à venir.
Cette distinction compte.
Cela signifie que les attentes actuelles reposent sur une conception d’ingénierie plutôt que sur des années de performance observable du réseau.
Rien d’inhabituel à cela.
Chaque projet d’infrastructure commence par des projections avant d’accumuler de l’historique opérationnel.
Mais les projections et les mesures sont des formes de preuves différentes.
Un autre point qui a attiré mon attention est que Newton reconnaît que certains aspects de sa feuille de route dépendent de l’évolution plus large de la technologie de zero-knowledge.
Plus précisément, les améliorations des outils basés sur la technologie zk développés dans l’ensemble de l’écosystème.
Des frameworks comme Succinct et RISC Zero continuent d’avancer rapidement, mais leurs progrès ne sont pas entièrement contrôlés par Newton lui-même.
J’ai en fait apprécié cette honnêteté.
Les feuilles de route présentent souvent des échéances avec beaucoup plus de certitude que la réalité ne le permet.
Reconnaître les dépendances externes rend la discussion plus ancrée.
Aucun projet d’infrastructure ne se développe entièrement en vase clos.
Le progrès dépend souvent aussi de l’évolution des écosystèmes environnants.
Ensuite, il y a une autre considération qui semble facile à négliger.
L’agrégation améliore l’efficacité.
Mais l’agrégation introduit aussi une coordination.
Au lieu de traiter les preuves une par une, les lots doivent être assemblés avant que la vérification n’ait lieu.
Cela soulève naturellement des questions pratiques.
À quelle vitesse les lots peuvent-ils se former ?
La latence augmente-t-elle pendant certaines périodes ?
Comment le système se comporte-t-il lorsque l’activité devient imprévisible ?
Ce ne sont pas des critiques.
Il ne s’agit que de questions opérationnelles qui ne deviennent significatives que dans de vraies conditions de réseau.
Un scénario à propos duquel je ne cesse de penser implique une demande corrélée.
Imaginez des milliers d’agents autonomes réagissant simultanément au même événement de marché.
Les taux d’intérêt peuvent changer.
Peut-être qu’une stablecoin perd brièvement son arrimage.
Peut-être que la liquidité se déplace entre plusieurs protocoles.
Plutôt que des demandes d’autorisation qui arrivent de façon régulière tout au long de la journée, d’énormes quantités arrivent presque simultanément.
Ce type de comportement synchronisé représente l’un des environnements les plus exigeants auxquels un réseau d’autorisation pourrait être confronté.
Si la vérification agrégée des preuves fonctionne bien à ces moments-là, la confiance grandit naturellement.
Si des goulots d’étranglement apparaissent ailleurs, les ingénieurs apprennent où une optimisation supplémentaire devient nécessaire.
Les diagrammes sur tableau blanc ne peuvent pas répondre pleinement à ces questions.
Les systèmes en conditions réelles finissent par le faire.
Un autre facteur à garder en tête est la décentralisation.
La scalabilité n’existe pas indépendamment de la participation au réseau.
Newton continue d’étendre, au fil du temps, la participation des validateurs et des opérateurs.
Ce processus suit sa propre chronologie.
Les améliorations de passage à l’échelle (scalabilité) et la décentralisation s’influencent souvent l’une l’autre d’une manière qui devient plus claire seulement après qu’elles aient mûri ensemble.
Tester l’une sans l’autre raconte rarement l’histoire complète.
C’est pourquoi je me retrouve à résister aux conclusions absolues.
Je ne pense pas qu’il soit raisonnable de déclarer la feuille de route de scalabilité de Newton garantie.
Je ne pense pas non plus qu’il soit raisonnable de la rejeter simplement parce que chaque jalon n’a pas encore été démontré publiquement.
La situation me rappelle encore une fois le marathon de mon ami.
Ses calculs n’étaient pas de la fiction.
Son entraînement n’était pas dépourvu de sens.
Tout indiquait une possibilité réaliste.
L’ingrédient manquant était une validation dans le monde réel sous de vraies conditions de course.
La feuille de route de Newton me semble similaire.
L’ingénierie sous-jacente semble réfléchie.
La logique qui sous-tend la vérification agrégée des preuves a du sens.
La direction architecturale s’aligne avec les évolutions plus larges qui se produisent dans l’infrastructure de zero-knowledge.
Mais, au final, les projections ne deviennent des faits que lorsque les systèmes ont vécu exactement les conditions qu’ils étaient conçus à affronter.
Une question revient sans cesse vers moi.
Comment les frais se comportent-ils pendant de vraies périodes de demande soutenue ?
Pas une activité normale.
Pas des environnements de démonstration.
De vraies conditions de production.
Quelle latence apparaît quand les demandes d’autorisation arrivent plus vite que prévu ?
Avec quelle efficacité les lots continuent-ils de se former ?
Les coûts restent-ils prévisibles ?
Les améliorations de débit continuent-elles de s’étendre comme prévu ?
Ce sont les questions que j’espère que les données réseau futures finiront par répondre.
Parce que la performance dans des conditions ordinaires ne raconte qu’une partie de l’histoire.
L’infrastructure gagne la confiance dans des conditions extraordinaires.
En repensant au marathon de mon ami, je ne pense pas que la leçon soit que la planification ne compte pas.
La planification compte énormément.
Sans préparation, la réussite devient improbable.
Mais, à elle seule, la préparation ne garantit jamais les résultats.
La réalité introduit toujours des variables qu’aucun tableur ne peut anticiper pleinement.
Le même principe s’applique à l’infrastructure blockchain.
La feuille de route de scalabilité de Newton ne devrait pas être traitée comme un fait établi simplement parce que l’ingénierie paraît convaincante.
Et elle ne devrait pas non plus être rejetée parce que la preuve d’une production à grande échelle est encore en train de se développer.
À ce stade, il semble plus exact de le décrire comme une hypothèse solidement fondée techniquement, en attente d’une validation à grande échelle.
Personnellement, je trouve que c’est une place saine à occuper.
Une bonne ingénierie mérite un optimisme prudent.
Pas une certitude aveugle.
Pas un scepticisme automatique.
Simplement la volonté de distinguer une architecture prometteuse d’une capacité prouvée.
Si les futurs tests de stress démontrent que la vérification agrégée des preuves continue d’offrir de faibles frais, une latence prévisible et une autorisation efficiente sous une demande soutenue et à haute fréquence, alors la feuille de route d’aujourd’hui deviendra la preuve de demain.
D’ici là, je pense qu’il vaut la peine de se rappeler le marathon de mon ami.
Le tableur ne mentait pas.
Simplement, il n’avait pas encore rencontré la route.
Peut-être que l’histoire de la scalabilité de Newton est dans une situation similaire aujourd’hui.
L’ingénierie semble solide.
La direction a du sens.
Désormais, l’industrie doit simplement voir comment cela fonctionne quand la théorie rencontre enfin la réalité.