ChainSafe / lodestar

🌟 TypeScript Implementation of Ethereum Consensus
https://lodestar.chainsafe.io
Apache License 2.0
1.16k stars 284 forks source link

Implement min-bid #6602

Open philknows opened 6 months ago

philknows commented 6 months ago

Problem description

MEV-boost is currently the only piece of software that is implementing min-bid to discard builder blocks below a certain threshold.

Solution description

This feature implements min-bid within the beacon node itself and a user can set the minimum bid value to consider a builder block for proposal.

Additional context

See twitter thread here: https://x.com/sproulM_/status/1772962785619538219?s=20

nflaig commented 6 months ago

Based on Vitalik's tweet a while back, it should be doable to implement some sort of heuristic that sets a min-bid value dynamically based on expected rewards by looking at N previous blocks. I am not sure yet how many N blocks you would have to look at but since we already have a rewards cache in Lodestar it might be possible for at least the last 2 epochs.

Having a min-bid option in general seems like a net plus, but setting a reasonable (static) default value is almost impossible in my opinion as setting it too low it's essentially the same as zero if market conditions change and if it's too high we just impact profitability of likely non sophisticated operators that do not follow the market all day and just stick with the default.

One other open question I have, do we want this value to be dictated by the validator client similar to boost factor or is it just set on the beacon node side?

ensi321 commented 6 months ago

Based on Vitalik's tweet a while back, it should be doable to implement some sort of heuristic that sets a min-bid value dynamically based on expected rewards by looking at N previous blocks. I am not sure yet how many N blocks you would have to look at but since we already have a rewards cache in Lodestar it might be possible for at least the last 2 epochs.

If we are to have complex calculation to decide the min-bid value, couple things to think about:

  1. How do we consolidate this calculation into one flag (be it boolean or numeric value) for users?
  2. How do we explain the function of this flag to user? Builder boost factor is already borderline difficult to explain. Where as a static min-bid makes sense because MEV-boost have had this for a long time and users are used to it.

I would suggest making it a static value. And if some research suggests a calculation that can increase censorship resistance, it could become part of the protocol when ePBS comes. Before then, I would keep the min-bid stuff simple.

Funny thing to think about is that the builder boost factor is not as effective as we thought it would be. Shall we deprecate it some day in favour of min-bid?

nflaig commented 6 months ago

How do we explain the function of this flag to user? Builder boost factor is already borderline difficult to explain. Where as a static min-bid makes sense because MEV-boost have had this for a long time and users are used to it.

While min-bid is easy to understand it terms of what happens, it is actually very hard to understand the impact of a specific min-bid value on profits and % of locally build blocks even if market conditions are stable.

E.g. if you look at impact of our 0.07 ETH min-bid on our Lido nodes, most of the time the difference in block value is very minimal and the impact on profitability is low but there are also cases where the mev block has 0.06x ETH and local block is only around 0.01 ETH.

image

I would suggest making it a static value

If we want to keep complexity low this is likely the way to go, but we might wann have another static value that limits the max delta between local and builder block, e.g. if builder block is 50% (or absolute value) more valuable than local, always pick builder block. This would help avoid outliers that have a big impact on profitability.

Funny thing to think about is that the builder boost factor is not as effective as we thought it would be. Shall we deprecate it some day in favour of min-bid?

yeah unfortunately, there is really no good % value to set, it's either too low and has no impact or if you set it too high you lose out on a lot of profits. 10% boost on local block is essentially a no-op

image

The data definitely suggests that min-bid is more effective, I am just wondering how we wanna set this. Boost factor right now is also used to communicate the block building preference from the validator client to the beacon node, so the min (0) and max (2**64 - 1) value is definitely useful, but we can just use the aliases for that and deprecate the boost factor CLI flag in favor of min-bid.

And I guess there needs to be further discussion if we should have a non zero default value for min-bid but I don't see how you would come up with a sensible default value. If you set it too low it's essential the same as zero and if it's too high you just impact profitability of likely non sophisticated operators that do not follow the market all day and adjust the min-bid value themselves.