Attesto 2.0

Proofstream und Offline-Verifikation

Proofstream zeichnet KI-relevante Evidenz als append-only Stream History auf. Jedes akzeptierte Event erhält ein Receipt; geschlossene Windows werden zu Checkpoints; Witnesses signieren monotone Progression; Anchors binden Epochs extern; Bundles können ohne Zugriff auf die Attesto-Backend verifiziert werden.

Lifecycle

Stream Events und Receipts

Ein Proofstream Event wird genau einem Stream angehängt und erhält eine monotone Sequence Number. Das Receipt bindet Event Hash, Previous Event Hash, Sequence Number und den resultierenden Stream Head.

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

Ein Window schließt einen zusammenhängenden Eventbereich. Seine Merkle Root committed jedes Event im Bereich, und Inclusion Material erlaubt dem Verifier zu beweisen, dass ein bestimmtes Event zu diesem geschlossenen Bereich gehört.

• from_seq_no und to_seq_no definieren den geschlossenen Bereich.
• window_root committed die geordneten Leaves.
• leaf_hash und inclusion_path verifizieren individuelle Membership.

Checkpoints

Ein Checkpoint committed den Stream State nach einem oder mehreren Windows. Er verbindet den neuesten Event Head, Window Roots, Policy Digest, Witness Policy und Anchor Epoch Candidate.

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

Consistency

Consistency beweist, dass ein späterer Checkpoint frühere Historie erweitert. Ohne Consistency könnte ein System Inclusion für zwei verschiedene Histories zeigen und dennoch lokal gültig erscheinen. Proofstream behandelt Consistency als First-class Verifier Requirement.

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

Fork Defense

Inclusion Proofs allein reichen nicht. Proofstream prüft auch Consistency und Witness Monotonicity. Wenn zwei Checkpoint Heads inkompatible Histories für denselben Stream beanspruchen, wird Fork Evidence erzeugt und der Verifier lehnt die mehrdeutige History ab.

Fork Evidence ist keine Dashboard-Warnung. Es ist ein verifizierbares Objekt, das in ein Bundle aufgenommen und von einem externen Verifier geprüft werden kann.

Offline-Verifikation

Nutze den SDK Helper oder die Verifier CLI mit einem heruntergeladenen Bundle. Online Anchor Re-checks sind explizit; der Kernpfad der Bundle Verification hängt nicht von der Verfügbarkeit der Attesto-Backend ab.

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

Für Service-to-service Verification sendest du dieselbe Objektform an POST /v2/verify. API und CLI teilen Fail-closed Semantics.

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 ist eine asynchrone Lifecycle Lane über committed Checkpoint Metadata. Sie ist designed for lifecycle proofing; cryptographic construction is pending external review, und die Lane bleibt review-gated, bevor stärkere externe kryptografische Claims gemacht werden. Receipt Ingest und Offline Bundle Verification hängen nicht davon ab, dass Nova Proof Generation im Hot Path liegt.