Proof of Evolution

Nova, IVC e lifecycle state

Proof of Evolution è il livello asincrono di Attesto 2.0 per provare transizioni di lifecycle state su metadati di checkpoint impegnati. Non è nel percorso di ingest e non blocca i receipts.

Panoramica

Proofstream crea prima la cronologia delle prove. Il livello Proof of Evolution prende typed checkpoint commitments, semantica di policy, stato incident/gap, witness quorum evidence e la precedente lifecycle state root, quindi produce una nuova committed state root per la epoch successiva.

Nova e IVC

Nova è usata per incrementally verifiable computation tramite folding schemes. In Attesto, l'obiettivo pratico è provare l'evoluzione del lifecycle state su evidence commitments, non inserire grandi workload AI direttamente nel percorso di ingest.

State roots e input pubblici

{
  "previous_state_root": "sha256-hex",
  "semantic_schema_root": "typed-commitment-hex",
  "checkpoint_root": "typed-commitment-hex",
  "policy_digest": "typed-commitment-hex",
  "incident_state_hash": "typed-commitment-hex",
  "witness_registry_root": "typed-commitment-hex",
  "required_threshold": 2,
  "required_witness_classes_root": "typed-commitment-hex",
  "next_state_root": "sha256-hex"
}

Evolution chain

Ogni IVC epoch fa riferimento alla state root precedente e al range di checkpoint che riassume. Un verifier può ispezionare l'evolution chain come una sequenza di state transitions su evidence commitments.

Limiti dei claim

La formulazione di produzione attuale è: “designed for lifecycle proofing; cryptographic construction pending external review.” Claims più forti sulla sicurezza crittografica revisionata esternamente restano non disponibili finché una revisione esterna di applied cryptography non è completata e collegata dal trust material pubblico.

Circuito e2e attuale

La relazione Nova release-blocking attesto.lifecycle.e2e.v1 prova Attesto-native Poseidon proof objects, policy-bound incident-gap semantics, schema-root binding, boundary-root binding e una configured 2-of-3 witness-quorum relation usando circuit-friendly Schnorr signatures.

Il quorum signature message lega domain separator, semantic schema root, boundary root, stream, checkpoint epoch e boundary, checkpoint root, policy id/version/digest, required threshold, witness classes root, incident state, witness registry root, revocation epoch e previous state root. Questo blocca cross-domain, cross-stream, cross-policy, cross-checkpoint, registry/revocation, boundary e schema replay dentro la relation.

La garanzia di release è un'unica relazione di binding end-to-end. Gli artefatti esterni JSON/SHA-256/Ed25519 vengono accettati solo dopo una verifica deterministica di confine e poi rappresentati come oggetti ExternalEvidenceBinding di prima classe. Nova vincola il commitment Poseidon full-width di ogni binding, quindi nessun artefatto esterno può influenzare il lifecycle state se il suo oggetto boundary verificato non è presente nella relazione e2e. Claims di sicurezza crittografica più forti restano non disponibili finché una revisione esterna di applied cryptography non copre la versione esatta del circuito, i vectors, la release evidence e il commit.