Au départ, je pensais qu’@NewtonProtocol concernait principalement la conformité programmable. Après avoir passé plus de temps avec l’architecture, j’ai constaté que je prêtais moins attention aux politiques individuelles et davantage à l’endroit où ces politiques résident réellement. Ce changement a modifié la façon dont j’ai envisagé le protocole.
La conception sépare l’autorisation de l’exécution d’application, plutôt que d’intégrer des règles métier directement dans chaque contrat intelligent. Les politiques écrites en Rego définissent la logique d’autorisation, tandis que les applications individuelles fournissent leurs propres contraintes opérationnelles via la configuration de PolicyClient. Les limites de dépenses, les destinataires approuvés, les restrictions juridictionnelles et des exigences similaires deviennent une configuration d’exécution structurée plutôt qu’une logique de politique encodée de façon permanente.
Cette distinction semble plus importante qu’elle n’en a l’air au premier abord. Une seule politique peut rester réutilisable tandis que différentes applications fonctionnent dans des limites d’autorisation différentes, simplement en modifiant la configuration. La politique décrit le processus de décision. L’application fournit le contexte. Ces responsabilités sont volontairement indépendantes.
Mais quelque chose continuait à m’inquiéter.
La réutilisabilité ne fonctionne que si l’autorisation reste liée aux hypothèses exactes qui l’ont produite. Newton y répond en générant un nouvel identifiant de politique chaque fois que la configuration de PolicyClient change. Les attestations produites sous une configuration antérieure ne s’appliquent plus lorsque l’identifiant de politique référencé change. L’autorisation devient donc liée non seulement à la logique de la politique, mais aussi à la configuration précise qui existait au moment de l’approbation.
Le design modifie la frontière.
Au lieu de modifier le code de l’application à chaque fois que les exigences opérationnelles évoluent, les développeurs ajustent les politiques ou la configuration tout en préservant la logique de l’application. Cela peut simplifier la maintenance sur plusieurs applications, mais cela déplace aussi la responsabilité vers la gestion des politiques. La configuration devient alors une partie du modèle de sécurité plutôt qu’un simple détail de déploiement. Les informations externes introduisent une autre couche de responsabilité. Les PolicyData Oracles s’exécutent en tant que composants WASM isolés, renvoyant des données structurées d’exécution que les politiques évaluent de manière déterministe. L’exécution restreint intentionnellement l’accès réseau, et les échecs sont traités différemment selon l’endroit où ils surviennent. Les erreurs d’application structurées restent visibles pour l’évaluation de la politique, tandis que les échecs d’exécution deviennent des événements DataProviderError qui arrêtent l’autorisation entièrement au lieu de produire une décision normale.
Cela ne supprime pas la confiance. Cela la déplace.
L’expiration de l’attestation introduit une autre décision opérationnelle. Des fenêtres d’approbation courtes réduisent les possibilités de relecture, tandis que des fenêtres plus longues offrent aux utilisateurs plus de flexibilité avant l’exécution. Aucun des deux choix ne correspond à des fenêtres d’expiration qui équilibrent la résistance à la relecture et la facilité d’utilisation. Les utilisateurs interagissent finalement avec des attestations dont la validité reflète à la fois la version de la politique et le contexte d’exécution, plutôt que l’état du contrat seul.
Vu sous cet angle, Newton semble moins axé sur le remplacement de la logique des smart contracts que sur le déplacement de l’endroit où évolue l’autorisation à mesure que les exigences de l’application changent.
Déplacer l’évolution des politiques hors des contrats déployés simplifie-t-il la sécurité à long terme, ou crée-t-il simplement une couche différente où la complexité opérationnelle s’accumule ?
$NEWT #Newt $SUI $ETH