Attesto 2.0

Proofstream et vérification offline

Proofstream enregistre les preuves pertinentes pour l'IA comme une stream history append-only. Chaque event accepté reçoit un receipt; les windows fermées deviennent des checkpoints; les witnesses signent une progression monotone; les anchors lient les epochs à l'extérieur; les bundles peuvent être vérifiés sans accès au backend Attesto.

Lifecycle

Stream events et receipts

Un Proofstream event est ajouté à exactement un stream et reçoit un sequence number monotone. Le receipt lie l'event hash, le previous event hash, le sequence number et le stream head résultant.

curl -X POST https://verify.attesto.eu/v2/streams/$STREAM_ID/events \
  -H "Authorization: Bearer $ATTESTO_API_KEY" \
  -H "Idempotency-Key: $ATTESTO_IDEMPOTENCY_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @proofstream-event.json

{
  "stream_event_id": "sev_...",
  "seq_no": 42,
  "event_hash": "sha256-hex",
  "previous_event_hash": "sha256-hex",
  "stream_head_hash": "sha256-hex",
  "receipt": {
    "alg": "Ed25519",
    "kid": "proofstream-receipt-key",
    "signature": "hex-encoded-signature"
  }
}

Windows

Une window ferme une plage contiguë d'events. Sa Merkle root engage chaque event de la plage, et l'inclusion material permet au verifier de prouver qu'un event précis appartient à cette plage fermée.

• from_seq_no et to_seq_no définissent la plage fermée.
• window_root engage les leaves ordonnées.
• leaf_hash et inclusion_path vérifient l'appartenance individuelle.

Checkpoints

Un checkpoint engage le stream state après une ou plusieurs windows. Il relie le dernier event head, les window roots, le policy digest, la witness policy et l'anchor epoch candidate.

curl https://verify.attesto.eu/v2/checkpoints/$CHECKPOINT_ID

Consistency

La consistency prouve qu'un checkpoint ultérieur étend l'historique précédent. Sans consistency, un système pourrait montrer une inclusion pour deux historiques différents tout en semblant localement valide. Proofstream traite la consistency comme une exigence verifier de premier rang.

curl "https://verify.attesto.eu/v2/checkpoints/$CHECKPOINT_ID/consistency?from=$PREVIOUS_CHECKPOINT_ID"

Défense contre les forks

Les inclusion proofs seules ne suffisent pas. Proofstream vérifie aussi la consistency et la witness monotonicity. Si deux checkpoint heads revendiquent des historiques incompatibles pour le même stream, du fork evidence est créé et le verifier rejette l'historique ambigu.

Le fork evidence n'est pas une alerte de dashboard. C'est un objet vérifiable qui peut être inclus dans un bundle et inspecté par un verifier externe.

Vérification offline

Utilisez le helper SDK ou la verifier CLI sur un bundle téléchargé. Les online anchor re-checks sont explicites; le chemin principal de bundle verification ne dépend pas de la disponibilité du backend Attesto.

attesto bundles offline-verify --file ./attesto-bundle.json

Pour la verification service-to-service, soumettez la même forme d'objet à POST /v2/verify. L'API et la CLI partagent une sémantique fail-closed.

attesto bundles verify --file ./attesto-bundle.json

curl -X POST https://verify.attesto.eu/v2/verify \
  -H "Content-Type: application/json" \
  --data-binary @attesto-bundle.json

Lane Nova lifecycle proofing

Nova/IVC proofing est une lane lifecycle asynchrone sur des committed checkpoint metadata. Elle est designed for lifecycle proofing; cryptographic construction is pending external review, et la lane reste review-gated avant toute revendication cryptographique externe plus forte. Receipt ingest et offline bundle verification ne dépendent pas de la génération de preuve Nova dans le hot path.