Avant, quand nous comprenions les interactions on-chain, nous faisions surtout attention à savoir si la transaction elle-même réussissait. Une fois que la transaction est diffusée, confirmée par le bloc, et que les actifs changent, tout le processus est simple et direct. Mais quand les applications deviennent plus complexes, les vrais problèmes commencent à apparaître. Une transaction peut être liée à plusieurs protocoles ; une stratégie peut contenir plusieurs étapes ; un programme d’automatisation peut nécessiter une exécution sur le long terme. À ce stade, un résultat « réussi » ne signifie pas nécessairement que le processus a respecté l’objectif initial.
C’est aussi pour cela que je me suis intéressé ensuite au protocole Newton.
Beaucoup de gens mentionnent Newton et le placent dans le récit des AI Agents ou de l’automatisation, mais je pense que le problème qu’il cherche à résoudre est plus fondamental : comment faire en sorte que les comportements d’automatisation on-chain fonctionnent selon des règles clairement établies. À l’avenir, la question n’est pas de savoir si la machine peut exécuter, mais si, pendant l’exécution, elle comprend les limites, respecte les conditions, et peut prouver que ses actions correspondent à ce qui est attendu.
La conception centrale du livre blanc de Newton s’articule justement autour de ce point.
L’Authorization Layer qu’il propose n’est pas simplement l’ajout d’un bouton de permission. Elle met en place, entre l’application et l’exécution, une couche de mécanisme de décision basé sur des règles. Dans le passé, les smart contracts résolvaient surtout « comment le code s’exécute », mais Newton veut compléter « dans quels cas l’exécution devrait avoir lieu ».
Cette distinction est très importante.
Dans le modèle traditionnel, l’utilisateur autorise une action ; cela signifie généralement qu’une certaine capacité est confiée à l’application. Mais dans des scénarios complexes, cette approche n’est pas assez fine. Une stratégie d’automatisation peut avoir besoin de limiter une fourchette de montants ; un système de gestion d’actifs peut devoir satisfaire à des conditions spécifiques ; un programme on-chain peut devoir respecter une logique prédéfinie. Si toutes les décisions sont figées à l’intérieur de l’application, le coût de modification par la suite sera très élevé.
Le Policy Framework de Newton, c’est l’abstraction de ces conditions complexes en règles programmables.
Cela permet aux développeurs de définir différents types de logique d’exécution, y compris ce qui est autorisé, ce qui est limité, à quelles conditions une action est déclenchée, et quelles exigences doivent être respectées pendant l’exécution. Ainsi, une application n’est plus seulement un appel à un contrat fixe : elle peut combiner différentes stratégies selon différents scénarios.
Je pense que c’est aussi la plus grande différence entre Newton et les outils d’automatisation classiques.
Elle ne se contente pas d’aider les utilisateurs à réduire le nombre d’étapes : elle cherche à établir un nouveau mode d’exécution, afin que le système puisse accomplir des tâches dans le cadre des règles.
C’est lié à la conception de l’Automation Intent.
Auparavant, les interactions on-chain ressemblaient davantage à ceci : l’utilisateur dit au système « je veux faire telle action ». Par exemple, échanger des actifs, transférer des fonds, appeler un certain protocole. Mais dans des scénarios plus complexes à l’avenir, l’utilisateur peut davantage se soucier du résultat que de chaque étape d’exécution.
Par exemple, l’utilisateur souhaite que l’actif conserve un certain état ; que la stratégie s’ajuste en fonction des variations du marché ; qu’une tâche s’exécute automatiquement sur le long terme.
À ce moment-là, ce que le système doit comprendre, ce n’est pas une instruction unique, mais l’objectif.
Newton essaie de faire exprimer l’objectif par l’Intent, puis d’associer des contraintes de Policy afin que le processus d’automatisation corresponde davantage à la logique prévue.
Bien sûr, après avoir défini les objectifs et les règles, il reste une question clé : comment prouver que le processus d’exécution ne s’est pas écarté.
C’est aussi la valeur de Verifiable Automation dans l’architecture de Newton.
Grâce à l’Operator Network, l’exécution des tâches ne dépend plus entièrement d’un seul exécutant : un mécanisme de coordination et de vérification se met en place. En combinant aussi les technologies TEE et ZK, le système peut garantir un environnement d’exécution digne de confiance tout en donnant aux résultats une capacité de vérification.
En bref, le TEE résout le problème de l’environnement d’exécution : faire tourner le processus de calcul dans des conditions dignes de confiance. Le ZK résout le problème de la preuve : permettre au système de prouver que certains résultats répondent aux exigences, sans avoir à divulguer tous les détails.
Ce qui m’a semblé particulièrement intéressant dans cette conception, c’est que Newton n’a pas mis l’accent sur « rendre l’automatisation plus rapide », mais sur « la rendre plus fiable ».
Parce que lorsque le on-chain fonctionnera à grande échelle à l’avenir, l’efficacité sera bien sûr importante, mais la crédibilité le sera tout autant.
Du point de vue du marché, je pense que beaucoup de projets se concentrent sur la façon de créer de nouvelles applications, tandis que Newton cherche à permettre à davantage d’applications complexes de fonctionner durablement. Ce type d’infrastructure attire souvent moins l’attention que les projets applicatifs, mais les problèmes qu’elle résout sont généralement plus fondamentaux.
Bien sûr, Newton a encore besoin d’être validé par le marché. L’architecture du livre blanc n’est que le début : ce qui compte vraiment, c’est de savoir s’il y aura davantage d’applications connectées dans le futur, si des contextes d’usage réels utilisent ces capacités, et si l’ensemble du réseau peut créer un écosystème durable en fonctionnement continu.
Pour $NEWT, je me soucie moins des variations de prix à court terme que du fait qu’il puisse devenir un module de base au sein d’un système d’automatisation on-chain.
Autrefois, la blockchain résolvait le transfert d’actifs ; les smart contracts résolvaient l’exécution de règles. Et Newton explore, lorsque de plus en plus de tâches sont accomplies automatiquement par le système, comment faire en sorte que ces comportements s’alignent toujours sur un objectif clairement défini.
Si le monde on-chain entre vraiment dans une phase d’automatisation hautement avancée, une infrastructure capable de connecter l’objectif, les règles et l’exécution pourrait devenir une couche extrêmement importante.