feat(server): in-process verifier-only zkVM backend (kind: verifier)

[qu0b]

Summary

Adds a new kind: verifier to zkVMConfig: zkboost links the lightweight ere-verifier-* crate in-process and verifies proofs without spinning up an ere-server. The verifying key (.vk) is downloaded at startup from program_vk_url (HTTP or file://); pre-computed .vk files are shipped alongside .elf files in eth-act/ere-guests releases since v0.9.0.

This separates the prove and verify code paths in zkboost. A node that only needs to verify proofs (e.g. a beacon node receiving execution_proof gossip but not generating proofs locally) no longer needs to spin up a per-proof-type ere-server — eliminating the GB-scale prover circuit allocation, GPU pinning, and 24+ GB Docker image footprint.

Motivation

ere-server is monolithic and prover-first (ere/crates/server/cli/src/main.rs:142-159): its only entry point is construct_zkvm(elf, resource) which always builds a zkVMProver, regardless of ProverResource::{Cpu, Gpu, Cluster}. zkboost forwards both prove and verify HTTP calls to ere-server (crates/server/src/proof/zkvm.rs:135-149), so even a node that only needs to verify gossiped proofs ends up running the full prover stack.

In a kurtosis devnet measured on an RTX PRO 6000 Blackwell rig (1626 blocks proven, 3252 proofs verified):

Resource	ere-server (prove + verify)	in-process verifier
Per-op time	6.37 s/proof	5.6 ms/verify
Container RAM	54 GiB	11 MiB
GPU VRAM	96 GiB	0
Image size	24.4 GB	180 MB (zkboost only)

The EIP-8025 spec (consensus-specs/specs/_features/eip8025/p2p-interface.md) treats proof_types as a per-node dynamic capability advertisement — every aware node receives every type via gossip and verifies whatever its verifier code can handle. Verification is intended to be light. Today's monolithic ere-server forces the heavy prover footprint onto every node that wants to verify, which is the gap this PR closes.

Changes

• Cargo.toml: add ere-verifier-core, ere-verifier-zisk workspace deps pinned to ere v0.8.1 (matching the existing ere-server-client pin).
• crates/server/Cargo.toml: optional deps + verifier-zisk feature, included in default. Adding more zkVMs is a feature-flag addition.
• crates/server/src/config.rs: new zkVMConfig::Verifier { proof_type, program_vk_url } variant.
• crates/server/src/proof/verifier.rs (new): DynVerifier enum, feature-gated per zkVM. Constructed from program_vk_url, dispatches verify to ere-verifier-{kind}::Verifier.
• crates/server/src/proof/zkvm.rs: new zkVMInstance::Verifier variant; prove returns prove not supported for verifier-only zkvm; verify dispatches in-process via DynVerifier.
• crates/server/src/server.rs: skip per-zkVM prover worker for Verifier variants (no proving, no worker).

Configuration

[[zkvm]]
kind = "verifier"
proof_type = "reth-zisk"
program_vk_url = "https://github.com/eth-act/ere-guests/releases/download/v0.9.0/stateless-validator-reth-zisk.vk"

program_vk_url accepts https://, http://, or file://. The bytes are decoded via ere_verifier_*::ProgramVk::decode_from_slice — a 32-byte ZiskProgramVk for ZisK.

Test plan

E2E demo on a kurtosis enclave with two zkboost instances:

• zkboost-prover: kind: ere → ere-server-reth-zisk on GPU 0
• zkboost-verifier: kind: verifier for reth-zisk, no ere-server

Same proof type both sides. CL-1 generates and gossips signed proofs; CL-2 receives via gossip, calls zkboost-verifier's POST /v1/execution_proof_verifications. Confirmed by zkboost_verify_total{proof_type="reth-zisk",verified="true"} 3252 on the verifier and zero ere-server containers on the verifier side.

Launcher and test config: ethpandaops/ethereum-package companion PR: ethpandaops/ethereum-package#1385

Follow-ups (not in this PR)

• Add other zkVM verifier features: verifier-sp1, verifier-risc0, verifier-openvm, verifier-airbender. Each is a small feature-flag + match-arm change once ere-verifier-{kind} is plumbed.
• Lighthouse-side: today's --proof-types flag forces both BN gossip subscription AND VC prove-attempt. The VC will hit zkboost's prove path even for a verifier-only deployment. zkboost correctly returns prove not supported for verifier-only zkvm, so this is a Lighthouse-side flag separation, not a zkboost issue, but worth flagging.