remove BlindedExecutionPayloadEnvelope by nflaig · Pull Request #624 · ethereum/beacon-APIs

nflaig · 2026-07-08T12:23:01Z

While looking at the implementation of #580 I realized using a BlindedExecutionPayloadEnvelope adds quite some complexity and I don't think it's warranted to add it to the spec

(1) requires a second signing route for the same signature, validator clients, remote signers and DVT
middleware would all have to support this
(2) might be implementation specifc but at least for us having a object without a slot adds some complexity, initially when we discussed adding BlindedExecutionPayloadEnvelope, the slot was still a top-level field but we moved it to payload.slot_number so it's not part of the blinded object anymore
(3) on top of that, it requires to maintain a new type and adds more complexity to caching and reconstruction on the beacon node side during publishing, which adds more failure modes to a hot path, not ideal

There is probably more, I stopped the implementation when I realized using a blinded object was a bad idea, as it also just optimizes not having to send transactions and block_access_list between VC<>BN, everything else in the envelope is a few hundred bytes. While in theory, this seems like the ideal way to do it from a performance perspective (you could even just send the root), I don't think it makes sense as it's rather a micro optimization compared to not sending around the blobs and proofs, which this PR still retains, and previous concerns from #519 are still being addressed in gloas.

Note: This PR includes several smaller follow-ups to #580 that are opinionated, please take a look at my comments below with further rationale, I also just polished a few descriptions here and there, shouldn't be too controversial

eserilev

Seems to be a nice simplification. Blobs were the real bottleneck here, blinding the payload was probably overkill

potuz

Haven't read anything but I do approve the notion of avoid sending the blob data but keeping the payload there to avoid the existence of a blinded object. Blob data is already logically separated in our code base and it makes sense to keep it so here. But blinding the payload is unnecessary extra complexity.

nflaig · 2026-07-14T11:59:15Z

      description: "The active consensus version to which the execution payload envelope being submitted belongs."
    - in: header
-      name: Eth-Execution-Payload-Blinded
+      name: Eth-Blob-Data-Included


we can nit pick the header name, that was the best name I could come up with

Eth-Contains-Blob-Data ? Eth-Includes-Blob-Data? Eth-With-Blob-Data?

we do have Eth-Execution-Payload-Included already, so I do prefer the -Included suffix to at least keep consistency between those two headers, but appreciate the suggestions

nflaig · 2026-07-14T12:03:34Z

      $ref: "../../../beacon-node-oapi.yaml#/components/responses/UnsupportedMediaType"
    "500":
      $ref: "../../../beacon-node-oapi.yaml#/components/responses/InternalError"
+    "503":


not really related, but this PR has some follow ups for #580, so might as well include that, at least in our implementation we return 503 if node is syncing, and I couldn't come up with a good reason not to do that, we do the same in publishBlockV2 which has the 503 documented on the spec side

beacon-APIs/apis/beacon/blocks/blocks.v2.yaml

Lines 82 to 83 in 4f6a0a7

"503":

$ref: '../../../beacon-node-oapi.yaml#/components/responses/CurrentlySyncing'

What if the beacon node mistakenly thinks it's syncing, like we saw happen during the Holesky incident non-finality when very few blocks were being produced? Should the BN refuse a perfectly valid request to publish a payload envelope?

this is a bit tricky, the problem is that while the node is syncing it might not be able to validate the payload envelope easily, or have a bad view of the network state since it's not subscribed to gossip usually, so equivocation checks may not be possible

but I see what you are saying, this has been mostly addressed on the beacon node side to be able to configure this, eg. there is a flag in lodestar with which I can force it to build on very old heads. there is a trade-off there, but those scenario are being considered as part of the hardening efforts already

curious about other implementations and whether or not they return 503 currently

nflaig · 2026-07-14T12:07:57Z

-      required: false
+      required: true
      description: |
        Controls whether the execution payload envelope and blobs are included in the response
        when self-building (using local execution payload).

-        When `true` (default), the response includes the full block contents: beacon block,
+        When `true`, the response includes the full block contents: beacon block,


two reasons for changing this

