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

Add consensus version to submitBlindedBlock request header #4284

Closed
jimmygchen opened this issue May 13, 2023 · 8 comments
Closed

Add consensus version to submitBlindedBlock request header #4284

jimmygchen opened this issue May 13, 2023 · 8 comments

Comments

@jimmygchen
Copy link
Member

Description

Consider providing fork name via a Eth-Consensus-Version HTTP header when sending submitBlindedBlock request to remote builder. (or potentially all remote builder requests?)

This change has been included in builder-specs v0.3.0, although it's an optional tag:

https://github.com/ethereum/builder-specs/blob/7b269305e1e54f22ddb84b3da2f222e20adf6e4f/apis/builder/blinded_blocks.yaml#L15

This header would help the endpoint provider (relays) discriminate the type the request payload when decoding.

@Gua00va
Copy link
Contributor

Gua00va commented Jul 26, 2023

hey @jimmygchen , is this related to #4525 ?

@jimmygchen
Copy link
Member Author

jimmygchen commented Jul 26, 2023

This is a different one, this is for the submitBlindedBlock request from the Beacon Node to the Builder in the builder block proposal flow, i.e. POST /eth/v2/builder/blinded_blocks in the below diagram.

We currently don't send this HTTP header in the request, and is an optional header in the spec that would make it easier for the builder to deserialize the request body.

sequenceDiagram
    participant validator
    participant beacon_node
    participant mev_boost
    Title: Block Proposal with Builder API
    validator->>beacon_node: GET v2/validator/blinded_blocks/{slot}
    beacon_node->>mev_boost: GET v1/builder/header/{slot}/{parent_hash}/{pubkey}
    mev_boost-->>beacon_node: returns bid & blinded payload
    beacon_node-->>validator: returns blinded block
    Note over validator: signs the blinded block
    validator->>beacon_node: POST beacon/blinded_blocks
    beacon_node->>mev_boost: POST /eth/v2/builder/blinded_blocks
    Note right of beacon_node: sends signed blinded beacon block
    mev_boost-->>beacon_node: returns revealed payload
    Note over beacon_node: construct block and broadcast block
Loading

@Gua00va
Copy link
Contributor

Gua00va commented Jul 29, 2023

hey @jimmygchen, how do I get access to some object of ChainSpec type here:

pub async fn post_builder_blinded_blocks<E: EthSpec>(

It is required to get fork version here:

pub fn fork_name(&self, spec: &ChainSpec) -> Result<ForkName, InconsistentFork> {

@jimmygchen
Copy link
Member Author

Hi @Gua00va

ChainSpec is available on the BeaconChain object, you should be able to obtain the fork_name when constructing the block, perhaps here:

late_block_logging(
&chain,
timestamp_now(),
block.message(),
block_root,
"builder",
&log,
);
let full_payload = el
.propose_blinded_beacon_block(block_root, &block)

and then pass it to the post_builder_blinded_blocks function.

@jimmygchen
Copy link
Member Author

I think this is probably not super useful unless the header is mandatory, perhaps revisit this if a new v2 version of the endpoint is added with SSZ support.

@jimmygchen
Copy link
Member Author

Closing this. See comment above.

@michaelsproul
Copy link
Member

I think we actually implemented this header recently off the back of a bug report by JGM:

Impl in:

@jimmygchen
Copy link
Member Author

Nice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants