Attesto 2.0

Proofstream y verificación offline

Proofstream registra evidencia relevante para IA como stream history append-only. Cada event aceptado recibe un receipt; las windows cerradas se convierten en checkpoints; witnesses firman progreso monotónico; anchors vinculan epochs externamente; bundles pueden verificarse sin acceso al backend de Attesto.

Lifecycle

Stream events y receipts

Un Proofstream event se añade exactamente a un stream y recibe un sequence number monotónico. El receipt vincula event hash, previous event hash, sequence number y el stream head resultante.

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 cierra un rango contiguo de events. Su Merkle root compromete cada event del rango, e inclusion material permite al verifier probar que un event específico pertenece a ese rango cerrado.

• from_seq_no y to_seq_no definen el rango cerrado.
• window_root compromete las leaves ordenadas.
• leaf_hash e inclusion_path verifican membership individual.

Checkpoints

Un checkpoint compromete el stream state después de una o más windows. Vincula el event head más reciente, window roots, policy digest, witness policy y anchor epoch candidate.

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

Consistency

Consistency prueba que un checkpoint posterior extiende la historia anterior. Sin consistency, un sistema podría mostrar inclusión para dos historias diferentes y seguir pareciendo válido localmente. Proofstream trata consistency como un requisito verifier de primer nivel.

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

Defensa contra forks

Inclusion proofs por sí solas no bastan. Proofstream también verifica consistency y witness monotonicity. Si dos checkpoint heads reclaman histories incompatibles para el mismo stream, se crea fork evidence y el verifier rechaza la historia ambigua.

Fork evidence no es una advertencia del dashboard. Es un objeto verificable que puede incluirse en un bundle e inspeccionarse por un verifier externo.

Verificación offline

Usa el helper del SDK o la verifier CLI sobre un bundle descargado. Los online anchor re-checks son explícitos; la ruta principal de bundle verification no depende de la disponibilidad del backend de Attesto.

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

Para verification service-to-service, envía la misma forma de objeto a POST /v2/verify. La API y CLI comparten semántica 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 es una lifecycle lane asíncrona sobre committed checkpoint metadata. Está designed for lifecycle proofing; cryptographic construction is pending external review, y la lane sigue review-gated antes de hacer claims criptográficos externos más fuertes. Receipt ingest y offline bundle verification no dependen de que la Nova proof generation esté en el hot path.