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

Set defaultRelayMinBidEth to 0.05 ETH #635

Closed
wants to merge 1 commit into from

Conversation

timbeiko
Copy link

πŸ“ Summary

Defaults are powerful, and setting a non-zero defaultRelayMinBid can help increase censorship resistance.

β›± Motivation, Context and References

defaultRelayMinBid is a valuable feature to improve Ethereum's censorship resistance, but is currently off by default.

In Nov 2022, a 0.05 ETH MinBid was shown to result in validators proposing ~50% of blocks locally while keeping 80% of total fees (source). With a majority of builders currently censoring transactions (source), setting a non-zero default for this value can help increase the overall censorship resistance of the network.

While anyone can opt-out of this change trivially by setting the flag themselves, given mev-boost's broad adoption, many users are likely to stick to the defaults.


βœ… I have run these commands

  • make lint
  • make test-race
  • go mod tidy

@timbeiko timbeiko changed the title Set defaultRelayMinBidEth to 0.05 Set defaultRelayMinBidEth to 0.05 ETH Mar 19, 2024
@metachris
Copy link
Collaborator

50% local blocks seems quite destructive for the PBS and builder market ("would throw quite a bit of chaos into the equation for searchers and order-flow providers").

@jtraglia
Copy link
Collaborator

Personally, I'm not in favor of having a default min bid. I much prefer the solution that clients have already implemented, where the local payload will be used unless the builder's payload is 10% more valuable. That is a better solution which shouldn't require changes in the future, if for example the average payload changes.

  • If in 5 years the price of ETH is $10k (or higher), is the average payload value expected to be the same? If the average goes down so that its fiat value remains about the same, this will cause an increasing number of validators to produce blocks locally. This is important if we're truly targeting 50% for local payload production.
  • How will this affect testnets/devnets? The average payload value is much lower there. Will we (1) require nodes to disable the min-bid feature or (2) artificially produce payloads with values greater than 0.05 ETH to test things?

@dataalways
Copy link

I'm supportive of the change, but I think it needs stronger empirical justification.

Looking at data from proposers who already use min-bid, if the entire network adopted the change (min-bid= 0.05) proposers would lose on the order of $80 million per year in rewards. I also don't know how much I really believe in this defaults are sticky idea, the main issue is that only one of the top 20 staking entities by size (Upbit: 15th biggest) uses the parameter, are we really to believe that the top staking pools and CEXs just haven't bothered to change the default? It seems more likely to me that they just haven't been presented with proper cost-benefit analysis. It seems to me like changing the default will mostly affect solo stakers.

I would also like to see deeper discussion of the economics of client changes. It might sound like they're doing roughly equivalent things, but the distribution of blocks that they catch are vary different. The best result is probably some combination of the two methods (or looking at difference in values rather than just scaling local block values up by 10%).

@Evan-Kim2028
Copy link

Agree with @dataalways there should be a stronger empirical justification than a vitalik post from November 2022, with <3 months worth of beacon chain data.

For the other source, although the "majority of builders" are censoring transactions, this other dashboard shows that there are more non-ofac compliant blocks built than ofac compliant bllocks.

@timbeiko
Copy link
Author

Appreciate all the feedback here β€” will close as this clearly hasn't consensus to move forward!

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

Successfully merging this pull request may close these issues.

5 participants