docs: builder block selection and chain_split_halt guidance#143
docs: builder block selection and chain_split_halt guidance#143nickh-obol wants to merge 2 commits into
Conversation
ksale001
left a comment
ksale001
left a comment
There was a problem hiding this comment.
A few notes on the new Builder Block Selection section, mostly around the per-client flags. Nothing major, happy to chat through any of them.
|
|
||
| The relevant flags vary by consensus client: | ||
|
|
||
| - **Teku**: `--validators-builder-bid-compare-factor=0`. |
There was a problem hiding this comment.
I think this Teku flag might be backwards. From what I can tell, --builder-bid-compare-factor=0 means the builder bid has to beat the local block by around 100% before it ever wins, so it actually ends up favoring the local block, which is the opposite of what we want in this section. To always prefer the builder it should be --builder-bid-compare-factor=BUILDER_ALWAYS. One more thing, I believe the flag is just --builder-bid-compare-factor on the beacon node, without the validators- prefix. Could you double check both of those?
| - **Lighthouse**: `--prefer-builder-proposals`. | ||
| - **Lodestar**: `--builder.selection=builderalways` (set on the validator client). | ||
|
|
||
| With these settings the consensus client uses a builder block whenever one is available, only falling back to a locally-built block if no valid bid is returned from any configured relay in time. |
There was a problem hiding this comment.
Small thing on accuracy here. Setting --local-block-value-boost=0 on Prysm and Nimbus just removes the local bias rather than forcing the builder. It's still a value comparison, so a higher-value local block could still win. I think only Lighthouse with --prefer-builder-proposals and Lodestar with builderalways actually force builder-always. Could we soften the line about using a builder block whenever one is available so it reads accurately for all five clients?
| - **Lighthouse**: `--prefer-builder-proposals`. | ||
| - **Lodestar**: `--builder.selection=builderalways` (set on the validator client). | ||
|
|
||
| With these settings the consensus client uses a builder block whenever one is available, only falling back to a locally-built block if no valid bid is returned from any configured relay in time. |
There was a problem hiding this comment.
I think it would help to add a one-line caveat here. Always preferring the builder does maximize MEV, but it also raises the risk of a missed proposal if a relay is slow or returns a bad bid. That trade-off is basically why we used to recommend --local-block-value-boost=3, so calling it out would help operators make the right call for their setup.
2 participants
Summary
--local-block-value-boost=3recommendation and switch Lodestar frombuilderonlytobuilderalwaysfor graceful fallback. Cross-references the new section.chain_split_haltfeature in the Client Diversity section as a complementary safeguard against client bugs causing a chain split, including the--feature-set-enable=chain_split_haltflag (alpha).