Description
In the current ePBS (Gloas) design, a builder submits a SignedExecutionPayloadBid committing to a block_hash. When the builder reveals the payload via SignedExecutionPayloadEnvelope, the CL calls engine_newPayloadV4 on the EL to validate it. This optimistic execution path means the beacon node can't know whether a payload is valid until the EL finishes re-executing it — which is on the critical path for fork choice and block import.
One direction worth exploring: allowing builders to attach a ZK proof of execution correctness alongside their envelope via a separate gossip message. If the CL can verify the proof cheaply, it could skip optimistic execution for proved payloads entirely, or at minimum treat them as higher-confidence during fork choice.
This is compatible with the self-build flow already implemented — a proposer doing BUILDER_INDEX_SELF_BUILD could produce a proof locally alongside their payload. External builders have an even stronger incentive since their payment depends on payload acceptance.
Related:
Steps to resolve
What does the proof cover? The minimum viable proof covers the four fields that process_execution_payload_envelope already validates against the bid: block_hash, withdrawals_root, gas_limit, and prev_randao. A proof of those outputs from the execution trace is sufficient for the CL to skip the EL call entirely on the happy path.
Where does the proof live? A separate gossip topic (e.g. execution_payload_proof) carrying a SignedExecutionPayloadProof message — slot + builder_index + proof bytes. The builder broadcasts this alongside their envelope. The beacon node correlates by (slot, builder_index) and, if the proof arrives and verifies before the EL finishes newPayload, can fast-path fork choice without waiting for EL validation. This requires a new gossip topic but no change to the envelope or bid structures. Spec changes are isolated to the new message type and its gossip validation rules.
How does fork choice use it? A proved payload sets payload_revealed = true in fork choice without waiting for EL validation. An unproved payload continues through the existing optimistic path. This keeps the happy path fast and doesn't break anything for builders that don't produce proofs.
Proving system? Jolt is a strong candidate — it uses a sumcheck-based SNARK with a simple zkVM architecture that maps well to EVM execution traces. Worth evaluating against the proof generation time requirements for a single slot (~12s on mainnet, ~1s on minimal preset devnets).
A useful first milestone would be defining the ExecutionPayloadProof gossip message type and wiring Jolt proof verification into process_payload_envelope behind a feature flag, with a mock prover for testing. The gossip handler pattern already exists for execution_payload — this would follow the same structure.
Additional Info
The current process_payload_envelope implementation in envelope_processing.rs does full state transition validation (block hash, withdrawals root, gas limit, etc.) after the EL call. A ZK-proved payload could potentially skip the EL call and validate those fields directly from the proof output. That's a meaningful latency win on the critical path.
Description
In the current ePBS (Gloas) design, a builder submits a
SignedExecutionPayloadBidcommitting to ablock_hash. When the builder reveals the payload viaSignedExecutionPayloadEnvelope, the CL callsengine_newPayloadV4on the EL to validate it. This optimistic execution path means the beacon node can't know whether a payload is valid until the EL finishes re-executing it — which is on the critical path for fork choice and block import.One direction worth exploring: allowing builders to attach a ZK proof of execution correctness alongside their envelope via a separate gossip message. If the CL can verify the proof cheaply, it could skip optimistic execution for proved payloads entirely, or at minimum treat them as higher-confidence during fork choice.
This is compatible with the self-build flow already implemented — a proposer doing
BUILDER_INDEX_SELF_BUILDcould produce a proof locally alongside their payload. External builders have an even stronger incentive since their payment depends on payload acceptance.Related:
process_execution_payload_envelope— https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/beacon-chain.mdnewPayloadintegration: https://github.com/dapplion/vibehouse/blob/55c8282d95b18e9ef85ea39d30ccc7776f1ef892/beacon_node/beacon_chain/src/execution_payload.rsSteps to resolve
What does the proof cover? The minimum viable proof covers the four fields that
process_execution_payload_envelopealready validates against the bid:block_hash,withdrawals_root,gas_limit, andprev_randao. A proof of those outputs from the execution trace is sufficient for the CL to skip the EL call entirely on the happy path.Where does the proof live? A separate gossip topic (e.g.
execution_payload_proof) carrying aSignedExecutionPayloadProofmessage — slot + builder_index + proof bytes. The builder broadcasts this alongside their envelope. The beacon node correlates by(slot, builder_index)and, if the proof arrives and verifies before the EL finishesnewPayload, can fast-path fork choice without waiting for EL validation. This requires a new gossip topic but no change to the envelope or bid structures. Spec changes are isolated to the new message type and its gossip validation rules.How does fork choice use it? A proved payload sets
payload_revealed = truein fork choice without waiting for EL validation. An unproved payload continues through the existing optimistic path. This keeps the happy path fast and doesn't break anything for builders that don't produce proofs.Proving system? Jolt is a strong candidate — it uses a sumcheck-based SNARK with a simple zkVM architecture that maps well to EVM execution traces. Worth evaluating against the proof generation time requirements for a single slot (~12s on mainnet, ~1s on minimal preset devnets).
A useful first milestone would be defining the
ExecutionPayloadProofgossip message type and wiring Jolt proof verification intoprocess_payload_envelopebehind a feature flag, with a mock prover for testing. The gossip handler pattern already exists forexecution_payload— this would follow the same structure.Additional Info
The current
process_payload_envelopeimplementation inenvelope_processing.rsdoes full state transition validation (block hash, withdrawals root, gas limit, etc.) after the EL call. A ZK-proved payload could potentially skip the EL call and validate those fields directly from the proof output. That's a meaningful latency win on the critical path.