Attesto 2.0

Proofstream i weryfikacja offline

Proofstream zapisuje dowody istotne dla AI jako append-only stream history. Każdy zaakceptowany event otrzymuje receipt; zamknięte windows stają się checkpoints; witnesses podpisują monotoniczny postęp; anchors wiążą epochs zewnętrznie; bundles można weryfikować bez dostępu do backendu Attesto.

Lifecycle

Stream events i receipts

Proofstream event jest dodawany dokładnie do jednego streamu i otrzymuje monotoniczny sequence number. Receipt wiąże event hash, previous event hash, sequence number i wynikowy 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

Window zamyka ciągły zakres events. Jego Merkle root commit obejmuje każdy event w zakresie, a inclusion material pozwala verifierowi dowieść, że konkretny event należy do tego zamkniętego zakresu.

• from_seq_no i to_seq_no definiują zamknięty zakres.
• window_root commit obejmuje uporządkowane leaves.
• leaf_hash i inclusion_path weryfikują indywidualne membership.

Checkpoints

Checkpoint commit obejmuje stream state po jednej lub wielu windows. Łączy najnowszy event head, window roots, policy digest, witness policy i anchor epoch candidate.

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

Consistency

Consistency dowodzi, że późniejszy checkpoint rozszerza wcześniejszą historię. Bez consistency system mógłby pokazać inclusion dla dwóch różnych histories i nadal wyglądać lokalnie poprawnie. Proofstream traktuje consistency jako first-class verifier requirement.

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

Fork defense

Same inclusion proofs nie wystarczą. Proofstream sprawdza też consistency i witness monotonicity. Jeśli dwa checkpoint heads deklarują niekompatybilne histories dla tego samego streamu, powstaje fork evidence, a verifier odrzuca niejednoznaczną historię.

Fork evidence nie jest ostrzeżeniem dashboardu. To weryfikowalny obiekt, który może zostać dołączony do bundle i sprawdzony przez zewnętrznego verifiera.

Weryfikacja offline

Użyj helpera SDK albo verifier CLI na pobranym bundle. Online anchor re-checks są jawne; główna ścieżka bundle verification nie zależy od dostępności backendu Attesto.

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

Dla verification service-to-service prześlij ten sam kształt obiektu do POST /v2/verify. API i CLI współdzielą semantykę 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 to asynchroniczna lifecycle lane nad committed checkpoint metadata. Jest designed for lifecycle proofing; cryptographic construction is pending external review, a lane pozostaje review-gated przed jakimikolwiek silniejszymi zewnętrznymi claimami kryptograficznymi. Receipt ingest i offline bundle verification nie zależą od generowania Nova proof w hot path.