Cette semaine, j’ai séparé les trois piliers de Newton pour les examiner Verifiable Credentials Programmable Policies CrossChain Interoperability afin de comprendre lequel est le plus développé, où se situent les plus grandes lacunes, et lequel génère le plus de risques de dépendance pour les applications qui se construisent sur Newton dès maintenant.
Les trois piliers n’ont pas le même niveau de maturité, et les traiter comme équivalents sous-estime le profil de risque d’une adoption précoce.
Programmable Policies est le pilier le plus mature. Rego OPA est un langage de politique d’entreprise établi, avec un outillage étendu et plusieurs années d’utilisation en production pour le contrôle d’admission Kubernetes et l’autorisation d’API. Les extensions Rego de Newton ajoutent de nouvelles capacités sur une base stable. L’évaluation de la politique via des fournisseurs de données WASM exécutés dans un bac à sable stockage adressé par contenu IPFS et l’évaluation attestée par BLS est techniquement bien spécifiée. Le moteur de politique est la partie la plus claire et la plus complète du design de Newton.
L’interopérabilité inter-chaînes est mature au niveau de la spécification, mais dépend de normes externes. Le modèle source/chaîne de destination, la synchronisation de la racine Merkle signée par BLS et la conformité à l’ELIP 008 sont clairement définis. Le risque de dépendance : ce pilier hérite à la fois des trajectoires d’évolution d’EigenLayer et des chaînes de destination. Les propriétés inter-chaînes de Newton ne sont aussi stables que les spécifications dont elles dépendent.
Les attestations vérifiables sont le pilier le moins mature en pratique. La norme W3C est solide. La conception de Newton Identity Oracle est bien spécifiée. Mais l’écosystème des émetteurs n’existe pas encore à grande échelle : qui émet réellement des attestations KYC, des attestations financières et des attestations de comportement onchain au format compatible avec Newton, à des volumes de production pour de vrais utilisateurs ? La portabilité des attestations n’est utile que lorsque des attestations sont effectivement émises et acceptées dans plusieurs applications. Cet écosystème est en construction, pas encore utilisé.
En fait, je pense que l’écart de maturité dans l’écosystème des émetteurs d’attestations est la contrainte pratique la plus importante pour l’adoption à court terme de Newtons, plus que toute limitation technique. Le moteur de politique est prêt. Les attestations qu’il doit évaluer ne sont pas encore largement disponibles.
Ce que je n’ai pas encore déterminé, c’est qui supporte le coût de la construction de l’écosystème d’émetteurs : l’équipe centrale de Newton, ses partenaires institutionnels, ou un écosystème tiers qui doit être incité avant que les effets de réseau deviennent réels.