Witness Plane

Witnesses, quorum et visibilité des forks

La Witness Plane rend beaucoup plus difficile la réécriture silencieuse de l'historique d'un stream. Les witnesses signent la progression monotone des checkpoints et émettent une fork evidence lorsqu'ils observent des historiques conflictuels pour le même stream.

Witnesses

Un witness est un service indépendant avec sa propre identity key et sa propre key epoch. Il conserve le dernier checkpoint accepté par tenant stream et ne signe un nouveau checkpoint que lorsqu'il étend l'historique précédent.

Rôle	Objectif
Attesto-operated witness	Witness managé pour les premières policies de production et la disponibilité de base.
Customer-operated witness	Vue côté client de la progression des checkpoints, généralement via Local Vault.
Assurance witness	Witness indépendant opéré par assurance ou auditeur pour des policies à niveau de trust plus élevé.
Partner witness	Witness third-party de confiance utilisé dans des policy designs spécifiques au client.

Package privacy-preserving witness node

Le package witness standalone est défini comme observation node, pas comme consensus node ni blockchain validator. Il observe les checkpoint heads, anchor epochs, release manifests et truth-package hashes publics ou explicitement partagés. Il ne reçoit jamais customer payloads, envelopes, receipts, tenant metadata ou secrets sauf si un tenant partage explicitement un artifact précis.

Les noms de packages sont attesto-witness, @attesto/witness et go.attesto.eu/witness. Le package ne doit jamais être une dépendance transitive des core SDKs, ne doit jamais auto-enroll et ne doit jamais démarrer un background service sans action explicite de l’utilisateur. Jusqu’à ce que la release evidence marque le package standalone vert, le comportement customer-operated witness est fourni par Local Vault witness mode.

Quorum

Le quorum décrit combien de witnesses doivent signer pour qu'un checkpoint satisfasse la tenant policy. Une policy managed-only peut convenir à un stream simple. Une policy 2-of-3 est plus forte parce que le verifier peut exiger un agreement entre plusieurs vues indépendantes.

{
  "policy_id": "policy-2026-01",
  "required": 2,
  "witnesses": [
    "attesto-managed",
    "customer-local-vault",
    "assurance-witness"
  ]
}

Fork evidence et visibilité des forks

Un fork est un conflit où deux checkpoint heads revendiquent des historiques incompatibles pour le même stream. Le witness ne doit pas masquer cela en choisissant un côté. Il enregistre une fork evidence machine-readable afin que le verifier puisse rejeter l'historique ambigu.

{
  "kind": "fork_evidence",
  "stream_id": "str_...",
  "conflicting_checkpoints": [
    {"checkpoint_id": "chk_a", "checkpoint_head_hash": "hex-a"},
    {"checkpoint_id": "chk_b", "checkpoint_head_hash": "hex-b"}
  ],
  "detected_by": "customer-local-vault",
  "result": "verifier_rejects_ambiguous_history"
}

Forme de l'API witness publique

GET /witness/v1/identity: identité du witness, key epoch et algorithmes pris en charge.
POST /witness/v1/checkpoints: soumettre un checkpoint statement pour signature.
GET /witness/v1/checkpoints/{checkpoint_id}: récupérer le witness statement.
GET /witness/v1/forks: récupérer la fork evidence visible par l'appelant.