docs: re-implement validator config page with builder.boostFactor notes #6295
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,6 @@ | ||
| # Validator Configuration | ||
|
|
||
| The following instructions are for stakers utilizing the Lodestar validator client. | ||
|
|
||
| [TOC] | ||
|
|
||
|
|
@@ -17,7 +17,7 @@ The mnemonic is randomly generated during wallet creation and printed out to the | |
|
|
||
| ### Create a wallet | ||
|
|
||
| Lodestar has removed its functionality to create wallets. | ||
|
|
||
| To create a wallet, we recommend using the official [`staking-deposit-cli`](https://github.com/ethereum/staking-deposit-cli/releases) from the Ethereum Foundation for users comfortable with command line interfaces. | ||
|
|
||
|
There was a problem hiding this comment. The term wallet here might be a bit outdated, maybe should use term keystores, or we use same wording as deposit cli introduction. Maybe "keystores and corresponding deposit data" but since the whole section is about "Create a wallet" maybe better to revise that part in a separate PR. There was a problem hiding this comment. Will follow up in another PR with the best way to align this. TBH, I'm still kinda wondering if we need this as generally, most go through the Ethereum launchpad which provides all these instructions for them already. This whole section has been around for a long time when Lodestar had these features and before the existence of a lot of this tooling + other references. |
||
|
|
@@ -88,11 +88,29 @@ Configure your validator client's fee recipient address by using the `--suggeste | |
|
|
||
| You may choose to use the `--strictFeeRecipientCheck` flag to enable a strict check of the fee recipient address with the one returned by the beacon node for added reassurance. | ||
|
|
||
| ### Configure your builder selection and/or builder boost factor | ||
|
|
||
| If you are running a Lodestar beacon with connected builder relays, you may use these validator configurations to signal which block (builder vs. local execution) for the beacon node to propose. | ||
|
|
||
philknows marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| With produceBlockV3 (enabled automatically after the Deneb hard fork), the `builder.boostFactor` is a 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 `maxprofit`. Even though this is set on the validator client, the calculation is applied on the beacon node itself. For more information, see the [produceBlockV3 Beacon API](https://ethereum.github.io/beacon-APIs/#/ValidatorRequiredApi/produceBlockV3). | ||
|
|
||
philknows marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| With Lodestar's `--builder.selection` 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. | ||
nflaig marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - `executiononly`: Validator will not trigger builder block production even if builder relays are configured on the beacon. This will always select the local execution block. | ||
| - `builderalways`: An alias of `builder.boostFactor=18446744073709551615`, which will select the builder block, unless the builder block fails to produce. The builder block may fail to produce if it's not available, not timely or there is an indication of censorship via `shouldOverrideBuilder` from the execution payload response. | ||
philknows marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - `builderonly`: Generally used for distributed validators (DVs). No execution block production will be triggered. Therefore, if a builder block is not produced, the API will fail and *no block will be produced*. | ||
philknows marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
|
There was a problem hiding this comment. we should also probably add |
||
| #### Examples using custom `builder.boostFactor` | ||
| Example 1: Setting a `builder.boostFactor` of `0` is the same as signaling `builder.selection executiononly` where the validator will always select the local execution block if available. | ||
|
|
||
philknows marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Example 2: Setting a `builder.boostFactor` of `100` is the same as signaling `builder.selection maxprofit` where the validator will always select the most profitable block between the local execution engine and the builder block from the relay. | ||
|
|
||
| Example 3: Setting `builder.boostFactor` of `80` allows you to signal that your builder block bid needs 20% more in value comparatively to your local execution block to be selected. | ||
|
|
||
| ### Submit a validator deposit | ||
|
|
||
| Please use the official Ethereum Launchpad to perform your deposits | ||
|
|
||
| - Ethereum Foundation launchpad: <https://launchpad.ethereum.org> | ||
|
|
||
| ## Run the validator | ||
|
|
@@ -105,7 +123,7 @@ To start a Lodestar validator run the command: | |
|
|
||
| You should see confirmation that modules have started. | ||
|
|
||
|
There was a problem hiding this comment. The sh should stay in here "```sh" There was a problem hiding this comment. Those are logs, bash syntax highlighting looks wrong There was a problem hiding this comment. Doesn't really benefit the docs if it doesn't look similar to what you would actually even see in your terminal. Just leaving as txt should be fine |
||
| ``` | ||
| Nov-29 10:47:13.647[] info: Lodestar network=sepolia, version=v1.2.2/f093b46, commit=f093b468ec3ab0dbbe8e2d2c8175f52ad88aa35f | ||
| Nov-29 10:47:13.649[] info: Connecting to LevelDB database path=/home/user/.local/share/lodestar/sepolia/validator-db | ||
| Nov-29 10:47:51.732[] info: 3 local keystores | ||
|
|
||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the renaming 👍