À mon avis, la canonisation est l’étape au cours de laquelle Newton transforme un Intent ambigu en une entrée suffisamment précise pour qu’une Policy puisse l’évaluer de manière cohérente.
Un Intent brut peut arriver sous de nombreuses formes. Pour une même demande d’échange, un utilisateur peut saisir 1 ETH, un autre peut utiliser 10¹⁸ wei, tandis qu’une autre personne peut désigner l’actif par son symbole de token plutôt que par son adresse de contrat. Une date limite peut être fournie ou omise, car l’utilisateur suppose que le système saura la déduire.
Pour un humain, ces expressions peuvent sembler équivalentes.
Pour un moteur de Policy, elles ne constituent pas la même entrée.
Avant l’évaluation, Newton doit analyser l’Intent en composants définis : qui demande l’action, quelle action est demandée, quel actif et quelle cible sont concernés, et quelles contraintes régissent l’exécution.
Ce n’est qu’alors que la normalisation peut commencer.
Les identifiants d’actifs, les montants, les chaînes, les destinataires, les dates limites, le slippage et les autres contraintes doivent tous disposer de références, d’unités, de types et de formats standardisés afin que l’ordre des champs ne puisse pas modifier le sens de l’Intent.
Les valeurs par défaut doivent également suivre une règle commune. Lorsqu’un champ requis manque ou qu’un paramètre permet plusieurs interprétations, le système ne devrait pas laisser chaque opérateur faire sa propre supposition. L’Intent doit être considéré comme invalide ou insuffisamment spécifié avant que la Policy ne s’exécute.
Une fois les champs validés et normalisés, Newton peut construire une représentation canonique : un objet sémantique unique représentant l’Intent original. Il peut ensuite le sérialiser selon les mêmes règles, garantissant que chaque opérateur reçoit la même structure, les mêmes valeurs et le même sens.
C’est, pour moi, la partie essentielle.
Une Policy ne doit pas évaluer les mots que l’utilisateur a saisis. Elle doit évaluer l’Intent normalisé, après suppression des différences de format, d’unités et d’expression.
Si cette étape échoue, même une Policy déterministe ne peut pas sauver le système.
Newton ne peut préserver la cohérence de l’autorisation que lorsque chaque opérateur reçoit le même Intent canonique avant l’évaluation par la Policy.
@NewtonProtocol $NEWT #Newt $LAB $BTW
Un Intent brut peut arriver sous de nombreuses formes. Pour une même demande d’échange, un utilisateur peut saisir 1 ETH, un autre peut utiliser 10¹⁸ wei, tandis qu’une autre personne peut désigner l’actif par son symbole de token plutôt que par son adresse de contrat. Une date limite peut être fournie ou omise, car l’utilisateur suppose que le système saura la déduire.
Pour un humain, ces expressions peuvent sembler équivalentes.
Pour un moteur de Policy, elles ne constituent pas la même entrée.
Avant l’évaluation, Newton doit analyser l’Intent en composants définis : qui demande l’action, quelle action est demandée, quel actif et quelle cible sont concernés, et quelles contraintes régissent l’exécution.
Ce n’est qu’alors que la normalisation peut commencer.
Les identifiants d’actifs, les montants, les chaînes, les destinataires, les dates limites, le slippage et les autres contraintes doivent tous disposer de références, d’unités, de types et de formats standardisés afin que l’ordre des champs ne puisse pas modifier le sens de l’Intent.
Les valeurs par défaut doivent également suivre une règle commune. Lorsqu’un champ requis manque ou qu’un paramètre permet plusieurs interprétations, le système ne devrait pas laisser chaque opérateur faire sa propre supposition. L’Intent doit être considéré comme invalide ou insuffisamment spécifié avant que la Policy ne s’exécute.
Une fois les champs validés et normalisés, Newton peut construire une représentation canonique : un objet sémantique unique représentant l’Intent original. Il peut ensuite le sérialiser selon les mêmes règles, garantissant que chaque opérateur reçoit la même structure, les mêmes valeurs et le même sens.
C’est, pour moi, la partie essentielle.
Une Policy ne doit pas évaluer les mots que l’utilisateur a saisis. Elle doit évaluer l’Intent normalisé, après suppression des différences de format, d’unités et d’expression.
Si cette étape échoue, même une Policy déterministe ne peut pas sauver le système.
Newton ne peut préserver la cohérence de l’autorisation que lorsque chaque opérateur reçoit le même Intent canonique avant l’évaluation par la Policy.
@NewtonProtocol $NEWT #Newt $LAB $BTW