Depuis trois jours, le marché ne fait rien d’intéressant, alors je me suis retrouvé dans la documentation du registre de modèles de Newton Network. Soit c’est une utilisation productive du temps lent du marché, soit c’est un signe que j’ai besoin de meilleurs passe-temps.
Le registre fait partie de ces composants qu’on mentionne dans l’aperçu de l’écosystème de Newton, puis qu’on passe presque sous silence au profit du récit plus vendeur « compliance-as-code ». C’est dommage, parce que les modèles modulaires sur lesquels repose le fonctionnement réel du registre valent la peine d’être compris si vous essayez d’évaluer si l’écosystème développeur de Newton a de l’avenir.
Alors j'ai commencé à lire attentivement. Et l'idée centrale autour de laquelle le registre a été construit, c'est que les modèles d'IA déployés sur Newton ne devraient pas être des artefacts monolithiques. Ils devraient être composables. Un modèle qui gère le filtrage des sanctions ne devrait pas avoir besoin d'inclure sa propre logique de vérification d'identité. Un modèle qui gère les ratios de collatéral ne devrait pas avoir besoin de reconstruire sa propre intégration de flux de prix. L'architecture du registre permet aux développeurs de publier des composants de modèle distincts que d'autres développeurs peuvent composer pour créer des comportements d'agents plus complexes, sans tout reconstruire à partir de zéro.
C'est une bonne conception en théorie. La composabilité est la façon dont fonctionnent les écosystèmes matures de développeurs. L'écosystème Ethereum DeFi est devenu puissant parce que les protocoles pouvaient être empilés. Newton essaie de construire la même propriété dans sa couche de modèle IA, où l'unité de composition est un composant de modèle vérifié plutôt qu'un smart contract.
Voici ce qui m'a réellement arrêté en lisant. La promesse de composabilité crée un problème de dépendance spécifique que la documentation traite de façon moins approfondie que les bénéfices de la composabilité qu'elle met en avant. Lorsque vous composez plusieurs modèles de registre dans un seul comportement d'agent, vous héritez du profil de risque de chaque composant de la pile. Un modèle de filtrage des sanctions qui n'a pas été mis à jour depuis qu'une nouvelle liste de désignations est sortie, combiné à un modèle de gestion des garanties qui a son propre calendrier de mise à jour, crée un agent qui s'exécute avec des garanties de fraîcheur non alignées.
Dans un système composé, la fiabilité globale est limitée par le composant le moins fiable. Le registre a besoin d'une réponse claire sur la manière dont les piles de modèles composés exposent l'état de la mise à jour et l'historique de fiabilité de chaque composant dont elles dépendent. J'ai trouvé des références à la gestion de versions dans l'architecture du registre, mais moins de clarté sur la façon dont les dépendances de version se propagent à travers des piles composées, ou sur la manière dont les développeurs sont informés lorsqu'un composant dont leur modèle dépend a été mis à jour ou a été déprécié.
Le modèle de redevances ajoute une autre couche de complexité qui mérite d'être examinée. Les modèles du registre génèrent des redevances lorsque d'autres développeurs les utilisent comme composants dans des agents composés. Cette structure d'incitation est intéressante et probablement dans la bonne direction. Les développeurs qui publient des composants vraiment utiles devraient tirer une valeur continue de cette contribution.
Mais voici le mécanisme qui me dérange franchement. Si un composant du registre d'un développeur devient largement utilisé comme dépendance dans d'autres agents, il a une incitation financière à le maintenir et une incitation financière à ne pas le déprécier même lorsque la dépréciation serait la décision technique correcte. Les composants largement sollicités finissent par accumuler une dette technique dans n'importe quel écosystème. Le modèle de redevances crée une raison supplémentaire de les faire tourner plutôt que de les remplacer par de meilleures implémentations. Cette tension entre l'incitation financière et l'hygiène technique est réelle, et je ne la vois pas traitée explicitement dans la documentation de gouvernance.
Les modèles modulaires avancés que Newton construit dans le registre sont réellement sophistiqués par rapport à ce que la plupart des protocoles d'automatisation IA ont tenté. Le modèle de composition a du sens. La gestion des dépendances de version et la gouvernance des décisions concernant le cycle de vie des composants sont les éléments qui nécessitent encore plus de développement avant que la promesse de modularité tienne pleinement dans des conditions de production.
La plupart des infrastructures les plus intéressantes font bien ces détails dans la version deux. Newton en est encore à une version où l'architecture est la bonne et où les détails opérationnels sont en cours d'élaboration en temps réel.
C'est là que se trouvent en réalité la plupart des choses qui valent la peine d'être surveillées.