ChainSafe · jeluard · Jun 12, 2024 · Jun 7, 2024 · Jun 11, 2024 · Jun 12, 2024
@@ -48,8 +48,8 @@ docs/pages/**/*-cli.md
 docs/pages/assets
 docs/pages/images
 docs/pages/security.md
-docs/pages/lightclient-prover/lightclient.md
-docs/pages/lightclient-prover/prover.md
+docs/pages/libraries/lightclient-prover/lightclient.md
+docs/pages/libraries/lightclient-prover/prover.md
 docs/pages/api/api-reference.md
 docs/pages/contribution/getting-started.md
 ## Docusaurus

@@ -17,7 +17,7 @@
 - :gear: Follow the installation method for [source install](https://chainsafe.github.io/lodestar/getting-started/installation/#build-from-source), [NPM install](https://chainsafe.github.io/lodestar/getting-started/installation/#install-from-npm-not-recommended), or [Docker install](https://chainsafe.github.io/lodestar/getting-started/installation/#docker-installation) to install Lodestar. Or use our [Lodestar Quickstart scripts](https://github.com/ChainSafe/lodestar-quickstart).
 - :books: Use [Lodestar libraries](https://chainsafe.github.io/lodestar/supporting-libraries/libraries/) in your next Ethereum Typescript project.
 - :globe_with_meridians: Run a beacon node on [mainnet or a public testnet](https://chainsafe.github.io/lodestar/getting-started/starting-a-node/).
-- :computer: Utilize the whole stack by [starting a local testnet](https://chainsafe.github.io/lodestar/advanced-topics/setting-up-a-testnet/).
+- :computer: Utilize the whole stack by [starting a local testnet](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet/).
 - :spiral_notepad: View the Lodestar [CLI commands and options](https://chainsafe.github.io/lodestar/reference/cli/).
 - :nerd_face: View the [Package and dependency structure](https://chainsafe.github.io/lodestar/contribution/depgraph/).
 - :memo: Prospective contributors can read the [contributing section](./CONTRIBUTING.md) to understand how we develop and test on Lodestar.

@@ -21,10 +21,10 @@ Run a beacon node as a **bootnode**, with 8 validators with the following comman
   --reset
 ```
 
-`--genesisValidators` and `--genesisTime` define the genesis state of the beacon chain. `--dataDir` defines a path where
-lodestar should store the beacon state.
-`--enr.ip` sets the ENR IP entry for the node (essential for second node to connect via `enr`) and `--enr.udp` exposes the `discv5` discovery service (if you want to connect more than 1 node and enable discovery amongst them via _bootnode_).
-Lastly the `--reset` flag ensures the state is cleared on each restart - which is useful when testing locally.
+[`--genesisValidators`](../dev-cli.md#--genesisvalidators) and [`--genesisTime`](../dev-cli.md#--genesistime) define the genesis state of the beacon chain. [`--dataDir`](../dev-cli.md#--datadir) defines a path where
+Lodestar should store the beacon state.
+[`--enr.ip`](../dev-cli.md#--enrip) sets the ENR IP entry for the node (essential for second node to connect via `enr`) and [`--enr.udp`](../dev-cli.md#--enrudp) exposes the Discv5 discovery service (if you want to connect more than 1 node and enable discovery amongst them via _bootnode_).
+Lastly the [`--reset`](../dev-cli.md#--reset) flag ensures the state is cleared on each restart - which is useful when testing locally.
 
 Once the node has started, make a request to `curl http://localhost:9596/eth/v1/node/identity` and copy the `enr` value.
 
@@ -49,16 +49,16 @@ Start the second node without starting any validators and connect to the first n
   --reset
 ```
 
-By default, lodestar starts as many validators as the number supplied by `--genesisValidators`. In order to not start any validator, this is overridden by
-the `--startValidators` option. Passing a value of `0..0` means no validators should be started.
+By default, Lodestar starts as many validators as the number supplied by [`--genesisValidators`](../dev-cli.md#--genesisvalidators). In order to not start any validator, this is overridden by
+the [`--startValidators`](../dev-cli.md#--startvalidators) option. Passing a value of `0..0` means no validators should be started.
 
-Also, take note that the values of `--genesisValidators` and `--genesisTime` must be the same as the ones passed to the first node in order for the two nodes
+Also, take note that the values of [`--genesisValidators`](../dev-cli.md#--genesisvalidators) and [`--genesisTime`](../dev-cli.md#--genesistime) must be the same as the ones passed to the first node in order for the two nodes
 to have the same beacon chain.
 
-Also `--port` and `--rest.port` are supplied since the default values will already be in use by the first node.
+Also [`--port`](../dev-cli.md#--port) and [`--rest.port`](../dev-cli.md#--restport) are supplied since the default values will already be in use by the first node.
 
 The `--network.connectToDiscv5Bootnodes` flags needs to be set to true as this is needed to allow connection to boot ENRs on local devnet.
-The exact ENR of node to connect to is then supplied via the `--bootnodes` flag.
+The exact ENR of node to connect to is then supplied via the [`--bootnodes`](../dev-cli.md#--bootnodes) flag.
 
 Once the second node starts, you should see an output similar to the following in either of the terminals:
 
@@ -93,7 +93,7 @@ will give a result similar to the following:
 
 ## Post-Merge local testnet
 
-To set up a local testnet with a Post-Merge configuration, you may need to add the following parameters (in addition to the parameters described above) to your `lodestar dev` command:
+To set up a local testnet with a Post-Merge configuration, you may need to add the following parameters (in addition to the parameters described above) to your [`lodestar dev`](../dev-cli.md#dev-options) command:
 
 - `--params.ALTAIR_FORK_EPOCH 0`
 - `--params.BELLATRIX_FORK_EPOCH 0`

@@ -10,25 +10,24 @@ title: Home
 
 ### Getting started
 
-- Install [binaries](./run/getting-started/installation.md/#binaries), follow the installation method for [source install](./run/getting-started/installation.md/#build-from-source) or [Docker install](./run/getting-started/installation.md/#docker-installation) to install Lodestar. Or use our [Lodestar Quickstart scripts](https://github.com/ChainSafe/lodestar-quickstart).
+- Install [binaries](./run/getting-started/installation/#binaries), follow the installation method for [source install](./run/getting-started/installation/#build-from-source) or [Docker install](./run/getting-started/installation/#docker-installation) to install Lodestar. Or use our [Lodestar Quickstart scripts](https://github.com/ChainSafe/lodestar-quickstart).
 - Use [Lodestar libraries](./supporting-libraries/index.md) in your next Ethereum Typescript project.
 - Run a beacon node on [mainnet or a public testnet](./run/beacon-management/starting-a-node.md).
 - Utilize the whole stack by [starting a local testnet](./contribution/advanced-topics/setting-up-a-testnet.md).
-- View the Lodestar [CLI commands and options](./run/beacon-management/beacon-cli.md)
+- View the Lodestar Beacon [CLI commands and options](./run/beacon-management/beacon-cli.md)
 - Prospective contributors can read the [contributing section](./contribution/getting-started.md) to understand how we develop and test on Lodestar.
-- If you have questions [submit an issue](https://github.com/ChainSafe/lodestar/issues/new) or join us on [Discord](https://discord.gg/yjyvFRP)!
+- If you have questions [submit an issue](https://github.com/ChainSafe/lodestar/issues/new/choose) or join us on [Discord](https://discord.gg/yjyvFRP)!
 - Please note our [security policy](./security.md).
-- Sign up to our [mailing list](https://chainsafe.typeform.com/lodestar) for announcements and any critical information about Lodestar.
 
 ## Specifications
 
 Hardware specifications minimum / recommended, to run the Lodestar client.
 
 |           | Minimum                          | Recommended                       |
 | --------- | -------------------------------- | --------------------------------- |
-| Processor | Intel Core i5–760 or AMD FX-8100 | Intel Core i7–4770 or AMD FX-8310 |
-| Memory    | 4GB RAM                          | 8GB RAM                           |
-| Storage   | 20GB available space SSD         | 100GB available space SSD         |
+| Processor | Intel Core i3–9100 or AMD Ryzen 5 3450 | Intel Core i7–9700 or AMD Ryzen 7 4700 |
+| Memory    | 16GB RAM                          | 32GB RAM                           |
+| Storage   | 100GB available space SSD         | 1TB available space SSD         |
 | Internet  | Broadband connection             | Broadband connection              |
 
 ## About these docs

@@ -51,4 +51,4 @@ Configuring your node to store and prune data is key to success. On average you
 
 Logs can also become quite large so please check out the section on [log management](../logging-and-metrics/log-management.md) for more information.
 
-There is really only one flag that is needed to manage the data for Lodestar, [`--dataDir`](./beacon-management/beacon-cli#--datadir). Other than that handling log management is really the heart of the data management story. Beacon node data is what it is. Depending on the execution client that is chosen, there may be flags to help with data storage growth but that is outside the scope of this document.
+There is really only one flag that is needed to manage the data for Lodestar, [`--dataDir`](./beacon-cli#--datadir). Other than that handling log management is really the heart of the data management story. Beacon node data is what it is. Depending on the execution client that is chosen, there may be flags to help with data storage growth but that is outside the scope of this document.
@@ -39,16 +39,19 @@ When starting up a Lodestar beacon node in any configuration, ensure you add the
 ### Ensure JWT is configured with your execution node
 
 **For Go Ethereum:**
-Use the `--authrpc.jwtsecret /data/jwtsecret` flag to configure the secret. Use their documentation [here](https://geth.ethereum.org/docs/interface/merge).
+Use the `--authrpc.jwtsecret /path/to/jwtsecret.hex` flag to configure the secret. Use their documentation [here](https://geth.ethereum.org/docs/getting-started#start-geth).
 
 **For Nethermind:**
-Use the `--JsonRpc.JwtSecretFile /data/jwtsecret` flag to configure the secret. Use their documentation [here](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/running-nethermind-post-merge#jwtsecretfile).
+Use the `--JsonRpc.JwtSecretFile /path/to/jwtsecret.hex` flag to configure the secret. Use their documentation [here](https://docs.nethermind.io/get-started/consensus-clients/#configuring-json-rpc-interface).
 
 **For Besu:**
-Use the `--engine-jwt-secret=<FILE>` flag to configure the secret. Use their documentation [here](https://besu.hyperledger.org/en/stable/Reference/CLI/CLI-Syntax/#engine-jwt-secret).
+Use the `--engine-jwt-secret=/path/to/jwtsecret.hex` flag to configure the secret. Use their documentation [here](https://besu.hyperledger.org/public-networks/how-to/use-besu-api/authenticate#2-create-the-jwt).
 
 **For Erigon:**
-Use the `--authrpc.jwtsecret` flag to configure the secret. Use their documentation [here](https://github.com/ledgerwatch/erigon?tab=readme-ov-file#beacon-chain-consensus-layer).
+Use the `--authrpc.jwtsecret /path/to/jwtsecret.hex` flag to configure the secret. Use their documentation [here](https://github.com/ledgerwatch/erigon?tab=readme-ov-file#beacon-chain-consensus-layer).
+
+**For Reth:**
+Use the `--authrpc.jwtsecret /path/to/jwtsecret.hex` flag to configure the secret. Use their documentation [here](https://reth.rs/run/mainnet.html?highlight=jwt#running-the-reth-node).
 
 ## Run a beacon node
 
@@ -92,7 +95,7 @@ If your node is stuck with `Searching for peers` review your network configurati
 
 By default, Lodestar stores all configuration and chain data at the path `$XDG_DATA_HOME/lodestar/$NETWORK_NAME`.
 
-A young testnet should take a few hours to sync. If you see multiple or consistent errors in the logs, please open a [Github issue](https://github.com/ChainSafe/lodestar/issues/new) or reach out to us in [Discord](https://discord.gg/yjyvFRP). Just by reporting anomalies you are helping accelerate the progress of Ethereum Consensus, thanks for contributing!
+A young testnet should take a few hours to sync. If you see multiple or consistent errors in the logs, please open a [Github issue](https://github.com/ChainSafe/lodestar/issues/new/choose) or reach out to us in [Discord](https://discord.gg/yjyvFRP). Just by reporting anomalies you are helping accelerate the progress of Ethereum Consensus, thanks for contributing!
 
 :::warning
 It is dangerous to expose your Beacon APIs publicly as there is no default authentication mechanism provided. Ensure your beacon node host is not exposing ports 8545 or 9596 outside of your internal network.

@@ -2,7 +2,7 @@
 
 ## Binaries
 
-Binaries can be downloaded from [this page](https://github.com/ChainSafe/lodestar/releases/) under the `Assets` section.
+Binaries can be downloaded from [the release page](https://github.com/ChainSafe/lodestar/releases/latest) under the `Assets` section.
 
 ## Docker Installation
 
@@ -85,7 +85,7 @@ Lodestar should now be ready for use.
 ./lodestar --help
 ```
 
-See [Command Line Reference](./../../reference/cli.md) for further information.
+See [Command Line Reference](./../beacon-management/beacon-cli.md) for further information.
 
 ### Known Issues
 

@@ -1,5 +1,5 @@
 ---
-title: Stake with a Validator Client
+title: Starting a Validator Client
 ---
 
 # Validator Configuration
@@ -30,7 +30,7 @@ You will also need the passphrase used the encrypt the keystore. This can be spe
 
 #### Option 1: Import Keys To Lodestar's Keystores Folder
 
-You can load the keys into the keystore folder using the `validator import` command. There are two methods for importing keystores:
+You can load the keys into the keystore folder using the [`validator import`](../validator-management/validator-cli.md#validator-import) command. There are two methods for importing keystores:
 
 _Interactive passphrase import_
 
@@ -50,13 +50,13 @@ The interactive passphrase import method will prompt every keystore in the `vali
 The plaintext passphrase file import method will allow you to import all keystores in the `validator_keys` folder encrypted with the same password contained in `password.txt` for efficiency.
 :::
 
-Once imported with either method, these keystores will be automatically loaded when you start the validator. To list the imported keystores, use the `validator list` command.
+Once imported with either method, these keystores will be automatically loaded when you start the validator. To list the imported keystores, use the [`validator list`](./validator-cli.md#validator-list) command.
 
 ---
 
 #### Option 2: Import Keys When Starting the Validator
 
-To import keys when you start the validator specify the `--importKeystores` and `--importKeystoresPassword` flags with the `validator` command:
+To import keys when you start the validator specify the [`--importKeystores`](./validator-cli.md#--importkeystores) and [`--importKeystoresPassword`](./validator-cli.md#--importkeystorespassword) flags with the [`validator`](./validator-cli.md#base-validator-command) command:
 
 ```bash
 ./lodestar validator --importKeystores ./validator_keys --importKeystoresPassword ./password.txt
@@ -70,17 +70,17 @@ If you import keys using `--importKeystores` at runtime (Option 2) any keys load
 
 Post-Merge Ethereum requires validators to set a **Fee Recipient** which allows you to receive priority fees when proposing blocks. If you do not set this address, your priority fees will be sent to the [burn address](https://etherscan.io/address/0x0000000000000000000000000000000000000000).
 
-Configure your validator client's fee recipient address by using the `--suggestedFeeRecipient` flag. Ensure you specify an Ethereum address you control. An example of a fee recipient set with the address `0xB7576e9d314Df41EC5506494293Afb1bd5D3f65d` would add the following flag to their configuration: `--suggestedFeeRecipient 0xB7576e9d314Df41EC5506494293Afb1bd5D3f65d`.
+Configure your validator client's fee recipient address by using the [`--suggestedFeeRecipient`](./validator-cli.md#--suggestedfeerecipient) flag. Ensure you specify an Ethereum address you control. An example of a fee recipient set with the address `0xB7576e9d314Df41EC5506494293Afb1bd5D3f65d` would add the following flag to their configuration: `--suggestedFeeRecipient 0xB7576e9d314Df41EC5506494293Afb1bd5D3f65d`.
 
-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.
+You may choose to use the [`--strictFeeRecipientCheck`](./validator-cli.md#--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 beacon node with connected builder relays, you may use these validator configurations to signal which block (builder vs. local execution) the beacon node should produce.
 
-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 (&gt;100) or dampen (&lt;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 requested and applied on the beacon node itself. For more information, see the [produceBlockV3 Beacon API](https://ethereum.github.io/beacon-APIs/#/ValidatorRequiredApi/produceBlockV3).
+With produceBlockV3 (enabled automatically after the Deneb hard fork), the [`--builder.boostFactor`](./validator-cli.md#--builderboostfactor) is a percentage multiplier the block producing beacon node must apply to boost (&gt;100) or dampen (&lt;100) builder block value for selection against execution block. The multiplier is ignored if [`--builder.selection`](./validator-cli.md#--builderselection) is set to anything other than `maxprofit`. Even though this is set on the validator client, the calculation is requested and applied on the beacon node itself. For more information, see the [produceBlockV3 Beacon API](https://ethereum.github.io/beacon-APIs/#/ValidatorRequiredApi/produceBlockV3).
 
-With Lodestar's `--builder.selection` validator options, you can select:
+With Lodestar's [`--builder.selection`](./validator-cli.md#--builderselection) validator options, you can select:
 
 - `default`: Default setting for Lodestar set at `--builder.boostFactor=90`. This default setting will have a local block boost of ~10%. Note that this value might change in the future depending on what we think is the most appropriate value to help improve censorship resistance of Ethereum.
 - `maxprofit`: An alias of `--builder.boostFactor=100`, which 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.
@@ -91,7 +91,7 @@ With Lodestar's `--builder.selection` validator options, you can select:
 
 #### Calculating builder boost factor with examples
 
-To calculate the builder boost factor setting, you need to know what percentage you will accept a builder block for against a local execution block using the following formula: `100*100/(100+percentage)`. The value passed to `--builder.boostFactor` must be a valid number without decimals.
+To calculate the builder boost factor setting, you need to know what percentage you will accept a builder block for against a local execution block using the following formula: `100*100/(100+percentage)`. The value passed to [`--builder.boostFactor`](./validator-cli.md#--builderboostfactor) must be a valid number without decimals.
 
 Example 1: I will only accept a builder block with 25% more value than the local execution block.