feat: set default builderBoostFactor to 90 #6568
Conversation
fredriksvantes
changed the title
|
Nimbus: status-im/nimbus-eth2#6103 |
philknows
changed the title
Setting a builder boost factor of 90 means the builder block value will be reduced by 10% but this is not the same as the increasing the local block value by 10%. Let's assume a local block value of 100, if builder block has value of 110 (10% more) it will still pick local block
We have notes about the calculation in our docs. I don't think it matters in this case as the difference is marginal. |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## unstable #6568 +/- ##
============================================
- Coverage 61.69% 61.68% -0.01%
============================================
Files 556 556
Lines 58820 58829 +9
Branches 1887 1888 +1
============================================
+ Hits 36287 36288 +1
- Misses 22492 22500 +8
Partials 41 41 |
|
We should do a follow up PR on this to make users aware of the default setting on our documentation. |
|
I have a question to this after giving it some more thought about how we deal with This will essentially break the idea of having a |
|
@philknows that's a good point, maybe we add another alias that translates to boost factor 90? Also on another thought, this change might be good for censorship resistance but it might also hurt the credible neutrality as something like this should be enforced via market forces or changes that do not reduce profits of stakers without them potentially being aware of it, not everybody closely reads release notes or follow the news. So the question for me is also should the client software be opinionated about something like this because "we know what's best for the user (and the network)" or should the user decide themselves. Might be better to push this similar to client diversity |
To be fair, it'll be disclosed and the user has full ability to change their builder selection preference at free will. It's just the name |
I don't think this analysis is profound at all. Censoring transactions is economically irrational and if more contracts (like Uniswap) would be on the OFAC list builders in US would be forced to relocate to a different jurisdiction or would become less competitive and lose their market share sooner or later. Websites like censorship.pics claiming that a certain % of slots are being censored is also not correct, looking at Tornado cash router it doesn't even come close to a tx every slot. And if there is no tx like this in the mempool that the builder explicitly does not include then claiming the slot is being censored is just not correct. So how exactly do we explain to the user that it was in the interest of the network to produce the block locally and missing out on some rewards? Maybe I am too much of a capitalist here but generally I think "state intervention" should be avoided if it's not critical. |
|
My thinking is that people have always needed to change default settings in order to not build local blocks 100% of the time (e.g. they have to explicitly specify a relay or mev-boost proxy), so max profit has never been the default setting for a validator. When they are viewing the documentation on how to configure lodestar to use an external builder, they would also see the default builder boost and how to adjust it. I am primarily looking at this from the angle of making Ethereum more censorship resistant, but from a capitalist point of view I can also see some positive long term effects for validators (and the whole ecosystem). EIP-1559 was for example seen by many miners as short term negative as the basefee was lost, but the long term effects for the ecosystem appears to have been positive. With this proposed change, builders would need to submit blocks that are at least 10% more profitable than the local mempool, which - assuming builders have or can achieve that profit margin - could mean validators end up receiving higher rewards. Long term I also believe increased censorship resistance will have a positive effect on Ethereum. |
|
|
||
| With Lodestar's `--builder.selection` validator options, you can select: | ||
|
|
||
| - `maxprofit`: Default setting for Lodestar set at `--builder.boostFactor=100`. This default setting will always choose the more profitable block. Using this option, you may customize your `--builder.boostFactor` to your preference. Examples of its usage are below. | ||
| - `default`: Default setting for Lodestar set at `--builder.boostFactor=90`. This default setting will have a local block boost of ~10%. Using this option, you may customize your `--builder.boostFactor` to your preference. Examples of its usage are below. |
There was a problem hiding this comment.
The docs are a bit misleading here, maxprofit is actually not the default but executiononly is. We only produce builder blocks if --builder flag is set or if --builder.selection is set to maxprofit | builderalways | builderonly, see builder.selection docs
Our docs are bit misleading here, see #6568 (comment). It is not actually the default setting.
I appreciate the push for this and at first I also thought it is a good idea but after thinking about this a bit more it does not seem reasonable to change this right now. Censorship resistance is a really vague term imo, it hard to define when is Ethereum is or is not censorship resistant. But it is easy to tell if Ethereum is censoring or not, and looking at tornado cash txs, those are clearly not censored. Imo what makes Ethereum censorship resistant is a large set of independent node operators which is the case for Ethereum. And I have high confidence in those operators (especially solo stakers) to do the right thing if there was meaningful / measurable censorship on Ethereum. The change proposed here might increase the % of locally build blocks slightly and make the graphs on censorship.pics and other similar websites look prettier but other than that doesn't meaningfully change anything. So it seems more like a marketing measure than solving a real issue. And don't get me wrong, building local blocks is great for many reasons, like not extracting value from user transactions which is also why I use a high min-bid myself. But I don't think right now it matters for censorship resistance. |
|
Just wanted to include this reference with data for some discussion about whether or not this is a meaningful change, which would require a bit of re-working on how to handle the UX. |
We also need to keep in mind that this is highly dependent on market conditions, in a bull market with high price volatility, the local block needs to be boosted much more as MEV increases disproportional compared to local block value. Considering this, educating users about this setting as an alternative to |
|
Based on our standup on Apr 2, we decided that we will move forward with this with feedback from the community and with additional data that shows a very mild difference for inclusion. Although this will not end the conversation on censorship resistance, there is harder support for #6602 which data points will make more of a difference. Once we figure out the alias option name because it's no longer |
There was a problem hiding this comment.
I think we should not change the maxprofit behavior and keep it as is. Instead I think it's better to add a new selection option and use that as default instead of maxprofit. This would ensure that users who have set this explicitly won't be affected and it's no longer a breaking change.
| builderSelection = builderSelection ?? routes.validator.BuilderSelection.MaxProfit; | ||
| builderBoostFactor = builderBoostFactor ?? BigInt(100); |
There was a problem hiding this comment.
I reverted the changes on the beacon node side as in case of Lodestar the boost factor is dictated by the validator client and setting a different default here is undocumented behavior we should avoid.
| @@ -260,7 +260,7 @@ export const validatorOptions: CliCommandOptions<IValidatorCliArgs> = { | |||
| "builder.boostFactor": { | |||
| type: "string", | |||
| description: | |||
| "Percentage multiplier the block producing beacon node must apply to boost (>100) or dampen (<100) builder block value for selection against execution block. The multiplier is ignored if `--builder.selection` is set to anything other than `default` or `maxprofit`", | |||
There was a problem hiding this comment.
Since we have the default for users that do not change the defaults it makes more sense to only apply the manually set boost factor in case of maxprofit as it is anyhow a setting for more advanced users.
| @@ -10,12 +10,12 @@ proposer_config: | |||
| builder: | |||
| gas_limit: "35000000" | |||
| selection: "maxprofit" | |||
| boost_factor: "18446744073709551616" | |||
| boost_factor: "50" | |||
There was a problem hiding this comment.
Might encourage users to set it even lower :)
|
Got a conflict here before merging. |
* Set default builderBoostFactor to 90 * Changing "MaxProfit" to "Default" * Update tests * Add default as new builder selection option * Ignore manually set boost factor if selection is default * Add ref to twitter thread * Fix parse proposer config test * Update comment --------- Co-authored-by: Nico Flaig <nflaig@protonmail.com>
|
🎉 This PR is included in v1.18.0 🎉 |
Motivation
Improve censorship resistance
Description
In order to help increase censorship resistance, I propose to change the default builderBoostFactor to 90. 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 100, but many are likely to use the default which could help with censorship resistance for the network.