Feature: Add `--prefer-builder-proposals`

[yorickdowne]

Is your feature request related to a problem? Please describe.

A home validator with limited bandwidth may prefer to always use builder blocks, because a local block would be orphaned when blobs can't be uploaded in time, post-Fusaka.

Describe the solution you'd like

Add --prefer-builder-proposals, which does what it says on the tin. Always use builder block unless it's not being offered or times out, errors, &c

Why this and what does that do that --local-block-value-boost 0 doesn't do? It uses a builder block, even if the local block would have paid better or the same.

Describe alternatives you've considered

1. Leave as-is - but a produced block at all is better than a theoretically better-paying local block that gets orphaned

Edit: 2) Or introduce --builder-block-value-boost, instead of the inversed --local-block-value-boost, which then allows setting the value to 2**64 - 1.

[tersec]

https://ethereum.github.io/beacon-APIs/#/Validator/produceBlockV3 already supports this:

builder_boost_factor=2**64 - 1: prefer the external builder payload unless an error or beacon node health check makes it unviable.

[yorickdowne]

Indeed, and I've used that value where clients don't have a more obvious alias. With Nimbus, the parameter is reversed: --local-block-value-boost, so a value of 10 is like a builder boost of 90. I am not sure how to configure a high builder boost factor with Nimbus.

Introducing --builder-block-value-boost as an alternative to --local-block-value-boost would resolve this, and make Nimbus behave like all other clients.

[tersec]

Indeed, and I've used that value where clients don't have a more obvious alias. With Nimbus, the parameter is reversed: --local-block-value-boost, so a value of 10 is like a builder boost of 90. I am not sure how to configure a high builder boost factor with Nimbus.

Introducing --builder-block-value-boost as an alternative to --local-block-value-boost would resolve this, and make Nimbus behave like all other clients.

--local-block-value-boost (and --builder-block-value-boost) are only there for the non-VC case, to begin with. I'm not, as such, sure why the various non-Nimbus/Teku/Grandine (I think is the complete list) of clients which only work through separate validator client functionality would have any such flags at all.

Historically, --local-block-value-boost was a copy of some other CL's parameters at the time, but now that there's a spec-based way of doing this, I'm not sure what the added value is of yet another client-specific flag.

[yorickdowne]

My understanding is this is a VC-level flag: Communicated to the CL. It's a way for a validator client to indicate their preference for local building unless remote pays N% more.

I have support for this with Vero, Vouch (pure VC projects), and the VCs that come with Prysm, Teku, Lodestar, Lighthouse, Grandine, whether built-in or standalone. Nimbus is the one I'm struggling with, a bit.

I don't follow the "spec-based way of doing this" - sure I get the builder boost factor can be set, but doesn't the VC still have to set it?

"builder_boost_factor=2**64 - 1: prefer the external builder payload unless an error or beacon node health check makes it unviable."

This is something the VC communicates to the CL.

[yorickdowne]

I finally get what you are saying, @tersec . Nimbus doesn't have a --builder-boost-factor on the VC, you do this on the CL

That's unlike every other VC out there.

Would you consider adding --builder-boost-factor to the VC?

And if so, do you want a fresh issue for it?

This issue was created with the assumption that the local boost parameter was a VC parameter, but reversed - it's not. It's a CL parameter. I get that now.

[tersec]

To the extent this is something worth adding to the VC, and it would be reasonable, I'd probably lean towards preferring copying the produceBlockV3 approach directly, and have the VC pass it through unchanged, rather than add some additional layer over that. It's well-documented how it works, and corresponds directly with the mechanics of the beacon API.

[yorickdowne]

@tersec I'm not deep enough in the mechanics to know what you'd do underneath. The flags I've seen are --builder-boost-factor <factor>, where <factor> is an integer and can go up to 2**64 - 1, and --prefer-builder-proposals, which is a user-friendly alias for a high builder boost factor. This is on the VC. My understanding is this then instructs the CL on the preference it should use.