J’ai eu une transaction qui a échoué un peu plus tôt dans la journée, totalement sans rapport avec un autre projet. Une approbation… n’a tout simplement pas abouti, sans raison claire, et je suis resté là, légèrement agacé, pendant une seconde avant de reprendre ma journée comme d’habitude.

Puis, plus tard, par curiosité, je suis retourné sur la tâche du protocole Newton et cette transaction qui avait échoué continuait de me hanter tout le temps, pour des raisons que je n’avais pas prévues.

Parce que voilà le point qui s’est avéré être étrange — je crois que j’ai passé des années à considérer « transaction réussie » comme le bon résultat et « transaction bloquée » comme le désagrément. Chaque expérience utilisateur de portefeuille, chaque choix de design, renforce ça. Case verte qui coche bien, erreur rouge pas bien. Mais en m’asseyant avec toute l’approche de Newton sur le périmètre des permissions, je me suis mis à me demander si je n’avais pas cette logique inversée plus souvent que je ne voudrais l’admettre. Une transaction bloquée n’est pas un échec du système. Parfois, c’est le système qui fait exactement la seule chose utile qu’il est censé faire.

Version simple du mécanisme — les gens supposent que le travail d’un wallet consiste à exécuter ce que vous demandez, sans problème, à chaque fois, et que tout ce qui l’interrompt est de la friction ou un bug. En réalité, avec des autorisations « scoped » (encadrées), c’est différent : le wallet ne demande pas « est-ce que je peux exécuter ceci », il demande plutôt « est-ce que cela entre bien dans ce que j’ai déjà accepté d’autoriser ». Quand ce n’est pas le cas, le refus n’est pas un dysfonctionnement : c’est la couche d’autorisations qui fonctionne comme prévu. J’avais, mentalement, classé chaque action bloquée dans la catégorie « pénible », jamais dans « correct ».

Mais voici la partie qui me dérange, et je n’en suis pas encore là. Si le refus commence à paraître normal et même positif, comment fait-on la différence entre « cette demande a été bloquée parce qu’elle sortait du champ sûr » et « cette demande a été bloquée parce que le champ a été défini incorrectement dès le départ » ? Les deux semblent identiques du côté de l’utilisateur — une transaction échouée. Je pensais que prendre un peu de recul avec cette idée finirait par clarifier la distinction pour moi. Non. Je ne suis vraiment pas sûr de la façon dont un utilisateur est censé distinguer un refus intelligent d’un refus cassé sans aller fouiller dans la politique elle-même, ce que la plupart des gens ne feront pas.

Pourquoi cela compte, je pense, dépend beaucoup de la personne qui observe la transaction bloquée. Pour un développeur ou quelqu’un qui audite la logique d’autorisations, un refus est une donnée — utile, attendu, parfois même l’objectif principal. Pour un utilisateur lambda qui essaie juste d’effectuer quelque chose de récurrent, un refus n’est que de la friction, point final, quelle qu’en soit la cause. Cet écart entre ces deux réactions à exactement le même événement me semble plus important que le mécanisme lui-même.

Petit moment — après ma propre transaction échouée plus tôt, je suis allé vérifier le champ d’approbation par habitude, en m’attendant à un bug. Ce n’en était pas un. Je l’avais simplement défini trop étroitement il y a des mois et j’avais oublié. Donc, dans mon cas, le résultat « le plus sûr » et le résultat « le plus pénible » étaient littéralement le même événement, et seule mon propre oubli a décidé de ce que j’en percevais.

Quoi qu’il en soit. Je ne vais pas m’en tenir à un refus clair sur ce point. Je vais peut-être juste surveiller l’évolution des messages de refus : est-ce qu’ils finissent par s’expliquer réellement, ou est-ce qu’ils restent aussi vagues qu’actuellement.

@NewtonProtocol #Newt $NEWT