Quand j’ai commencé à participer à la DeFi au début, je me concentrais davantage sur les opportunités. Quel protocole offrait un meilleur rendement, quel mécanisme était le plus récent, quel produit apportait de nouvelles façons de jouer. Mais plus je participais à des projets, plus je constatais un problème qui devenait de plus en plus évident : pris séparément, beaucoup de systèmes ne posent pas de problème, mais dès qu’on les combine, la complexité augmente rapidement.
Un protocole a sa propre logique, une application a ses propres règles, et un programme automatisé a sa propre manière d’exécuter. Quand tout cela fonctionne en même temps, la vraie difficulté consiste à faire en sorte qu’ils s’accordent selon une logique unifiée.
C’est aussi la direction qui m’intéresse particulièrement quand je regarde le protocole Newton.
Je pense que le cœur de Newton n’est pas de créer une nouvelle application, mais d’ajouter, sur la chaîne, une couche de capacités permettant de relier différents systèmes.
D’après la conception du livre blanc, Newton abstrait la logique d’exécution qui, auparavant, était dispersée au sein des applications, grâce à l’Authorization Layer. Il s’appuie sur un Policy Framework pour permettre aux développeurs de définir des conditions d’exécution différentes selon les scénarios, afin que les comportements complexes ne dépendent plus entièrement du code propre à une application donnée.
Cette conception me rappelle le processus de développement des logiciels traditionnels.
Souvent, une industrie n’entre véritablement dans une phase de mise à l’échelle non pas parce qu’elle propose plus de fonctionnalités, mais parce qu’elle dispose d’une infrastructure capable de connecter différentes fonctions.
En substance, ce que Newton veut faire est assez similaire.
Il ne demande pas à chaque application de redessiner son propre système d’exécution : il fournit plutôt une méthode plus standardisée, qui permet aux applications de combiner différents Policy selon les besoins, afin de construire des processus d’automatisation plus flexibles.
L’Automation Intent présenté dans le livre blanc constitue également une direction importante. Dans le passé, les interactions on-chain consistaient davantage en instructions précises données par les utilisateurs ; à l’avenir, des applications plus complexes exigeront de comprendre les objectifs que l’utilisateur cherche à atteindre. Le système doit passer d’un enchaînement d’étapes d’exécution individuelles à l’accomplissement de tâches plus longues.
Et derrière cela, il ne faut pas seulement des capacités d’exécution de code : il faut aussi une couche de base capable d’orchestrer le processus d’exécution.
En plus, dans la conception de Newton, la combinaison de l’Operator Network avec les technologies TEE et ZK fait partie, selon moi, des éléments les plus clés. Un système d’automatisation ne doit pas seulement exécuter : il doit aussi permettre de valider le processus d’exécution. Le TEE fournit un environnement d’exécution digne de confiance ; ZK permet de valider certains résultats tout en réduisant l’exposition inutile d’informations.
Cela fait évoluer tout le processus d’automatisation, qui passe progressivement de « faire confiance à un exécuteur » à « vérifier si l’exécution respecte les conditions ».
Bien sûr, je ne jugerai pas qu’une direction technologique réussira forcément simplement parce qu’elle paraît correcte.
Le plus grand défi d’un projet d’infrastructure, c’est de passer d’une proposition technique à une utilisation réelle. Dans la suite de Newton, il faudra prouver que les développeurs sont prêts à l’intégrer, que les applications sont disposées à l’adopter et que le réseau Operator peut fonctionner de façon continue.
Concernant $NEWT, je m’intéresse davantage aux données de l’écosystème qu’aux variations de prix à court terme.
Si le monde on-chain devient de plus en plus complexe à l’avenir, des infrastructures capables de relier applications, règles et exécution pourraient occuper une place de plus en plus importante.
Par le passé, nous nous préoccupions surtout de savoir qui créait de nouveaux actifs.
À l’avenir, je m’intéresserai davantage à la question de savoir qui saura faire tourner ces ressources et applications de manière plus efficace.
C’est aussi la raison pour laquelle je continue d’observer Newton.