Résumé

  • La révision 05 déplace atomiquement le montant de « réservé » à « consommé » au moment où l’entrée chez le prestataire est enregistrée, avant l’appel susceptible de produire un effet externe.
  • Après cette frontière, une réponse absente donne un résultat indéterminé, pas une preuve de non-entrée ; restituer le montant pourrait financer deux fois la même conséquence.
  • Révocation et gel d’urgence ne bloquent l’opération que s’ils gagnent l’ordre de sérialisation avant l’entrée ; ils ne réécrivent pas un effet déjà possible.

Le solde n’est pas un message d’erreur

Imaginons une enveloppe de 2 500 unités confiée à un agent pour des achats bien délimités. Une opération de 800 unités est réservée. La requête part, puis l’interface affiche un délai dépassé. Le réflexe applicatif consiste souvent à remettre 800 dans le solde. Or le fournisseur peut déjà avoir franchi son propre point d’acceptation. Le logiciel local ne sait plus si le bien sera livré, mais il sait moins encore que rien ne s’est passé.

Le document Bounded Capability Receipts and Durable Spend Control for Agent Actions propose de séparer le reçu signé du registre vivant qui conserve l’autorité. Le reçu fixe l’émetteur, le détenteur, la portée, l’unité, le plafond, la durée et l’éventuelle filiation. La signature rend cette déclaration contrôlable ; elle n’empêche pas deux exécutants ou deux reprises après panne d’utiliser le même reste. Le projet exige donc un domaine d’état atomique commun.

Le calcul est simple : reste = total − consommé − réservé. Toute la gouvernance se cache dans le moment où « réservé » devient « consommé ».

La révision 04 enregistrait l’entrée prestataire avant l’adaptateur externe, puis débitait lors du commit de résultat. La révision 05 resserre la frontière. Dans une même transaction, juste avant l’entrée, le registre authentifie le propriétaire de la réservation, vérifie l’échéance, relit l’état actuel de la capacité, les autorisations et les révocations applicables, compare éventuellement l’époque du domaine d’admission, écrit provider_entered, diminue le réservé et augmente le consommé. L’adaptateur n’est appelé qu’ensuite.

Le résultat ultérieur ne débite plus. Il ferme l’opération comme exécutée ou indéterminée. Ce déplacement évite qu’une opération soit déjà entrée chez le prestataire tout en paraissant encore remboursable.

Il faut prouver la non-entrée

Le projet distingue deux absences. indeterminate signifie que l’effet a pu commencer, sans preuve suffisante de réussite ni d’absence. Le montant reste consommé. not_entered exige que l’état autoritaire montre une réservation encore intacte et l’absence d’entrée prestataire. Seul ce second cas permet de libérer la réservation.

Même après libération, la clé d’opération demeure comme pierre tombale anti-rejeu. Le système rend de la capacité inutilisée ; il ne transforme pas la même demande en nouvelle demande. Un timeout n’autorise donc pas l’appelant à inventer un nouvel identifiant pour recommencer.

Cette asymétrie sacrifie parfois la disponibilité. Elle évite surtout qu’une incertitude devienne une duplication irréversible. Une commande, un virement ou une suppression lancés deux fois ne sont pas corrigés par un compteur remis à zéro.

Le gel d’urgence a un ordre précis

La révision 05 ajoute un domaine d’admission optionnel doté d’un état actif ou gelé et d’une époque croissante. La réservation capture l’époque ; l’entrée la relit dans la transaction décisive. Si le gel ou la révocation est sérialisé en premier, l’entrée est refusée et la non-entrée peut être attestée. Si l’entrée gagne, le gel bloque les actes suivants mais ne rembourse pas celui-ci.

Il ne s’agit pas d’un interrupteur universel. Le mécanisme ne stoppe pas un calcul déjà lancé, n’annule pas un effet externe et ne synchronise pas instantanément des domaines déconnectés. Il dépend aussi de l’adaptateur pour placer honnêtement la frontière réelle.

Le statut institutionnel doit rester clair. La page Datatracker présente la révision 05 comme un Internet-Draft individuel actif, état IESG I-D Exists, sans approbation de l’IETF. Le texte vise l’Experimental, alors que le résumé Datatracker n’affiche actuellement aucun statut RFC prévu. C’est une proposition testable, non une norme ni une preuve de déploiement.

Les RFC sur la canonisation JSON, Ed25519, l’heure Internet et le langage normatif rendent les objets et exigences reproductibles. Elles ne démontrent ni le bon placement de la frontière chez un fournisseur, ni l’effet final. C’est précisément pourquoi les couches — autorité signée, état courant, admission externe, résultat observé — doivent rester séparées.

Sources