(1) I do not like optional parameters in general

(2) I want to de-opinionate the spec about what should be the default

eg. for (2), in lodestar we look at how many beacon node(s) are connected and if it's > 1, then we default to stateless, otherwise stateful, and allow to override via separate cli flag. All of this is configured on the vc side though, so making this parameter optional would mean the bn would have to decide if omitted, but that's not easily possible since the bn has no good view on whether or not other bns are connected to the vc that is requesting to prodcue a block

nflaig · 2026-07-14T12:08:53Z

-        responses so clients can deserialize returned JSON or SSZ data to the correct object,
-        and sent in requests on endpoints that accept either blinded or full forms so the
-        server can select the correct request schema.
+      description: Required in response so client can deserialize returned json or ssz data to the correct object.


this just reverts back to pre #580 description

james-prysm

added a small list of suggestions for renames mostly nits

eth2353

Simplifying this seems like a good idea to me too, the main worry was about passing around the much larger blob data which is still addressed 👍

eth2353 · 2026-07-14T22:42:21Z

      $ref: "../../../beacon-node-oapi.yaml#/components/responses/UnsupportedMediaType"
    "500":
      $ref: "../../../beacon-node-oapi.yaml#/components/responses/InternalError"
+    "503":


What if the beacon node mistakenly thinks it's syncing, like we saw happen during the Holesky incident non-finality when very few blocks were being produced? Should the BN refuse a perfectly valid request to publish a payload envelope?

**What type of PR is this?** Feature **What does this PR do? Why is it needed?** reverts the blinded envelop introduced in OffchainLabs#16943 based on discussion and spec change on beacon api specs. kurtosis test ``` participants: - el_type: ethrex el_image: ethpandaops/ethrex:glamsterdam-devnet-5 el_extra_params: - --http.api=eth,net,web3,admin cl_type: prysm cl_image: gcr.io/offchainlabs/prysm/beacon-chain:latest vc_image: gcr.io/offchainlabs/prysm/validator:latest supernode: true cl_extra_params: - --verbosity=debug vc_extra_params: - --verbosity=debug count: 4 network_params: fulu_fork_epoch: 0 gloas_fork_epoch: 1 seconds_per_slot: 6 genesis_delay: 30 additional_services: - dora - tx_fuzz global_log_level: debug ``` **Which issue(s) does this PR fix?** implements ethereum/beacon-APIs#624 **Other notes for review** **Acknowledgements** - [x] I have read [CONTRIBUTING.md](https://github.com/prysmaticlabs/prysm/blob/develop/CONTRIBUTING.md). - [x] I have included a uniquely named [changelog fragment file](https://github.com/prysmaticlabs/prysm/blob/develop/CONTRIBUTING.md#maintaining-changelogmd). - [x] I have added a description with sufficient context for reviewers to understand this PR. - [x] I have tested that my changes work as expected and I added a testing plan to the PR description (if applicable).

Part of #8828 for the stateful path. Aligns `produceBlockV4` and `POST /eth/v1/beacon/execution_payload_envelopes` with beacon-APIs [#580](ethereum/beacon-APIs#580) and [#624](ethereum/beacon-APIs#624). - Request stateful block production with required `include_payload=false` - Submit `SignedExecutionPayloadEnvelope` with required `Eth-Consensus-Version` and `Eth-Blob-Data-Included: false` headers - Support `broadcast_validation` (`gossip`, `consensus`, `consensus_and_equivocation`) - Return `202` when the envelope is broadcast but not fully imported Co-Authored-By: shane-moore <skm1790@gmail.com>

