add produceBlockV4 by shane-moore · Pull Request #2 · shane-moore/beacon-APIs

shane-moore · 2025-12-23T22:09:54Z

Summary

Re-introduces the block production and execution payload envelope endpoints that were separated out from the epbs-standardized branch (Standardized Epbs Beacon Api ethereum/beacon-APIs#552) to be reviewed independently
GET /eth/v4/validator/blocks/{slot} — Post-Gloas block production endpoint (produceBlockV4).
Supports an include_payload query parameter that controls whether the execution payload
envelope and blobs are returned inline (stateless multi-BN operation) or cached by the
beacon node for separate retrieval (stateful single-BN operation).
GET /eth/v1/validator/execution_payload_envelope/{slot}/{builder_index} — Fetch a cached
execution payload envelope for signing and publishing (used in stateful mode or by builders).
POST /eth/v1/beacon/execution_payload_envelope — Publish a signed execution payload
envelope to the network.

Resolves comment in the epbs standardized PR

nflaig · 2026-01-26T12:41:58Z

    payload later. This endpoint is specific to the post-Gloas forks and is not backwards compatible
    with previous forks.
+
+    When self-building (local execution payload), the response will include the full block contents


in ethereum#519 the conclusion was to leave it up to clients to support blinding the response, eg. in Lodestar we have a flag --blindedLocal and corresponding query param to tell the bn to not return full block contents but rather cache them which makes the block production stateful but there is no drawback in a 1:1 setup

I think it would be good to standardize this kind of query parameter in produceBlockV4 and leave it up to clients whether the wanna implement it or not, ie. if a client doesn't wanna implement it they can always set the query param to false

nflaig

something to consider, if we return both the beacon block and execution payload here, do we also want an api to publish both, or are we fine with having 2 separate publish apis

Bez625 · 2026-01-26T14:52:03Z

Speaking on behalf of Vouch, we find this approach preferable to maintain the statelessness of the REST API and allowing us to leverage multiple clients in block production.

something to consider, if we return both the beacon block and execution payload here, do we also want an api to publish both, or are we fine with having 2 separate publish apis

This would be ideal for the stateless flow.

nflaig · 2026-01-26T14:59:01Z

This would be ideal for the stateless flow.

does it matter for that to have a single publish api call or 2 separate ones? but I can see that it's simpler for beacon node to process the data since you need to process the beacon block before you can process the execution payload to which the beacon block committed

Bez625 · 2026-01-28T10:51:11Z

does it matter for that to have a single publish api call or 2 separate ones? but I can see that it's simpler for beacon node to process the data since you need to process the beacon block before you can process the execution payload to which the beacon block committed

Is the submission process stateful, I.e. do you have to submit the payload to the same BN that you submit the beacon block to? If it's stateful then a single submission endpoint for both would make sense to keep the API stateless, but if it's not stateful it might be more consistent (for MEV and local production) to keep them separate.

For my benefit - is the worry that, if you submit the block to one BN and then the execution payload to a second BN, that the second client might not have seen the block yet?

nflaig · 2026-01-28T11:07:24Z

Is the submission process stateful, I.e. do you have to submit the payload to the same BN that you submit the beacon block to?

For my benefit - is the worry that, if you submit the block to one BN and then the execution payload to a second BN, that the second client might not have seen the block yet?

the BN needs the beacon block first to validate and process the execution payload however it's not required to submit both via the api

there will be a queue mechanism in clients for gossip as you can't be sure that you receive the beacon block before the execution payload there

so for api, it could be similar, BN shouldn't care if it receives the beacon block/payload via gossip or api

but if it's not stateful it might be more consistent (for MEV and local production) to keep them separate.

this is kinda what I wanna avoid, it's a implementation detail but I think we might be fine with keeping the 2 apis separate, and not have a specific publish api for local blocks

eth2353 · 2026-01-28T14:28:45Z

do we also want an api to publish both, or are we fine with having 2 separate publish apis

I'd just keep the 2 separate publish endpoints, that seems cleaner to me, they are two different objects being submitted.

That way we can also push out the BeaconBlock first, quickly, and follow it up with the ExecutionPayloadEnvelope right after (or even in parallel).

shane-moore · 2026-02-11T22:15:44Z

@nflaig, regarding your comment ethereum#552 (comment), I've added a commit to this pr. Is this what you were thinking regarding envelope being able to post with either stateful or stateless variant?

and your point about BlindedExecutionPayloadEnvelope probably needs more discussion here

@nflaig

* modified block production end points * epbs execution_payload_bid get and post * epbs execution_payload_envelope get and post * new epbs ptc assignment POST * new epbs payload_attestations get and post * small fixes * epbs documentation updates * updates per pr review * add produceBlockV4 endpoint * epbs related copy changes * add consensus version to bid and envelope post * gloas container links updated to use specific commit * add get bid error message for invalid builder index * add slot voting time parameters to validator-flow * add eth-consensus-version for payload attestations * update payload attestation get to have slot in path * payload attestation post should support an array in the request * updates per nico review * get execution payload envelope by block id * updates per nico review * add payload attestation and execution payload bid events * add execution_payment to execution_payload_bid * add payload attestation and bid fields for eventstream * Add prev_randao to execution payload bid * Make builders non-validating staked actors * Apply suggestion from @nflaig * Review PR * chore: remove produceBlockV4 * remove envelope endpoints * chore: updates per pr review * chore: revert attestation_data changes to reflect master * remove payload endpoints from changelog * Update apis/beacon/execution_payload/bid.yaml * Update apis/beacon/execution_payload/envelope_get.yaml * Update apis/validator/payload_attestation_data.yaml * Add ssz support to getPoolPayloadAttestations response * Update spec references to v1.7.0-alpha.2 * Add missing changelog entries * Keep phase0 spec references as before * Fix spellcheck * Final touch * Apply suggestion from hangleang --------- Co-authored-by: Bharath Vedartham <vedabharath12345@gmail.com> Co-authored-by: Nico Flaig <nflaig@protonmail.com>

shane-moore · 2026-02-12T18:42:42Z

discussion should move to ethereum#580

Introduces the block production and execution payload envelope endpoints for post-Gloas (ePBS) forks. These were separated out from #552 to be discussed and reviewed independently. Prior discussion in [PR 552 thread](#552 (comment)) and [shane-moore#2](shane-moore#2) as well. ## New endpoints: - **`GET /eth/v4/validator/blocks/{slot}`** — Post-Gloas block production endpoint (`produceBlockV4`). Supports an `include_payload` query parameter that controls whether the execution payload envelope and blobs are returned inline (stateless multi-BN operation) or cached by the beacon node for separate retrieval (stateful single-BN operation). - **`GET /eth/v1/validator/execution_payload_envelopes/{slot}/{beacon_block_root}`** — Fetch the cached execution payload envelope for the current proposer's self-built payload, returned as a `BlindedExecutionPayloadEnvelope` (the minimal object the validator client signs over). `beacon_block_root` is a required path param so the lookup is re-org resistant. Only available for the current slot; returns 404 for past slots or when no envelope has been cached. Used in stateful mode. - **`POST /eth/v1/beacon/execution_payload_envelopes`** — Publish a signed execution payload envelope. The request body is selected by the `Eth-Execution-Payload-Blinded` header: `false` carries `SignedExecutionPayloadEnvelopeContents` (envelope + blobs + KZG proofs, stateless flow); `true` carries a `SignedBlindedExecutionPayloadEnvelope` that the beacon node reconstructs from its cache before broadcasting (stateful flow). ## Blinded execution payload envelope Folds in shane-moore#10, resolving the earlier open question on whether a blinded envelope should be used in the stateful flow. `BlindedExecutionPayloadEnvelope` replaces the `payload` field with `payload_root` (the hash tree root of the full execution payload). Its hash tree root matches the full `ExecutionPayloadEnvelope`, so a validator signature over the blinded form is valid against the full envelope. This keeps the object the VC signs minimal in the stateful flow, where the beacon node already has the full payload and blobs cached from block production. Discussion: [r3310000141](#580 (comment)), [r3277279908](#580 (comment)). --------- Co-authored-by: Paul Harris <paul.harris@consensys.net> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

shane-moore mentioned this pull request Dec 23, 2025

Standardized Epbs Beacon Api ethereum/beacon-APIs#552

Merged

shane-moore force-pushed the produce-block-v4-with-payload branch from 52cf903 to 2013831 Compare December 30, 2025 04:32

nflaig mentioned this pull request Jan 26, 2026

All Core Devs - Testing (ACDT) #67, January 26, 2026 ethereum/pm#1882

Closed

3 tasks

nflaig reviewed Jan 26, 2026

View reviewed changes

shane-moore force-pushed the produce-block-v4-with-payload branch from adc9800 to 94662da Compare February 11, 2026 20:33

shane-moore changed the title ~~add flag to include payload in produceBlockV4~~ add produceBlockV4 Feb 11, 2026

shane-moore and others added 5 commits February 12, 2026 16:16

add flag to include payload in produceBlockV4

e902e3b

chore: add include_payload_flag

56be573

chore: add get payload envelope

e74fde6

stateful and stateless envelope post

5c28168

shane-moore force-pushed the produce-block-v4-with-payload branch from 6469abd to 5c28168 Compare February 12, 2026 18:02

update validator flow

6ee20eb

shane-moore closed this Feb 12, 2026

shane-moore mentioned this pull request Feb 12, 2026

Produce block v4 with payload ethereum/beacon-APIs#580

Merged

nflaig mentioned this pull request Feb 15, 2026

Queuing on api if execution payload envelope is received first ChainSafe/lodestar#8915

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add produceBlockV4 - #2

add produceBlockV4#2
shane-moore wants to merge 6 commits into
epbs-standardizedfrom
produce-block-v4-with-payload

shane-moore commented Dec 23, 2025 •

edited

Loading

Uh oh!

nflaig Jan 26, 2026 •

edited

Loading

Uh oh!

nflaig left a comment

Uh oh!

Bez625 commented Jan 26, 2026

Uh oh!

nflaig commented Jan 26, 2026

Uh oh!

Bez625 commented Jan 28, 2026

Uh oh!

nflaig commented Jan 28, 2026 •

edited

Loading

Uh oh!

eth2353 commented Jan 28, 2026

Uh oh!

shane-moore commented Feb 11, 2026

Uh oh!

shane-moore commented Feb 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

shane-moore commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

nflaig Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nflaig left a comment

Choose a reason for hiding this comment

Uh oh!

Bez625 commented Jan 26, 2026

Uh oh!

nflaig commented Jan 26, 2026

Uh oh!

Bez625 commented Jan 28, 2026

Uh oh!

nflaig commented Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eth2353 commented Jan 28, 2026

Uh oh!

shane-moore commented Feb 11, 2026

Uh oh!

shane-moore commented Feb 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

shane-moore commented Dec 23, 2025 •

edited

Loading

nflaig Jan 26, 2026 •

edited

Loading

nflaig commented Jan 28, 2026 •

edited

Loading