Nhảy tới nội dung

Inclusion vs execution proofs

Normative spec

The four ordered integrity gates, the anchored-root pinning contract, and the MOCK-by-default execution-proof caveat are in Protocol · Verification, provenance & anchoring.

DIG uses two distinct kinds of proof. They answer different questions, run on different timescales, and you'll meet them in different places.

Inclusion proofs — synchronous, per read​

An inclusion proof is a Merkle proof that accompanies every served resource. It proves the exact ciphertext bytes you received belong to a specific generation's root — the root that is anchored on-chain. The client checks it synchronously, on every read, before decrypting — so a host can never substitute or tamper with content without detection.

  • Question answered: "are these the genuine bytes for this root?"
  • Where: every dig RPC content read carries one. → Proofs & security · Streaming
  • Cost: free, instant, client-side.

Execution proofs — asynchronous, attesting faithful serving​

An execution proof is a ZK / risc0 execution receipt that attests a node faithfully ran the serving logic over a period — a stronger, aggregate guarantee about a node's behaviour than any single read can give. These are expensive to produce, so they are asynchronous and gated on the hub control plane, which budgets the prover jobs.

  • Question answered: "did this node serve honestly over time?"
  • Where: requested/budgeted via the hub /v1 control plane; produced by the risc0 prover backend.
  • Cost: expensive; rate-limited and gated.

Why both​

Inclusion proofs make each read trustless without trusting the host. Execution proofs let the network audit a node's overall conduct — the basis for node attestation and the network's availability guarantees — without making every read pay that cost.