[MEV-Boost\Builder] Unhide hidden params for mev-boost\builder

[tbenr]

CLI argument changes changes:

--eb-endpoint -> --builder-endpoint

--Xvalidators-registration-default-enabled -> --validators-builder-registration-default-enabled
--Xvalidators-registration-timestamp-override -> --validators-builder-registration-timestamp-override
--Xvalidators-proposer-blinded-blocks-enabled -> --validators-proposer-blinded-blocks-enabled

--Xvalidators-registration-default-gas-limit -> --Xvalidators-builder-registration-default-gas-limit
--Xvalidators-registration-sending-batch-size -> --Xvalidators-builder-registration-sending-batch-size

Relaxed proposerConfig json rule to allow per pubkey configuration to have empty\null fee_recipient.
default_config still requires it.

Extended proposer-config json referenced by the existing --validators-proposer-config

A draft note covering the usage of the changes: https://hackmd.io/@StefanBratanov/BkMlo1RO9

closes #5396

Documentation content

Intro

When The Merge completes, Consensus Clients will be responsible for proposing blocks containing an Execution Payload (the Ethereum PoW Block in the context of PoS) obtained from their local Execution Clients via the Engine API.
Optionally, instead of building it locally, a Consensus Clients can configure an external “builder” to delegate the Execution Payload construction to.
This new interface is called Builder API and has been introduced to standardize the interaction with MEV providers, in the effort of making it easily accessible and interchangeable.

Teku supports this interface and allows to configure the Beacon Node to a single builder endpoint that will be trusted for generating Execution Payload. In case of failures or non timely responses, Teku will use the payload produced by the local Execution Client (the one specified with ee-endpoint)

The most common deployment is to run an specialised software (i.e. mev-boost) and configure it as the builder endpoint. This software will be responsible for requesting a payload proposal from several entities (called relays) and selecting the best bid.

Important Note
In deployment where Validator Client runs in a separate process and communicate with a Beacon Node via rest API, make sure that the Beacon Node supports the blinded block API.

new CLI args

--builder-endpoint
Optionally specify the Builder API to delegate the execution payload construction to.
example(--builder-endpoint=http://127.0.0.1:18550/)

--validators-builder-registration-default-enabled
When enabled, all validators managed by the validator client will be configured to register to builder endpoint and will use it when proposing a block.

--validators-builder-registration-timestamp-override
This parameter allows to specify a timestamp that will be used when registering validators against the builder endpoint. It is only useful in deployments where validator keys are shared between multiple nodes (Obol, SSV or similar)

--validators-proposer-blinded-blocks-enabled
This enables blinded blocks flow, a prerequisite for the usage of the builder endpoint. When --validators-builder-registration-default-enabled is enabled this option will be enabled automatically. It requires explicit enablement when used in conjunction with --validators-proposer-config.

CLI args changes

—validators-proposer-config

The specified config file now supports a new builder attribute that can be specified in the default_config as well as for each public keys.

in builder

• enabled indicates if the applicable validator key should register to and use the builder endpoint when proposing blocks.
• gas_limit is an optional parameter that allows to specify the preferred gas_limit that the builder should respect. When not specified the default value 30000000 will be used.

fee_recipient attribute becomes optional in a public key config, but remains mandatory in the default_config

{
  "proposer_config": {
    "0xa057816155ad77931185101128655c0191bd0214c201ca48ed887f6c4c6adf334070efcd75140eada5ac83a92506dd7a": {
      "fee_recipient": "0x50155530FCE8a85ec7055A5F8b2bE214B3DaeFd3", //optional
      "builder": { //optional
        "enabled": true, //mandatory
        "gas_limit": "12345654321" //optional
      }
    }
  },
  "default_config": {
    "fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A", //mandatory
    "builder": { //optional
      "enabled": false, //mandatory
       "gas_limit": "12345654321" //optional
    }
  }
}

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

[ajsutton]

The eb-endpoint name seems confusingly similar to ee-endpoint and it even took me some time to work out what eb was. Might be better to make it explicitly --external-builder-endpoint and have an alias --eb-endpoint.

The other two options possibly should be named so they're tied together (so they'd be --external-builder-registration-default-enabled. Maybe we drop the external and just have --builder-registration-enabled and --builder-endpoint etc.

Do we need to expose --validators-proposer-blinded-blocks-enabled? I'd like to make that the only way it works at some point in the future so would be good if we could avoid exposing it. Possibly enable it automatically when a builder endpoint is specified?

[tbenr]

The eb-endpoint name seems confusingly similar

yeah, agree, not particularly user friendly.

Maybe we drop the external and just have --builder-registration-enabled and --builder-endpoint etc.

I prefer this option. Btw the e was for execution :-)

Do we need to expose --validators-proposer-blinded-blocks-enabled?

the problem is that this option is for the VC. So we automatically enable it when using --validators-registration-default-enabled, but its complicated if you use --validators-proposer-config, also because it can be changed at runtime.

An option could be to simply enable the blinded block flow by default (which saves bandwidth for Bellatrix blocks), and warn if user disable it (which could prevent mev when using validators-proposer-config)

[ajsutton]

An option could be to simply enable the blinded block flow by default (which saves bandwidth for Bellatrix blocks), and warn if user disable it (which could prevent mev when using validators-proposer-config)

If we're really confident in our fallback that would be reasonable. Otherwise it could easily break for a lot of people.

[tbenr]

a beginning could be to enable it now in all our merged testnets

[ajsutton]

LGTM.

[StefanBratanov]

LGTM to me as well