YinkoShield

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.

[ local evidence ledger · commander channel ] device · on-device storage ·01 sign hash: 0xa3… ·02 sign prev: 0xa3… ·03 … append-only commander module decrypts signed-and-encrypted commands replies with signed forensic responses no infrastructure in the loop · pgp-analogous device key · operator key · sovereign operator encrypted command signed response forensic, attributable device-resident, hash-linked, sovereign — no third-party in the forensic path
The ledger is on the device. The Commander gives operators a signed channel to it without putting any third party in the path.

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.

Demander la spécification YEI-001 →