Produce block v4 with payload by shane-moore · Pull Request #580 · ethereum/beacon-APIs

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

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 and shane-moore/beacon-APIs#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_envelope/{slot} — Fetch the cached execution payload envelope for the current
proposer's self-built payload. 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_envelope — Publish a signed execution payload envelope to the network.

Open Questions

Whether a BlindedExecutionPayloadEnvelope (omitting transactions) should replace the full envelope in the stateful POST flow for both proposer self-building and builder envelope submission, since the beacon node already has the data cached (see discussion)
Builder-specific endpoints for constructing envelopes from custom block building (tracked in Builder api to construct envelope from their execution payload #575) and perhaps warrants a separate PR

nflaig · 2026-02-13T13:07:38Z

apis/validator/execution_payload_envelope.yaml

+    - Validator
+    - ValidatorRequiredApi
+  parameters:
+    - name: slot


while implementing this, I noticed the slot alone is not definitive enough (eg. in case of forks), we should consider also passing the beacon_block_root here

hm, what do you think about making it optional to pass beacon_block_root like in 0c45859? pretty sure the VC already computes the block's tree hash root during signing, so passing it here should be straightforward

Yes, we do already compute the block root on the vc side. I am not a big fan of optional parameters, so I'd rather have it as required or remove it if it's not needed, so far it makes our implementation simpler, maybe get more feedback from others who already implemented the apis

I feel you, perhaps @eserilev @tersec @StefanBratanov or others from your teams have some thoughts here

james-prysm · 2026-02-17T16:57:57Z

apis/validator/execution_payload_envelope.yaml

+      description: "Slot for which the execution payload envelope is requested."
+      schema:
+        $ref: "../../beacon-node-oapi.yaml#/components/schemas/Uint64"
+    - name: builder_index


Will this endpoint be used for all builders outside of self building? I think the pipeline might endup being very different which makes me question if we would ever be caching more than just the current slot's payload envelope. terence asked this internally and I didn't have a good answer.

this endpoint is only meant for self-building if you are the proposer or the "act as a builder" mode where you build the payload for another proposer

builders that produce payloads outside of the beacon node would get their own endpoint which would be under the /builder namespace (at least that's how I am thinking about it right now)

it should be sufficient to only cache the current slot as you consume the cache within the same slot, maybe if that's the case my comment here #580 (comment) is also not needed but I feel like the block root is useful to specify, not just the slot

After thinking about it more, maybe we keep the current apis under /validator to be only used by proposers, which means we can remove builder_index here as it's only used for self-building

makes sense, removed builder_index in 0c45859

so looks like we might wanna use this for builders too if the validator "acts as a builder"

~~worth revisiting if we wanna re-add the builder_index here~~

Edit:

we might be fine, I think it's worth to wait until someone actually implement the "act as a builder" flow e2e, I rather tend towards not mixing up apis required by validators and builders too much

see discord for conversation about this

james-prysm · 2026-02-19T19:49:33Z

apis/validator/execution_payload_envelope.yaml

+  operationId: getExecutionPayloadEnvelope
+  summary: Get execution payload envelope
+  description: |
+    Retrieves execution payload envelope for a given slot and builder, which can then be signed by a validator. The envelope contains the full


can we specify this is not used for general payload envelope returns and they should expect a 404 if it's not for the current proposer? i.e. we aren't going to go get from execution for older slots

agreed, 0c45859

@shane-moore coul you update the pr description too to reflect

good call, updated description!

Notable changes - implement epbs stateful block production (self-build only) - `GET /eth/v4/validator/blocks/{slot}` added - `GET /eth/v1/validator/execution_payload_envelope/{slot}/{beacon_block_root}` added - `POST /eth/v1/beacon/execution_payload_envelope` added - `POST /eth/v2/beacon/blocks` updated - implement envelope state root computation - update block production cache for gloas (includes state root) - add validator block production flow for gloas - add envelope signing to validator store / remote signer - data column sidecar changes required to wire up new gloas type - update beacon-api spec to `v5.0.0-alpha.0` see ethereum/beacon-APIs#580 for reference

bharath-123 · 2026-02-23T21:48:01Z

apis/validator/block.v4.yaml

+        * if `exec_node_payload_value >= builder_boost_factor * (builder_payload_value // 100)`,
+          then return a full (unblinded) block containing the execution node payload.
+        * otherwise, return a blinded block containing the builder payload header.


I don't think this applies with gloas anymore. Regardless of whether we self-build or fetch a bid from a builder. We will get back a SignedExecutionPayloadBid in the beacon block. In the case of the builder, the envelope won't be available with the validator.

this needs to be rephrased for gloas, I think I brought that up in the other PR as well

made minimal changes to the description to remove the blinded/unblinded references in 8bf9080

agreed builder_boost_factor needs to be rethought for gloas. we discussed briefly in the old PR here and briefly in the discord

I also found this builder-specs PR defining how BN can set preferences between external bids/p2p bis/VC bids

The question is whether we want to be able to override these BN preferences via the VC. I'm sure the answer is yes, and the question becomes "how"?

Would we want to modify the validator registrations endpoint to signal a VC's per builder bid boost preferences similar to as proposed in the builder spec PR? Pretty sure this POST fires every epoch or when one of the values change

This could replace builder_boost_factor for example

Open to other ideas as well

bharath-123 · 2026-02-23T21:49:48Z

apis/validator/block.v4.yaml

+
+        Servers should use saturating arithmetic or another technique to ensure that large values of
+        the `builder_boost_factor` do not trigger overflows or errors. If this parameter is
+        provided and the beacon node is not configured with a builder then the beacon node MUST


I guess with ePBS, the beacon node is always configured with a builder as it listens to the builder bids on the gossip topic anyways.

not necessarily, we currently have an option to only produce local blocks which I intend to keep, but the default behavior will likely change with gloas to either use bid from p2p or build local, there are still valid reasons to force the node to build a local block, eg. builders censoring, which especially until FOCIL is shipped requires local blocks or a really sophisticated logic in clients to filter out bids from censoring builders

ensi321 · 2026-02-27T05:34:42Z

apis/beacon/execution_payload/envelope_post.yaml

+  description: |
+    Instructs the beacon node to broadcast a signed execution payload envelope to the network,
+    to be gossiped for payload validation. A success response (20x) indicates
+    that the envelope passed gossip validation and was successfully broadcast onto the network.


In publishBlockV2 we return 202 if block passed gossip validation but failed integration.

Are we doing something similar for publishExecutionPayloadEnvelope?

I guess from another angle to think about this is we broadcast the payload regardless the result of the payload integration, or we integrate first, if it goes well, we then gossip?

We probably want to propagate the envelope as quickly as possible, so ideally:

Apply gossip validation

Broadcast

Run process_execution_payload and import to DB

If (1) fails, we 400. If (3) fails we should probably 202 just like for blocks.

I was hoping we could avoid the nastiness of broadcast_validation for envelopes, but I think there might actually be an unbundling attack (background) for envelopes now:

I think there is an unbundling attack something like:

Malicious proposer publishes block A at slot N committing to bidA and payloadA, where bidA comes from an external builder (could be P2P or otherwise).

Malicious proposer publishes block B (slashable) at slot N committing to bidB and payload payloadB. They will be slashed at the next slot.

Builder for bidA starts to publish payloadA. Even on beacon nodes that have seen the equivocating block, the payload will PASS gossip validation as long as block A was imported.

Proposer publishes payloadB for block B. Envelope gossip validation passes for payloadB because it is signed by a different builder from payloadA.

Result: either A or B could become head, depending on timing. If B wins, the builder of A has revealed potentially valuable information, which could be worth the proposer slashing themselves for (they could use it for a self-build in the next slot).

Proposed fixes:

We could put the burden on the builder to check for block equivocations prior to revealing their payload (no API/spec changes).

We could add a gossip condition to reject envelopes for slashable blocks.

We could add a broadcast_validation=equivocation flag (like we have for pre-Gloas blocks) to check that the envelope's block is not an equivocation. This flag would likely be used by all builders when interacting with their BNs.

We could make the block equivocation check a default part of the API (same as broadcast_validation=equivocation from fix 3, but no flag required and no ability to opt-out).

based off the discord convo, seems like a broadcast_validation flag is warranted. I built it out in b9b6fc6 to use same BroadcastValidation schema as produceBlocksV2 since all the possible values seem to make sense for envelopes as well, but lmk if have some other thoughts on it

Notable changes - implement epbs stateful block production (self-build only) - `GET /eth/v4/validator/blocks/{slot}` added - `GET /eth/v1/validator/execution_payload_envelope/{slot}/{beacon_block_root}` added - `POST /eth/v1/beacon/execution_payload_envelope` added - `POST /eth/v2/beacon/blocks` updated - implement envelope state root computation - update block production cache for gloas (includes state root) - add validator block production flow for gloas - add envelope signing to validator store / remote signer - data column sidecar changes required to wire up new gloas type - update beacon-api spec to `v5.0.0-alpha.0` see ethereum/beacon-APIs#580 for reference

shane-moore added 5 commits February 12, 2026 10:00

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

update validator flow

6ee20eb

shane-moore mentioned this pull request Feb 12, 2026

add produceBlockV4 shane-moore/beacon-APIs#2

Closed

chore: update changelog

25de51f

nflaig added the Gloas api's needed in Gloas fork. label Feb 12, 2026

nflaig reviewed Feb 13, 2026

View reviewed changes

nflaig mentioned this pull request Feb 14, 2026

feat: implement epbs block production ChainSafe/lodestar#8838

Merged

eserilev mentioned this pull request Feb 16, 2026

Gloas stateless/stateful block production endpoints sigp/lighthouse#8828

Open

james-prysm reviewed Feb 17, 2026

View reviewed changes

james-prysm reviewed Feb 19, 2026

View reviewed changes

chore: remove builder index from get execution payload envelope

0c45859

bharath-123 reviewed Feb 23, 2026

View reviewed changes

ensi321 reviewed Feb 27, 2026

View reviewed changes

shane-moore added 2 commits March 6, 2026 10:03

chore: update blockv4 builder_boost_factor description

8bf9080

chore: update post envelope with broadcast validation

b9b6fc6

nflaig mentioned this pull request Mar 10, 2026

feat: add gloas execution payload envelope import pipeline ChainSafe/lodestar#8962

Merged

james-prysm mentioned this pull request Mar 12, 2026

Get block v4 OffchainLabs/prysm#16488

Open

4 tasks

wheelercameron193-hub approved these changes Mar 20, 2026

View reviewed changes

Conversation

shane-moore commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

New endpoints:

Open Questions

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nflaig Feb 19, 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!

Choose a reason for hiding this comment

Uh oh!

nflaig Mar 31, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bharath-123 Feb 23, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nflaig Feb 24, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

shane-moore commented Feb 12, 2026 •

edited

Loading

nflaig Feb 19, 2026 •

edited

Loading

nflaig Mar 31, 2026 •

edited

Loading

bharath-123 Feb 23, 2026 •

edited

Loading

nflaig Feb 24, 2026 •

edited

Loading