Proof Integration

Pluggable prover and verifier backends for ZK, TEE, and fraud proof systems

Status: Speculative outline. No implementation work has started. The interfaces described here are proposals subject to change based on the EIP-8141 spec and Beam Chain / Verge roadmap.

Proof Integration connects Erigon to external proof systems — ZK provers, TEE attesters, and fraud proof generators. The pattern is consistent across Ethereum's proof landscape: the node executes a block and produces a witness, an external prover consumes the witness and produces a proof, and a verifier checks the proof in the consensus layer (L1) or in a rollup settlement contract (L2).

Erigon already has the input side covered: debug_getWitness and debug_getTxWitness RPCs produce execution witnesses (rpc/jsonrpc/eth_call.go). Proof Integration adds the prover dispatch and verifier validation on top of this existing foundation.

---

Key Capabilities

Pluggable backends: ProverBackend and VerifierBackend are registered components. Supported backends include Zilkworm, SGX (Raiko-compatible), RISC0, SP1, and ZisK. Selecting a backend is a configuration change, not a code change.

Independent deployability: Prover Integration and Verifier Integration are separate components. An archive node runs only the prover; a consensus node runs only the verifier; a full rollup operator runs both.

Multi-proof diversity: For scenarios requiring strong security guarantees, the component can require N independent proofs from different backends per block before accepting a block as verified.

---

Ecosystem Reference

• Taiko — node + Raiko (SGX prover) as a separate service; proofs submitted on-chain via ProveBlock transactions

• zkCloud/Ethproofs — provers deliver to a coordinator; gossipped via ExecutionProofs subnet; Lighthouse validates with --execution-proofs flag

• Nethermind — execution witness capture → stateless replay → RISC-V compilation → zkVM integration pipeline

---

Two Separate Components

Prover Integration and Verifier Integration are independently pluggable — a node might run one, both, or neither depending on its role:

• Archive or sequencer node — runs Prover Integration only (produces proofs for settlement)

• Consensus node — runs Verifier Integration only (validates incoming proofs)

• Full rollup operator — runs both

Component 1: Prover Integration

Produces execution witnesses and dispatches them to external proof providers. The component does not generate proofs itself — it prepares inputs and manages the interface to external provers.

type ProverBackend interface {
    Type() string  // "sgx", "zk-risc0", "zk-sp1", "zk-zisk", "zilkworm"
    SubmitWitness(ctx context.Context, witness *ExecutionWitness) (*ProofRequest, error)
    GetProof(ctx context.Context, requestID string) (*Proof, error)
}

The simplest first implementation wraps debug_getWitness — capture the witness produced during normal block execution, then dispatch it to a configured ProverBackend. Backends are registered via init() and selected by configuration.

Supported backends (planned): Zilkworm, SGX (Raiko-compatible), RISC0, SP1, ZisK.

Component 2: Verifier Integration

Validates proofs as part of consensus or rollup settlement. Integrates with two contexts:

• L1 Beam Chain — validates proofs in the Consensus component (when Erigon's Caplin participates in a proof-requiring fork)

• L2 RollupDriver — validates proofs in the settlement stage (ZK rollups, consensus rollup finality)

type VerifierBackend interface {
    Type() string
    Verify(ctx context.Context, proof *Proof, blockHash common.Hash) error
}

Multi-Proof Diversity Policy

For scenarios requiring strong security guarantees, the component supports requiring N independent proofs per block from different backends before accepting a block as verified:

type DiversityPolicy struct {
    RequiredProofs int           // minimum number of proofs required
    Backends       []string      // which backends must contribute
    Timeout        time.Duration // how long to wait for all proofs
}

Dependencies

Dependency	Notes
L1/L2 Node — Consensus component	For L1 Beam Chain verifier integration
L1/L2 Node — RollupDriver	For L2 settlement verifier integration
Existing debug_getWitness RPC	Simplest first prover input source
Map-Reduce Framework	For batch witness generation across a block range

Relationship to QMTree

QMTree Commitment (see QMTree Commitment) is a complementary proof-of-execution scheme. While Proof Integration connects to external ZK/TEE provers, QMTree produces an internal append-only Merkle commitment that commits to the EVM execution trace. They address different parts of the proof landscape and can operate independently.