Specify Builder Configurations and Bid selection strategies - #144
Specify Builder Configurations and Bid selection strategies#144bharath-123 wants to merge 60 commits into
Conversation
| # Builders must respond by 2 seconds into the slot | ||
| # This leaves 2 seconds for local building fallback | ||
| return slot_start + BUILDER_DEADLINE_MS |
There was a problem hiding this comment.
This deadline can be just 1 sec.
| # Validate the bid | ||
| registration = registrations.get(builder_config.url) | ||
| if registration and validate_bid(state, registration, signed_bid, registration.message.fee_recipient): | ||
| bids.append((builder_config, signed_bid)) |
There was a problem hiding this comment.
Bid needs to be boosted before being added.
| | `MAX_SALT_BYTES` | `4096` | | ||
| | Name | Value | | ----------------------------------------- | | ||
| ------------------ | | `MAX_SALT_BYTES` | `4096` | | `MAX_URL_BYTES` | `4096` | | ||
| | `MAX_WHITELISTED_BUILDERS` | `10000` | | `BUILDER_DEADLINE_MS` | `2000` | | `MAX_STRATEGY_DESC_BYTES` | `4096` | |
There was a problem hiding this comment.
Need to fix formatting
6327e7e to
b4d745e
Compare
| and decide on the best possible bid after making all requests. | ||
|
|
||
| ```python | ||
| def query_builders( |
There was a problem hiding this comment.
Maybe it is not necessary to specify how to fetch bids and send registrations in the specification and leave this to implementation. We could just specify the BuilderConfig
|
I don't see how this replaces Mev Boost. There are two components to mev boost, one is to request bids from multiple builders/relays. The other one is to handle exchange of blind signed objects. The first part has to be implemented by CL clients on Gloas to be able to request signed bids from builders directly. The second part would be the core feature of Mev Boost that this PR does not make any mention of. |
How/where? https://github.com/flashbots/mev-boost/blob/develop/cli/flags.go selects from entities the current builder API MEV ecyosystem calls relays (which, "whitelist" is an odd word here: it's mostly that they have to be queried explicitly, not that other relays are providing information which is being ignored). It doesn't know or care about what the current builder API MEV ecosystem calls "builders". Yes, ePBS changes this terminology, but in terms of discussing what |
With ePBS, we won't have blind signed objects. With the Builder-API with ePBS, the CL client would query the block builders for all their bids, pick the winning bid, embed it to the beacon block and send the beacon block to the builder whose bid has been selected. I should note that, I intended to have this PR only for ePBS and not pre-ePBS. So we wouldn't have blind signing going forward in ePBS. |
Yes we can be more clear about the terminology here for sure. I will re-work that aspect. Ideally relays and builders are technically interchangable. |
ef29bb8 to
0c9dced
Compare
bharath-123
changed the title
b037d16 to
43f15ca
Compare
9d5be35 to
3b5735b
Compare
… epbs-builder-config
0e77300 to
efaf888
Compare
| ## Overview | ||
|
|
||
| This document specifies how a validator selects the best execution payload bid | ||
| from among bids received over the p2p network, bids received via the offchain |
There was a problem hiding this comment.
the use of 'offchain' and 'on-chain' is a bit overloaded throughout the docs. 'offchain' refers to both the builder API delivery channel and implicitly the trusted payment, while 'on-chain' refers to the protocol-enforced collateral. Maybe something like 'p2p' vs 'direct' for bid sources and 'trustless' vs 'trusted' for payment types would be clearer?
4 participants
TODO: update PR description