…as block production (#9595) - per ethereum/beacon-APIs#624 - validator client defaults to the stateless flow if multiple beacon nodes are configured - add `--payloadLocal` flag to configure behavior stateless vs. stateful - `produceBlockV4` now respects `builder_selection` and `builder_boost_factor` - post-gloas the validator client defaults to the `default` builder selection strategy (uses in-protocol p2p bids and local block, selecting by value), explicit `--builder.selection` config is still honored - implement `broadcast_validation` for publishing execution payload envelopes (except `equivocation` checks) - extend oapi spec test framework to support `{schema: type: boolean}` in query params and request headers - remove `builderonly` builder selection option, it's a safety concern and adds unnecessary complexity

remove BlindedExecutionPayloadEnvelope

1c9356b

eserilev approved these changes Jul 8, 2026

View reviewed changes

nflaig added the Gloas api's needed in Gloas fork. label Jul 8, 2026

tersec previously approved these changes Jul 9, 2026

View reviewed changes

potuz approved these changes Jul 9, 2026

View reviewed changes

nflaig mentioned this pull request Jul 9, 2026

All Core Devs - Consensus (ACDC) #182, July 9 2026 ethereum/pm#2152

Closed

4 tasks

This was referenced Jul 9, 2026

feat(ssv_types): add BlindedExecutionPayloadEnvelope and EnvelopeConsensusData with QbftData and value check sigp/anchor#1121

Closed

feat(validator_store): implement sign_execution_payload_envelope sigp/anchor#1126

Open

hangleang mentioned this pull request Jul 13, 2026

[Glamsterdam] Block production and execution payload envelope beacon API grandinetech/grandine#772

Closed

de-opinionate spec about include_payload default

f43e6c5

nflaig dismissed tersec’s stale review via f43e6c5 July 14, 2026 11:50

keep include_payload required

4f6a0a7

nflaig commented Jul 14, 2026

View reviewed changes

nflaig mentioned this pull request Jul 14, 2026

Produce block v4 with payload #580

Merged

nflaig added 2 commits July 14, 2026 13:17

ref both prs in changelog

3035475

Merge branch 'master' into remove-blinded

611fe82

nflaig marked this pull request as ready for review July 14, 2026 12:30

qu0b approved these changes Jul 14, 2026

View reviewed changes

nflaig added 3 commits July 14, 2026 15:09

use PAYLOAD_DUE_BPS for envelope submission deadline

93c1d9d

document both envelope submission options for builders

e645cea

ref alpha.12

0a6ebde

KaloyanTanev approved these changes Jul 14, 2026

View reviewed changes

eserilev approved these changes Jul 14, 2026

View reviewed changes

hangleang approved these changes Jul 14, 2026

View reviewed changes

nflaig mentioned this pull request Jul 14, 2026

feat: builder selection, broadcast validation, stateless flow for gloas block production ChainSafe/lodestar#9595

Merged

james-prysm approved these changes Jul 14, 2026

View reviewed changes

james-prysm mentioned this pull request Jul 14, 2026

reverting blinded envelope OffchainLabs/prysm#17181

Merged

4 tasks

eth2353 approved these changes Jul 14, 2026

View reviewed changes

shane-moore approved these changes Jul 15, 2026

View reviewed changes

nflaig merged commit 53ccf16 into master Jul 16, 2026
3 checks passed

nflaig deleted the remove-blinded branch July 16, 2026 10:50

This was referenced Jul 17, 2026

chore: make post envelope beacon api spec compliant sigp/lighthouse#9276

Merged

Implement gloas stateless block building api sigp/lighthouse#9568

Open

JasonVranek mentioned this pull request Jul 21, 2026

Update Beacon API for parity with Builder API and KeyManager API #630

Open

This was referenced Jul 31, 2026

send Eth-Blob-Data-Included on envelope submission ethpandaops/go-eth2-client#45

Open

send the Eth-Blob-Data-Included header on envelope submission ethpandaops/buildoor#150

Open

	"503":
	$ref: '../../../beacon-node-oapi.yaml#/components/responses/CurrentlySyncing'

Uh oh!

Conversation

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

Uh oh!

Uh oh!

eserilev left a comment

Choose a reason for hiding this comment

Uh oh!

potuz left a comment

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!

Choose a reason for hiding this comment

Uh oh!

nflaig Jul 14, 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!

james-prysm left a comment

Choose a reason for hiding this comment

Uh oh!

eth2353 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

11 participants

nflaig commented Jul 8, 2026 •

edited

Loading

nflaig Jul 14, 2026 •

edited

Loading