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 default LocalBlockValueBoost to 10 #13772

Merged
merged 6 commits into from
Mar 22, 2024

Conversation

fredriksvantes
Copy link
Contributor

@fredriksvantes fredriksvantes commented Mar 19, 2024

What type of PR is this?

Feature

What does this PR do? Why is it needed?

In order to help increase censorship resistance, I propose to change the default LocalBlockValueBoost to 10. This means validators will prioritize local block building unless the bid from the external block builder is 10% or higher than what the validator would receive when building locally.

Looking at stats, it can be seen that currently 63.7% of external builders are censoring transactions compared to 8.53% of validators who do local block building, so setting a minimum 10% as default can help increase the overall censorship resistance of the network.

It is still easy for validators to opt out of this by manually setting the flag to 0, but many are likely to use the default which could help with censorship resistance for the network.

@fredriksvantes fredriksvantes requested a review from a team as a code owner March 19, 2024 20:44
terencechain
terencechain previously approved these changes Mar 19, 2024
Copy link
Member

@terencechain terencechain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I support this change. However, we should likely conduct some testing before merging, considering that local boost has been seldom used. For the reviewer's reference, a similar effort can be found at flashbots/mev-boost#635.

@terencechain terencechain added the Blocked Blocked by research or external factors label Mar 19, 2024
@terencechain
Copy link
Member

Marking this as blocked to get more eyes and discussion

@fredriksvantes
Copy link
Contributor Author

fredriksvantes commented Mar 19, 2024

The same type of proposal was submitted as a PR to Lighthouse, Teku, Nimbus and Lodestar:
Nimbus: status-im/nimbus-eth2#6103
Lighthouse: sigp/lighthouse#5441
Lodestar: ChainSafe/lodestar#6568
Teku: Consensys/teku#8108
Prysm: #13772

@potuz
Copy link
Contributor

potuz commented Mar 19, 2024

Ohh cmon! when we designed this I was aiming for 20 and was voted down that anything above 0 would be controversial, Frederik proposes and it gets insta-approved, I'm jealous... definitely approve of this

potuz
potuz previously approved these changes Mar 19, 2024
@terencechain
Copy link
Member

The same type of proposal was submitted as a PR to Lighthouse, Teku, Nimbus and Lodestar:
Nimbus: status-im/nimbus-eth2#6103
Lighthouse: sigp/lighthouse#5441
Lodestar: ChainSafe/lodestar#6568
Teku: Consensys/teku#8108
Prysm: #13772

@potuz Sorry! You were right, and I was wrong, just like 99.9% of the other times.

@fredriksvantes Do you think we should give this a mention in the ACD?

@fredriksvantes
Copy link
Contributor Author

fredriksvantes commented Mar 19, 2024 via email

@tbenr
Copy link
Contributor

tbenr commented Mar 21, 2024

Nimbus and Teku merged, cmon ;-)

config/params/mainnet_config.go Outdated Show resolved Hide resolved
@prestonvanloon
Copy link
Member

I approve the initiative and will approve this PR after the value is applied at the flag level

@fredriksvantes fredriksvantes dismissed stale reviews from potuz and terencechain via 7cb2ad1 March 21, 2024 14:46
@terencechain terencechain removed the Blocked Blocked by research or external factors label Mar 21, 2024
@terencechain terencechain enabled auto-merge March 21, 2024 18:12
@terencechain terencechain added this pull request to the merge queue Mar 22, 2024
Merged via the queue into prysmaticlabs:develop with commit d193655 Mar 22, 2024
17 checks passed
@dataalways
Copy link

Has anyone in this conversation looked at the data or are we just flying blind? A local block value boost of 10% does essentially nothing for censorship resistance.

e.g., if we look at the min-bid reversion data for Lido ChainSafe (min-bid = 0.07) we see that if they were using LBVB of 10% (or even like 50%), very few of their blocks would have been locally built.

lbvb-lido-chainsafe

@MrKoberman
Copy link

How do you then boost an external block? With the current setup you cannot as the variable is a uint64 and it does not accept numbers lower then 0. I recommend to actually change this to what lighthouse does which allows you to prioritise local and also external blocks.

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.

7 participants