@NewtonProtocol Je me suis surpris à penser à quel point une autorisation utile peut devenir quelque chose de plus grand que ce que l'utilisateur avait l'intention d'accorder.
Pas parce que l'utilisateur avait l'intention d'abandonner le contrôle.
Parce que la plupart des systèmes de crypto donnent l'impression que la délégation est une petite autorisation, même quand cette autorisation peut ensuite décider de la manière dont les fonds bougent.
C'est là que le problème commence pour moi. Un utilisateur peut vouloir qu'une application exécute une action récurrente, qu'un agent réagisse à des conditions changeantes, ou encore qu'un gestionnaire de coffre-fort respecte un mandat sans demander une validation manuelle à chaque fois. La commodité a du sens. Personne ne veut confirmer indéfiniment chaque petite action.
Mais dès qu’un autre système peut agir au nom de l’utilisateur, la question change.
Ce n’est plus seulement : « qui a accès ? »
Cela devient : « qu’est-ce que exactement cet accès est autorisé à faire ? »
C’est la ligne autour de laquelle il semble que le protocole Newton travaille. La partie la plus importante n’est pas l’automatisation elle-même. C’est le point de contrôle avant l’exécution. Avant qu’une action protégée ne se stabilise, l’intention de la transaction peut être vérifiée par rapport à une politique. Les opérateurs évaluent cette politique, renvoient une attestation signée, et le contrat intégré peut vérifier cette preuve avant d’autoriser la poursuite de l’exécution.
Cela change la forme de la délégation.
Au lieu de donner à un système une autorité étendue et d’espérer qu’il se comportera correctement, l’autorisation peut être liée à une règle. Une politique Rego peut vérifier l’intention de la transaction, les paramètres configurés et les données de runtime provenant d’oracles PolicyData. Cela signifie que la décision peut dépendre de conditions, de limites, de contextes externes ou d’exigences propres à l’application, plutôt que d’être uniquement basée sur une signature valide.
C’est pour cela que le titre compte pour moi.
La délégation n’est pas automatiquement dangereuse.
Une délégation non définie l’est.
Une approbation de portefeuille ou une autorisation automatisée peut sembler inoffensive quand un utilisateur l’accepte d’abord. Le vrai risque apparaît souvent plus tard, lorsque le système commence à agir en dehors de l’attente de l’utilisateur, ou lorsque les conditions initiales ne s’appliquent plus. En crypto, les gens accordent souvent l’accès en premier et ne comprennent la vraie limite qu’après qu’une action a déjà été exécutée.
Newton essaie de déplacer cette limite plus tôt.
Mais cela n’enlève pas la partie difficile.
Une attestation signée peut prouver qu’une politique a été respectée pour une action donnée. Elle ne prouve pas que la politique elle-même était avisée. Quelqu’un définit toujours la règle. Quelqu’un choisit les limites. Quelqu’un décide quelle source de données compte et ce qui doit se passer lorsque ces données sont manquantes, en retard ou incorrectes.
C’est cette tension.
Une politique solide peut maintenir les systèmes délégués dans une plage de fonctionnement claire. Une politique faible peut faire paraître la même délégation plus sûre qu’elle ne l’est réellement. Le chemin d’application peut être plus propre, mais le jugement derrière la règle compte toujours.
Donc je ne vois pas Newton comme une simple histoire d’automatisation.
La question la plus sérieuse est de savoir si les apps, les agents et les coffres peuvent agir pour les utilisateurs sans transformer l’accès délégué en confiance aveugle.
C’est la ligne fine.
La délégation est utile lorsque la limite est claire.
Cela devient une reddition quand le système peut agir sans consentement.
