Skip to content

remove submitBeaconBlock API - #162

Open
bharath-123 wants to merge 54 commits into
mainfrom
remove-send-beacon-block-api
Open

remove submitBeaconBlock API#162
bharath-123 wants to merge 54 commits into
mainfrom
remove-send-beacon-block-api

Conversation

@bharath-123

@bharath-123 bharath-123 commented Jun 2, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

When a proposer selects a bid from a builder via the builder-api, only the builder whose bid has been selected can reveal the payload. So the beacon block should be returned to the builder whose bid has been selected.

This becomes a problem for stateless validator clients as when the validator client sends the beacon node the signed block, just based on the block you cannot tell if the bid is from the builder-api or from the p2p . You need to maintain some state in the beacon node which tells where the bid in the block has come from which makes it trickier for validator clients which want to talk to multiple beacon nodes. This makes the block proposal flow more stateful.

We could also argue that builders could help in improving block dissemnation.

I am on the fence on this and I am waiting for client devs to implement it and get more info on this.

@bharath-123
initial builder-api for gloas
74b53c1
@bharath-123
updates
0c55646
@bharath-123
pass in params while querying execution payload bid
278df30
@bharath-123
introduce validator registrations v2
1577ba9
@bharath-123
run doctoc
a3db7f7
@bharath-123
update validator registration v2
df52176
@bharath-123
add more specs
6e1a777
@bharath-123
run lint
80974bc
@bharath-123
updates
a242d3b
@bharath-123
abstract execution_payment_accepted to a BuilderPreferences struct
4ab5a0f
@bharath-123
minor fixes
9901fdc
@bharath-123
run doctoc
6959fda
@bharath-123
use correct method to check if builder is active
e752694
@bharath-123
save
d5773ac
@bharath-123
updates
68c1f21
@bharath-123
add information for bidding
373493a
@bharath-123
update
b0d9542
@bharath-123
add bid request auth
77be521
@bharath-123
remove builder index from validator registration
56a5ec9
@bharath-123
add validator registration type
dd644e5
@bharath-123
link to api calls
80dbeb0
@bharath-123
add some notes
3a9640a
@bharath-123
fix return type of execution_payload_bid.yaml
8962cc3
@bharath-123
use max_trusted_bid in builder preferences
2cdc29c
@bharath-123
run linter
5ab4d6d
@bharath-123
fix spellchecker
f4a9e04
@bharath-123
update bid request auth according to feedback
35fb5a7
@bharath-123
minor updates
e33dfed
@bharath-123
use a salt in the bid request auth
8aaa3b5
@bharath-123
correctly render constants table
3625f54
@bharath-123
address feedback
66c15dc
@bharath-123
update bid request auth to request auth
31dc1d4
@bharath-123
fix typo
0644e07
@bharath-123
use salt instead of url
b02106f
@bharath-123
use get-upcoming-proposal-slots
dbce4d6
@bharath-123
Update liveness failsafe section
b0e3d0c
@bharath-123
update RequestAuth types
e7d4321
@bharath-123
deprecate validator registrations in favour of proposer preferences
37c8e87
@bharath-123
updates to api
3b5735b
@bharath-123
run lint
19c272f
@bharath-123
remove description of proposer preferences
18ca2ed
@bharath-123
add validator pubkey in builder preferences and request auth
c1f2af3
@bharath-123
specify setting fee reicpient in execution payload bid
48c6ad8
@bharath-123
updates to epbs
3d53d8d
@bharath-123
updates
d125dea
@bharath-123
minor updates
5a618ae
@bharath-123
address feedback
6429ef9
@bharath-123
minor updates
9d4a18d
@bharath-123
add an error type for missing auth request
fbc4747
@bharath-123
Endpoint to submit builder preferences (#160)
7bd4ea1 
* add api to submit builder preferences

* add builder preferences type

* add signed builder preference

* updates

* specify precedence and when to submit the preference

* send preference based on epoch lookahead

* send request auth with builder preferences

* use builder pubkey in request auth

* add validator pubkey to the query param

* some updates
@bharath-123
Gloas Builder-API spec updates (#161)
75ea726 
* updates

* remove header to communicate max_execution_payment

* use proposer_pubkey instead of index

* some spec updates

* update is_eligible_for_bid

* update error code

* don't encapsulate the beacon block under a "data" field

* add an identity api

* reword sentence on block and payload decoupling

* update request auth to use builder url

* update error codes

* add eth consensus version header

* suffix containers with v1

* run make lint

* fix spellcheck

* minor spec updates

* builder can choose to not serve bid if preferences not seen
@bharath-123
address justins + AntiD2ta feedback
8a51c81
@bharath-123
remove submitBeaconBlock API
9b6dea2
@bharath-123
mention that the block has to be broadcasted
77d15bd
@JasonVranek

JasonVranek commented Jun 9, 2026

Copy link
Copy Markdown

I think there's a lot of value in keeping submitBeaconBlock. Today highly connected relays assist in broadcasting signed blocks before the attestation deadline which increases the viability/robustness of more geographically isolated proposers. In ePBS, the auction's winning builder would equally be incentivized to help with the propagation. If we remove this endpoint arguably the same geographically isolated proposers would be disadvantaged.

@vladimir-ea

vladimir-ea commented Jun 10, 2026

Copy link
Copy Markdown

I am sure there is a discussion somewhere which sets out the rationale for this change - could it be referenced here please?

@bharath-123

bharath-123 commented Jun 10, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Apologies, i should have updated the description. The rationale is as follows:
When a proposer selects a bid from a builder via the builder-api, only the builder whose bid has been selected can reveal the payload. So the beacon block should be returned to the builder whose bid has been selected.

This becomes a problem for stateless validator clients as when the validator client sends the beacon node the signed block, just based on the block you cannot tell if the bid is from the builder-api or from the p2p . You need to maintain some state in the beacon node which tells where the bid in the block has come from which makes it trickier for validator clients which want to talk to multiple beacon nodes. This makes the block proposal flow more stateful

I am on the fence on this and I am waiting for client devs to implement it and get more info on this.

@bharath-123

bharath-123 commented Jun 10, 2026

Copy link
Copy Markdown
Contributor Author

I think there's a lot of value in keeping submitBeaconBlock. Today highly connected relays assist in broadcasting signed blocks before the attestation deadline which increases the viability/robustness of more geographically isolated proposers. In ePBS, the auction's winning builder would equally be incentivized to help with the propagation. If we remove this endpoint arguably the same geographically isolated proposers would be disadvantaged.

We can also make the argument that the beacon block's size goes down significantly with ePBS and that block broadcast can be done with a much lower bandwidth compared to today. The block could disseminate much faster in the network.

@bharath-123 bharath-123 mentioned this pull request Jun 11, 2026
Closed
4 tasks
Base automatically changed from epbs-updates to main June 11, 2026 12:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@bharath-123 @JasonVranek @vladimir-ea