[Security] High (attackable): PREVRANDAO is unconstrained by Summit verification

[evonide]

Context

Summit proposers build execution payloads through the Engine API, then validators verify the Summit block before voting on it. The execution payload is committed into the Summit block digest, so all validators agree on the same payload bytes.

One of those payload fields is prev_randao, which is exposed to EVM contracts through the PREVRANDAO opcode. That value should come from a consensus-defined randomness source or another explicitly defined Summit policy, not arbitrary proposer choice.

Claim

A malicious scheduled proposer running modified Summit or EL-facing code can include an otherwise valid execution payload with a chosen prev_randao value. Summit verification accepts the payload bytes without comparing prev_randao to any consensus-derived expected value, so the attacker-controlled value can pass into the canonical payload.

Impact

Contracts that use PREVRANDAO for randomness can receive a proposer-chosen value instead of unbiased consensus randomness. This can make lotteries, mints, games, ordering decisions, or other entropy-sensitive EVM logic predictable or biasable.

The payload hash only proves validators agreed on the chosen bytes. It does not prove the embedded randomness value was valid under Summit’s consensus rules.

Root Cause

Summit sets prev_randao to zero during honest payload construction, but remote block verification does not enforce zero or any other expected consensus-derived value. The verifier checks other block/header/auxiliary fields, but never checks payload.prev_randao.

Code

• https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/engine_client.rs#L101 sets honest payload construction prev_randao to zero.
• https://github.com/SeismicSystems/summit/blob/ed2c5c8/application/src/actor.rs#L551 commits the execution payload returned by the proposer into the Summit block.
• https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/block.rs#L51 hashes the full execution payload bytes into payload_hash.
• https://github.com/SeismicSystems/summit/blob/ed2c5c8/application/src/actor.rs#L598 verifies parent, height, timestamp, state root, checkpoint, validator deltas, and withdrawals, but does not compare payload.prev_randao to an expected value.
• https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/engine_client.rs#L149 replays the payload through new_payload_v4, but does not pass any Summit-derived expected randomness value.

Related Issues/PRs

Several existing PRs fix adjacent EL payload-verification gaps, but none defines or enforces Summit’s expected prev_randao value. This issue is specifically about a payload field being committed by hash while still lacking a Summit-side validity rule.

• #167 moves EL payload validation before consensus certification, but Engine API validation does not define Summit’s expected prev_randao.
• #190 binds EL payload block number and timestamp to the Summit header, but does not check prev_randao.
• #206 addresses a similar Summit-policy gap for fee_recipient, but not the randomness field.
• #191 addresses blob versioned-hash validation data, not payload randomness.

Fix

Define Summit’s expected prev_randao policy and enforce it before voting. If the intended value is always zero, reject any payload whose prev_randao is nonzero. If Summit intends to provide real consensus randomness, derive the expected value from consensus state or auxiliary data and compare the execution payload field against it. Add regression coverage showing that honest payloads pass and proposer-supplied unexpected prev_randao values are rejected before certification.

[matthias-wright]

Proposed fix: #263