In Glamsterdam, the beacon block contains a signed execution payload bid but not the execution payload. The selected builder reveals the payload in a signed envelope after it learns the beacon block root.
Envelope object
SignedExecutionPayloadEnvelope contains a builder signature over:
payload: ExecutionPayload
execution_requests: ExecutionRequests
builder_index: BuilderIndex
beacon_block_root: Root
parent_beacon_block_root: Root
The payload contains the execution block hash, parent hash, state and receipt
roots, transactions, withdrawals, gas fields, timestamp, and fork fields. The
bid in the beacon block commits to the builder, block hash, gas limit,
prevRandao, blob commitments, and execution-requests root.
The signature uses DOMAIN_BEACON_BUILDER. An external builder signs with its
builder key; a self-built block (builder_index is BUILDER_INDEX_SELF_BUILD)
is signed with the proposer's validator key.
Gossip
The consensus p2p specification names the global topic execution_payload. It
carries SignedExecutionPayloadEnvelope.
A receiver ignores:
- an envelope whose beacon block is not yet known, which it may queue;
- another valid envelope for the same block root and builder; or
- an envelope before the latest finalized slot.
It rejects:
- an envelope for a beacon block that failed consensus validation;
- a payload slot that differs from the beacon block slot;
- a builder index that differs from the selected bid;
- a payload block hash that differs from the bid;
- execution requests whose hash-tree root differs from the bid;
- request-list counts above their fork limits;
- withdrawals above
MAX_WITHDRAWALS_PER_PAYLOAD; or - an invalid builder signature under
DOMAIN_BEACON_BUILDER.
The network check stores the payload by block hash only after these rules pass. Full payload processing has more checks.
Execution and data validation
on_execution_payload_envelope waits until the referenced beacon block state
is known and its blob data is available. It then verifies:
- the builder signature;
- the envelope's beacon block root and parent beacon block root;
- builder index,
prevRandao, gas limit, block hash, and execution-requests root against the bid; - payload slot, execution parent hash, and timestamp;
- the withdrawals root against consensus expected withdrawals; and
- the full payload through the execution client, including versioned hashes, parent beacon root, and execution requests.
Only after all checks pass does the node store the envelope for that beacon block. A timely network envelope can still be execution-invalid.
Req/Resp recovery
The range method requests:
start_slot: Slot
count: Uint64
It follows the block-range response rules and returns at most
MAX_REQUEST_PAYLOADS signed envelopes. The mainnet value is 128.
The root method accepts at most 128 beacon block roots. It can return fewer
envelopes when the peer lacks some data. Each successful response chunk
contains one Gloas SignedExecutionPayloadEnvelope.
Servers support the range:
max(GLOAS_FORK_EPOCH,
current_epoch - compute_min_epochs_for_block_requests())
through current_epoch
They may return 3: ResourceUnavailable or omit envelopes older than that
range. A payload attestation that names an unseen payload is a reason to start
a root request.
Payload timeliness committee
The global topic carries:
validator_index: ValidatorIndex
beacon_block_root: Root
slot: Slot
payload_present: Boolean
blob_data_available: Boolean
signature: BLSSignature
The mainnet payload timeliness committee has 512 positions. A member sets
payload_present when it saw the matching envelope before 50% of the slot. It
sets blob_data_available from the local data-availability check. It broadcasts
the signed message by 75% of the slot.
A receiver ignores a non-current slot, duplicate validator message, unknown
block, or block at another slot. It rejects a consensus-invalid block, an
out-of-range validator, a validator outside the committee, or a bad
DOMAIN_PTC_ATTESTER signature.
The next block can contain up to four aggregate payload attestations. Fork choice records committee votes. Mainnet timeliness thresholds use a strict majority of 512 positions (more than 256 votes).
These votes report timely receipt and blob availability. They do not prove
execution validity and cannot override an execution client's invalid result.
No committee message is a missing vote, not an automatic false or true.
Topic-name conflict
The pinned builder guide tells builders to publish on an
execution_payload_envelope gossip topic. The pinned consensus p2p table and
validation section define execution_payload.
This corpus uses execution_payload for the consensus wire marker because that
document owns the libp2p topic. The two pinned sources must align before a
builder can rely on the guide alone for the literal topic name.
Draft separation of the block access list from this envelope is a distinct future proposal. See block access list sidecars.