feat: Make BUILDER_PROPOSAL_DELAY_TOLERANCE Configurable #7382
Conversation
|
Well, I'm a bit skeptical this is the best way to achieve most of those goals. I'd ask some questions: is this, in practice, timing out for you? If it's not, none of:
apply. If it is timing out, that's interesting, though generally speaking, I'd say one would have to coordinate this with It won't reliably increase the yield with a well-functioning relay, in particular, because a well-functioning relay will typically respond somewhat quickly whenever they're queried, and similarly in general if it's not timing out then increasing the timeout is a no-op on the rest. If one wants to look at way to increase yield, the traditional thing is to push the entire bid request later in the slot; one can find analysis showing (at least a couple years ago, last time I saw them) near-linear increases in MEV at slot start + 0 seconds, to slot start + 1s, to slot start +2s, etc. Risking going past 4s for when they're received, though, does backfire/become a much riskier game. Either way, I don't see how this PR achieves what it states it achieves. |
|
There is no timeout issue. As you menioned, pushing the bid request from T+1 to T+2 or even T+2.5 could allow gathers an extra 1 to 1.5 sec for the builder to submit a valueable bid (From more MEV opportunities or more transactions for fees) Since my average signing time is always below T+2, this indicates that there is a buffer to push for a later response to boost the yield. For the error, I will take a look. |
|
…nce type from int to uint16
|
The overall approach here is to be able to ensure Nimbus's timeout is long enough to accommodate both the fairly short timeout intrinsic to fetching the bid, plus whatever delay (T+1, T+2, T+2.5, etc) that the timing game strategy requires? |
|
Yes, that's correct. |
| @@ -0,0 +1,18 @@ | |||
| ## Builder Proposal Delay Tolerance | |||
|
|
|||
| You can now configure the builder proposal delay tolerance (MEV block builder timeout) via the following flag: | |||
There was a problem hiding this comment.
Regarding now: By the time this would appear in the documentation, it will simply be the case.
It's true that some programming language documentation, or e.g., the curl docs, explicitly say some option appeared in $SOFTWARE version x.y.z. I'm not sure that's that useful here, since due to the hardfork mechanism, essentially no one is running a Nimbus version older than a year at any given time, and typically less.
The release notes do document this the appearance of such features, for people who need a timeline.
Similarly, whether or not this is combined with https://github.com/status-im/nimbus-eth2/blob/stable/docs/the_nimbus_book/src/external-block-builder.md it's worth ensuring both use consistent terminology.
siddarthkay
force-pushed
the
unstable
branch
from
6c84d01 to
b118196
Compare
Description:
Currently, the timeout value for
BUILDER_PROPOSAL_DELAY_TOLERANCEis hardcoded to 1500.milliseconds in beacon_chain/spec/mev/electra_mev.nim. Allowing this value to be configurable would enable operators to adjust the timeout as needed for different environments or use cases.Motivation:
In some scenarios, increasing the timeout would allow the builder extra time to gather more transactions or MEV value, potentially improving block value and network efficiency. Making this value configurable allows for experimentation and optimization based on network conditions or operator needs.
Proposed Solution:
Benefits:
ref. #7380