Attesto 2.0

Proofstream e verifica offline

Proofstream registra evidenza rilevante per l'AI come stream history append-only. Ogni event accettato riceve un receipt; le windows chiuse diventano checkpoints; witnesses firmano progresso monotono; anchors vincolano epochs esternamente; bundles possono essere verificati senza accesso al backend Attesto.

Lifecycle

Stream events e receipts

Un Proofstream event viene aggiunto esattamente a uno stream e riceve un sequence number monotono. Il receipt vincola event hash, previous event hash, sequence number e lo stream head risultante.

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

Una window chiude un intervallo contiguo di events. La sua Merkle root fa commitment a ogni event nell'intervallo, e l'inclusion material permette al verifier di provare che uno specifico event appartiene a quell'intervallo chiuso.

• from_seq_no e to_seq_no definiscono l'intervallo chiuso.
• window_root fa commitment alle leaves ordinate.
• leaf_hash e inclusion_path verificano la membership individuale.

Checkpoints

Un checkpoint fa commitment allo stream state dopo una o più windows. Collega l'event head più recente, window roots, policy digest, witness policy e anchor epoch candidate.

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

Consistency

Consistency prova che un checkpoint successivo estende la history precedente. Senza consistency, un sistema potrebbe mostrare inclusion per due histories diverse e sembrare comunque valido localmente. Proofstream tratta consistency come first-class verifier requirement.

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

Fork defense

Gli inclusion proofs da soli non bastano. Proofstream controlla anche consistency e witness monotonicity. Se due checkpoint heads dichiarano histories incompatibili per lo stesso stream, viene creato fork evidence e il verifier rifiuta la history ambigua.

Fork evidence non è un avviso del dashboard. È un oggetto verificabile che può essere incluso in un bundle e ispezionato da un verifier esterno.

Verifica offline

Usa l'helper SDK o la verifier CLI su un bundle scaricato. Gli online anchor re-checks sono espliciti; il percorso core di bundle verification non dipende dalla disponibilità del backend Attesto.

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

Per verification service-to-service, invia la stessa forma oggetto a POST /v2/verify. API e CLI condividono semantica 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

Nova lifecycle proofing lane

Nova/IVC proofing è una lifecycle lane asincrona su committed checkpoint metadata. È designed for lifecycle proofing; cryptographic construction is pending external review, e la lane rimane review-gated prima di qualsiasi claim crittografico esterno più forte. Receipt ingest e offline bundle verification non dipendono dalla Nova proof generation nel hot path.