Witness Plane

Witnesses, quorum y visibilidad de forks

Witness Plane hace que sea mucho más difícil reescribir en silencio la stream history. Los witnesses firman la progresión monotónica de checkpoints y emiten fork evidence cuando observan histories en conflicto para el mismo stream.

Witnesses

Un witness es un servicio independiente con su propia identity key y key epoch. Almacena el último checkpoint aceptado por tenant stream y solo firma un nuevo checkpoint cuando extiende la history anterior.

Rol	Propósito
Attesto-operated witness	Witness gestionado para policies de producción tempranas y disponibilidad base.
Customer-operated witness	Vista del cliente sobre la progresión de checkpoints, normalmente mediante Local Vault.
Assurance witness	Witness independiente operado por assurance o auditoría para policies de mayor trust.
Partner witness	Witness third-party de confianza usado en policy designs específicos del cliente.

Package privacy-preserving witness node

El package witness standalone se define como observation node, no como consensus node ni blockchain validator. Observa checkpoint heads, anchor epochs, release manifests y truth-package hashes públicos o compartidos explícitamente. Nunca recibe customer payloads, envelopes, receipts, tenant metadata ni secrets salvo que un tenant comparta explícitamente un artifact específico.

Los nombres de package son attesto-witness, @attesto/witness y go.attesto.eu/witness. El package nunca debe ser una dependencia transitiva de los core SDKs, nunca debe auto-enroll y nunca debe iniciar un background service sin acción explícita del usuario. Hasta que release evidence marque el package standalone en verde, el comportamiento customer-operated witness se ofrece mediante Local Vault witness mode.

Quorum

Quorum describe cuántos witnesses deben firmar para que un checkpoint satisfaga la tenant policy. Una policy managed-only puede ser útil para un stream sencillo. Una policy 2-of-3 es más fuerte porque el verifier puede exigir agreement entre varias views independientes.

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

Fork evidence y visibilidad de forks

Un fork es un conflicto en el que dos checkpoint heads reclaman histories incompatibles para el mismo stream. El witness no debe ocultarlo eligiendo un lado. Registra fork evidence machine-readable para que el verifier pueda rechazar la history ambigua.

{
  "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"
}

Forma de la API pública de witness

GET /witness/v1/identity: identidad del witness, key epoch y algoritmos compatibles.
POST /witness/v1/checkpoints: enviar checkpoint statement para firma.
GET /witness/v1/checkpoints/{checkpoint_id}: recuperar witness statement.
GET /witness/v1/forks: recuperar fork evidence visible para el caller.