-
Notifications
You must be signed in to change notification settings - Fork 215
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
Comments
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 |
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. |
Do we know how many CL clients already support this header? Would be good to start with forwarding this header as a first step. |
This header is not in Lighthouse yet, I've raised an issue here for tracking: |
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
The text was updated successfully, but these errors were encountered: