Set default localBlockValueBoost to 10

[fredriksvantes]

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 users 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]

Nimbus: #6103
Lighthouse: sigp/lighthouse#5441
Lodestar: ChainSafe/lodestar#6568
Teku: Consensys/teku#8108
Prysm: prysmaticlabs/prysm#13772

[tersec]

Needs to target unstable.

[github-actions]

Unit Test Results

         9 files  ±0    1 107 suites  ±0   30m 0s ⏱️ + 2m 44s
  4 232 tests ±0    3 885 ✔️ ±0  347 💤 ±0  0 ❌ ±0 
16 891 runs  ±0  16 493 ✔️ ±0  398 💤 ±0  0 ❌ ±0 

Results for commit 2fdedcb. ± Comparison against base commit fc9c72f.

[etan-status]

This was being discussed in ethereum/pm#987

• Prysm has concerns about this being a surprising default and prefers it to be a design space for clients
• Lighthouse suggested to require the user to explicitly specify a value if using a builder, to raise awareness of it instead of exploiting unawareness about this
• Furthermore, it depends on the market situation what an optimal value should be to strike a balance for the percentage that builders get to control

[tersec]

Alright. #6118 in the meantime.

But I'll say that I don't find the suggestion of requiring the user to explicitly specify a value particularly valuable either intrinsically or taking into advantage that it'd presumably exclude existing configurations.

When I added this setting to Nimbus, I regarded 0 as, well, slightly less surprising than any other value, a bit arbitrary.

But sure, to the extent it's viewed as problematic either way, am fine with holding this at the status quo.

[fredriksvantes]

Some info from clients on their status to implement this:
Prysm wasn't opposed to this (Potuz suggested 20% instead of 10%), but he was interested in documenting these things at some place. Their latest status: prysmaticlabs/prysm#13772 (comment)

Teku: Consensys/teku#8108

Lodestar: ChainSafe/lodestar#6568 (comment)

Lighthouse is still considering how they want to do it: sigp/lighthouse#5441 (comment)

Also I believe the market situation described in the comment above was related to setting a Fixed minbid value (e.g. require bids from external builders to be >= 0.05 ETH). Setting a fixed value for minbids could be an issue if the market is on fire and both local and external blocks are >= 0.05 ETH. This proposal where setting it to 10%, however, means its handled dynamically and as such doesn't have those problems.

[tersec]

Well, I didn't see an issue with it to begin with, thus the merge. I'd be ok merging again, but at least initially it looked like maybe there were concerns I hadn't anticipated. It does not look like they turned out nearly as severe as they could have been.

Prysm and Teku merged. Lodestar appears to be running up against basically how they phased their --builder.selection maxprofit, but the Nimbus BN never made such a commitment in any explicit way.

Lighthouse is still considering how they want to do it: sigp/lighthouse#5441 (comment)

if we want to raise awareness of this feature and encourage users to set this to what they want, my preference would be to require --builder-boost-factor if --builder is used

Nimbus will not be making its UI more error-prone for this purpose.

I was surprised to an extent that it's a controversial thing. I regarded 0% as, well, slightly less surprising a default, but not by that much, than a modest boost. Given the risk of failure of the builder API, one might even view it in a risk-adjusted return way. EL blocks hold relatively little risk, though not none. They're at least under the control of users.

There have been dozens of MEV blocks this year alone which failed because, apparently, of this optimistic validation approach. To their credit, it fails slightly differently each time, but it does fail, repeatedly, in a way where users do eventually get recourse so far but only after missing a block. So it's not clear 0% is even a "neutral" default: it's rewarding the MEV infrastructure for risk-taking likely against the interests of users, aside from any centralization/censorship concerns, which they were not doing at the time of that choice.

If not 0%, then the next not-contrived sounding options are 5% and 10%. If it were exactly 6%, that would almost ask for some explanation why, so big round numbers work better. I'm ultimately okay with any of 0, 5, or 10% as in this PR.

[tersec]

#6126 will revert the revert, i.e. re-apply this PR.

[MrKoberman]

Why not do it the same way as lighthouse, decreasing the number from 100 to increase chances on using local block instead of external? With lighthouse implementation you can go in either directions, either increase changes of using external block or local.

[tersec]

Why not do it the same way as lighthouse, decreasing the number from 100 to increase chances on using local block instead of external? With lighthouse implementation you can go in either directions, either increase changes of using external block or local.

nimbus-eth2/beacon_chain/conf.nim

Lines 646 to 651 in f20a21c

	# Flag name and semantics borrowed from Prysm
	# https://github.com/prysmaticlabs/prysm/pull/12227/files
	localBlockValueBoost* {.
	desc: "Increase execution layer block values for builder bid comparison by a percentage"
	defaultValue: 10
	name: "local-block-value-boost" .}: uint8

documents that this was explicitly modeling the Prysm command-line option at the time. Using Lighthouse's would have been reasonable, as well, but I'm not sure it existed at the time.

Any further changes likely to align with ethereum/beacon-APIs#386 and its builder_comparison_factor in a spec-based way rather than whatever yet another CL implementation happened to do.

[MrKoberman]

True but the endpoint with custom builder_comparison_factor at the moment mev-boost cannot take advantage of.

[tersec]

True but the endpoint with custom builder_comparison_factor at the moment mev-boost cannot take advantage of.

In general or with Nimbus? If the latter, sure, that's a gap in the Nimbus Beacon API functionality which will be filled.

In general, that's an issue with mev-boost-based infrastructure, if it cannot take advantage of builder_comparison_factor.

[MrKoberman]

With nimbus and prysm at the moment from what we are looking at. With lighthouse we can achieve using --produce-block-v3 and --builder-boost-factor={number}.

[tersec]

In which case the only issue is that Nimbus doesn't yet implement builder_comparison_factor, but that's going to happen at some point. Is there a reason that one has to use some command-line option for a BN as opposed to a parameter to produceBlockV3?