State proofs and trusted history

Joltzu authenticates canonical EVM and native records through a shared Merkle–Patricia state trie. Proofs can establish inclusion or absence against a trusted root.

Where trust starts

A server's returned root is a claim until the client authenticates it. Start from an independently trusted committee/checkpoint and verify certified history. Then verify a proof against that complete trusted context.

joltzu_getHead provides useful metadata but is not a commit certificate. eth_getBlockByNumber likewise does not, by itself, establish validator finality. Do not fetch a root and proof from one untrusted peer and call that independent verification.

What can be proved

State proofs cover canonical native/EVM records. Receipt chunks authenticate bounded pieces of receipt data; descriptor proofs authenticate metadata without demonstrating payload availability. Log record/page proofs support authenticated indexing. Historical-root witnesses bind older roots through retained authenticated history.

These are Joltzu encodings and state layout. eth_getProof is not supported, and Ethereum account-trie verifiers cannot be assumed to verify native Joltzu state.

Retention and availability

joltzu_getProofRetention publishes separate state and log floors. Old state below the retained floor cannot be read as an all-zero account. Local leases can preserve eligible ranges when explicitly enabled; remote agreements and funded challenges have their own authority and retention terms.

Proof validity is distinct from future availability. A valid answer does not promise that a server will answer tomorrow. Consult storage operations before pruning.