Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decode signed blinded beacon block with consensus version header #472

Open
jimmygchen opened this issue Mar 15, 2023 · 4 comments
Open

Decode signed blinded beacon block with consensus version header #472

jimmygchen opened this issue Mar 15, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@jimmygchen
Copy link

In the latest builder spec (0.3.0), the submitBlindedBlock endpoint adds an additional (optional) Eth-Consensus-Version request header, which has the fork name as value. This was added so that the receiver could use this information to deseralize the request body easily.

mev-boost currently tries to decode using Capella, and then falls back to Bellatrix if it fails. The newly added version header could be utilised here to avoid the decode attempts and potentially catch errors like invalid payload for the fork.

https://github.com/flashbots/mev-boost/blob/main/server/service.go#L697-L709

@ralexstokes
Copy link
Collaborator

this information is only good for the receiver of this API, aka the relay

so relays could detect if this header is available and accept the hint for decoding

but this doesn't really help mev-boost... if the caller of this endpoint wants more precision, they can read the JSON text to get the version and use that to dispatch which deserialization routine to call for the attached data

@metachris
Copy link
Collaborator

Thanks @jimmygchen for the heads-up! As of now, mev-boost wouldn't forward the header, it starts a new HTTP request from scratch without forwarding any headers. This would need to be implemented.

I don't expect a new mev-boost release before mainnet Capella fork though.

@metachris
Copy link
Collaborator

Do we know how many CL clients already support this header? Would be good to start with forwarding this header as a first step.

@jimmygchen
Copy link
Author

This header is not in Lighthouse yet, I've raised an issue here for tracking:
sigp/lighthouse#4284

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants