Summary
- Le projet individuel propose qu’un émetteur évalue une condition sur un portefeuille à un état de chaîne référencé, puis retourne un booléen signé vérifiable hors ligne grâce à JWKS.
- Dans le format JSON, seuls
id,pass,resultsetattestedAtcomposent les octets signés ;expiresAt,kid, les enveloppes et, en général, l’identité du portefeuille restent à côté. - Une signature valide authentifie une observation déclarée par l’émetteur. Elle ne prouve ni la finalité du bloc, ni l’actualité de l’état, ni l’absence de rejeu, ni l’autorisation de l’action suivante.
Le résultat peut être exact et déjà périmé
Un service demande si un portefeuille détient encore un montant minimal. L’émetteur interroge une source de chaîne, choisit un bloc, répond pass: true et signe. Quelques secondes plus tard, la signature se vérifie parfaitement. Entre-temps, les actifs ont pu être déplacés, la source de données pouvait être en retard ou une réorganisation a pu retirer l’état observé de l’histoire canonique.
La cryptographie n’a pas menti. Elle a simplement attesté une phrase plus étroite que celle affichée par le tableau de bord. Le signataire répond de l’évaluation et des ancrages enregistrés ; il ne gèle pas le monde.
Le texte a été publié le 27 septembre 2026 comme Internet-Draft individuel. Datatracker indique Active et I-D Exists, sans stream. Le document profile JWT, JWKS et JOSE ; il ne définit pas un nouveau protocole filaire. Il ne faut donc lui attribuer ni adoption par un groupe de travail, ni consensus IETF, ni interopérabilité ou déploiement démontré.
La surface signée est volontairement étroite
Le format JSON signe quatre membres : id, pass, results, attestedAt. Chaque résultat contient la condition évaluée, son hash et une référence de chaîne. Un bloc et son horodatage servent pour EVM ; XRPL emploie un index de ledger et, si disponible, son hash ; Solana fournit un slot ; Bitcoin une hauteur et un hash de pointe.
La révision 01 maintient un schéma « bare », sensible à l’ordre exact des membres transmis, et ajoute un schéma séparé par domaine. Celui-ci préfixe un type de message et une version puis emploie la canonisation RFC 8785. Cette amélioration réduit les désaccords sur les octets à vérifier. Elle ne certifie pas la source RPC, l’indexeur, la disponibilité des données ou la finalité du bloc.
kid choisit la clé et le schéma dans le JWKS de l’émetteur. Une valeur absente ou inconnue donne « unverifiable », pas « refuted » ; aucune clé de remplacement ne doit être essayée. Deux vérificateurs possédant des caches JWKS d’âges différents peuvent donc rendre des verdicts distincts sur le même artefact sans que l’un ait découvert une fausse signature.
La liaison au portefeuille varie avec le format. L’objet JSON signé ne nomme généralement pas le portefeuille. Certaines conditions intègrent l’adresse dans evaluatedCondition, mais un destinataire secondaire ne doit pas l’inventer. Le JWT signe sub et exp. Il doit être vérifié séparément : la signature JSON voisine ne couvre pas ses claims.
La fraîcheur est une règle, pas un champ
Les références de chaîne dans results et attestedAt sont les ancrages de fraîcheur protégés. Leur acceptation dépend pourtant d’une politique locale. L’âge de la signature et celui du bloc ne sont pas interchangeables. Une signature produite à l’instant peut décrire un bloc trop ancien pour un paiement immédiat.
Dans JSON, expiresAt est un conseil TTL non signé. La révision 01 demande au vérificateur qui s’y fie de le borner par attestedAt signé et la fenêtre documentée par l’émetteur. Le JWT offre un exp signé. Mais la vérification d’expiration reste RECOMMENDED : un système doit conserver si ce contrôle a réellement été exécuté, au lieu de le déduire d’un voyant vert.
Le rejeu n’est pas résolu par la seule fraîcheur. id peut alimenter une mémoire des identifiants vus ; le nonce et l’audience restent à définir dans le profil d’intégration. Un objet encore récent peut donc être présenté dans une autre transaction ou à un autre destinataire.
La chaîne possède sa propre horloge
Le projet laisse hors périmètre la sélection RPC, le choix d’indexeur, les nœuds d’archive, la finalité et le traitement des réorganisations. Il reconnaît qu’une réorganisation postérieure peut rendre non canonique l’état signé. Profondeur de confirmation, chaîne à finalité forte, contrôle indépendant et procédure d’invalidation restent des choix d’exploitation.
Le conditionHash démontre que la condition transmise n’a pas été changée. Il ne démontre pas que l’émetteur a lu la bonne chaîne ou choisi le bon seuil commercial. Une preuve de Merkle peut réduire la confiance accordée à l’évaluation pour une racine donnée ; la racine doit encore être reconnue comme canonique et suffisamment finale.
Il faut donc suivre trois temps : observation de l’émetteur, canonicalité de la chaîne, décision du service. Les confondre transforme une preuve d’intégrité en délégation silencieuse de politique.
Un registre de reçus plutôt qu’un feu vert
La discipline des couches de réalité de Lu Heng sépare représentation signée, observation, état canonique, état courant et résultat applicatif. Running-Code Primacy place la chaîne réellement observée et le résultat du service au-dessus du nom du mécanisme. Minimum Initial Specification conseille de garder le format commun petit et de rendre les décisions de finalité et d’autorisation explicites.
Le journal doit conserver l’émetteur, le kid, le schéma et le domaine, le hash des octets reconstruits, les verdicts primaire et compagnon, le résultat du hash de condition, la liaison au portefeuille, la référence de chaîne, le contrôle indépendant et la profondeur de finalité, la décision de fraîcheur, le contrôle de rejeu, la règle d’autorisation et l’issue de l’action.
Sources et limites
- https://datatracker.ietf.org/doc/draft-borthwick-wallet-state-attestation/
- https://datatracker.ietf.org/doc/draft-borthwick-wallet-state-attestation/history/
- https://www.ietf.org/archive/id/draft-borthwick-wallet-state-attestation-00.html
- https://www.ietf.org/archive/id/draft-borthwick-wallet-state-attestation-01.html
- https://www.rfc-editor.org/rfc/rfc4648.html
- https://www.rfc-editor.org/rfc/rfc7515.html
- https://www.rfc-editor.org/rfc/rfc7517.html
- https://www.rfc-editor.org/rfc/rfc7519.html
- https://www.rfc-editor.org/rfc/rfc8785.html
- https://www.rfc-editor.org/rfc/rfc9794.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Ces sources n’établissent ni consensus IETF, ni adoption, implémentation, déploiement, observation indépendante, finalité, contrôle du portefeuille, consentement, autorisation réussie, règlement ou livraison. Les affirmations d’adoption citées à titre informatif dans le projet restent celles de ses auteurs.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

