Architecture / architecture · 04
Local Evidence Ledger & Commander
Chaque événement signé est ajouté à un ledger hash-linked qui vit sur l'appareil. Une falsification à n'importe quel maillon casse la chaîne visiblement. Le ledger ne quitte pas l'appareil — mais l'opérateur peut y accéder via un canal forensique souverain.
Le ledger
Le Local Evidence Ledger est l’enregistrement résident sur l’appareil de tout ce que le runtime a signé. Il est append-only. Chaque événement référence le hash de son prédécesseur, produisant une chaîne reconstructible depuis n’importe quel point de départ. Toute falsification d’un maillon rend la rupture visible au moment de la vérification.
Cela compte opérationnellement. La réconciliation n’est pas une question de “faire confiance au log backend contre la réclamation porteur” — c’est une vérification déterministe d’une séquence signée. Les litiges qui étaient autrefois un jugement de crédibilité deviennent un output de vérificateur.
outcomes
Ce que cela vous permet de faire aujourd'hui que vous ne pouviez pas avant
-
Reconstruire les transactions disputées déterministiquement
L'enregistrement complet d'exécution est sur l'appareil — séquence, ordre, état runtime, trust basis. Un investigateur de litiges interroge le ledger et obtient la réponse ; pas de narratif.
-
Opérer l'evidence sous partition
Un appareil sur un réseau 2G/3G, dans une zone cellulaire morte, ou offline by design produit toujours une evidence cohérente. Le ledger se règle à la reconnexion.
-
Faire tourner du forensique souverain
Aucun tiers — y compris nous — ne se trouve dans le chemin entre l'opérateur et l'enregistrement côté appareil. Les investigateurs accèdent au ledger directement via le canal Commander.
-
Sortir l'investigation du chemin d'auth
Les décisions à l'autorisation lisent le token inline ; les questions plus profondes reçoivent des réponses asynchrones contre le ledger. Vous ne payez pas la latence forensique dans la fenêtre d'auth.
-
Détecter le tampering spécifiquement, pas génériquement
Une hash chain cassée rapporte le maillon exact qui échoue — diagnosticable, pas anonyme.
Pourquoi il reste sur l’appareil
Streamer chaque événement signé hors de l’appareil vers un store central créerait trois problèmes : une nouvelle surface d’attaque (un canal de transit que des adversaires pourraient intercepter, rejouer, ou ré-ordonner), une nouvelle dépendance opérationnelle (un backend qui doit être disponible pour que le substrat fonctionne), et une nouvelle posture de privacy (l’opérateur ne possède plus le cycle de vie des données de bout en bout). Le substrat est conçu pour ne prendre aucun de ces coûts.
Le module Commander
Le Commander est le canal forensique contrôlé par l’opérateur dans le ledger. Il est PGP-analogue : la clé opérateur écrit des commandes signées et chiffrées ; la clé appareil les reçoit, déchiffre, exécute la requête de ledger demandée, et répond avec une réponse signée. Aucun tiers — y compris nous — n’est dans la boucle.
Le Commander est la façon dont un investigateur fraude récupère l’enregistrement complet d’evidence autour d’une transaction disputée. La façon dont un régulateur audite un workflow citoyen. La façon dont un émetteur reconstruit le chemin d’exécution côté appareil d’un événement aberrant. Tout cela se passe entre l’opérateur et l’appareil, sur un canal que l’opérateur possède.
properties
Ce que vous obtenez quand vous câblez le Commander
-
·01 Append-only
Des événements peuvent être ajoutés ; rien ne peut être modifié ou retiré sans casser la chaîne.
-
·02 Hash-linked
Chaque événement référence le hash de son prédécesseur. La cohérence est vérifiable sans scanner la chaîne entière.
-
·03 Résident sur l'appareil
Le ledger ne stream pas vers un store central. Pas de nouveau canal de transit, pas de nouvelle surface d'attaque, pas de nouvelle dépendance opérationnelle.
-
·04 Cycle de vie contrôlé par l'opérateur
Politique de rétention, politique de suppression, politique de query — tout possédé par l'opérateur, pas par nous.
-
·05 Canal Commander PGP-analogue
La clé opérateur écrit des commandes chiffrées et signées. La clé appareil reçoit, exécute, signe la réponse. Aucun tiers dans la boucle.
-
·06 Asynchrone by design
Cadence d'investigation (secondes à heures), pas cadence d'autorisation (sous-milliseconde). Le budget de latence est celui de l'opérateur, pas du runtime.
-
·07 Préservant la privacy
Pas de PII client dans le ledger. Les identifiants d'appareil sont pseudonymes. Le ledger ne quitte jamais l'appareil sans une demande explicite initiée par l'opérateur.
Où en lire plus
Le format complet du ledger et le protocole Commander vivent dans YEI-001 §6.6, partagés avec les régulateurs et partenaires qualifiés sous NDA.