Some updates to Lighthouse book (#6995)

* #6447


  - Move some deprecated pages to a new section under `Archived`

- Remove fallback log in mev as the log will not be present after VC using `/eth/v3/validator/blocks` endpoint by default
- Add warning against using Btrfs file system (thank you @ChosunOne for the report)
- Add data shared by @mcdee  on tree states API queries time
- Rename partial withdrawals to validator sweep to differentiate it from the upcoming execution layer partial withdrawals
- Update NAT API response
- Update docs on IPv6

- Rename .md files to follow a standard prefix section name, e.g., installation_*.md, advanced_*.md
- Standardise .md files using underscore `_` instead of hyphen `-` to be consistent with other files naming conventions.

book/.markdownlint.yml

@@ -8,7 +8,7 @@ MD010:
 MD013: false
 
 # MD028: set to false to allow blank line between blockquote: https://github.com/DavidAnson/markdownlint/blob/main/doc/md028.md
-# This is because the blockquotes are shown separatedly (a deisred outcome) when having a blank line in between
+# This is because the blockquotes are shown separately (a desired outcome) when having a blank line in between
 MD028: false
 
 # MD024: set siblings_only to true so that same headings with different parent headings are allowed

book/src/SUMMARY.md

@@ -2,58 +2,54 @@
 
 * [Introduction](./intro.md)
 * [Installation](./installation.md)
-  * [Pre-Built Binaries](./installation-binaries.md)
+  * [Pre-Built Binaries](./installation_binaries.md)
-  * [Docker](./docker.md)
+  * [Docker](./installation_docker.md)
-  * [Build from Source](./installation-source.md)
+  * [Build from Source](./installation_source.md)
-  * [Raspberry Pi 4](./pi.md)
+  * [Cross-Compiling](./installation_cross_compiling.md)
-  * [Cross-Compiling](./cross-compiling.md)
+  * [Homebrew](./installation_homebrew.md)
-  * [Homebrew](./homebrew.md)
+  * [Update Priorities](./installation_priorities.md)
-  * [Update Priorities](./installation-priorities.md)
 * [Run a Node](./run_a_node.md)
-* [Become a Validator](./mainnet-validator.md)
+* [Become a Validator](./mainnet_validator.md)
-* [Validator Management](./validator-management.md)
+* [Validator Management](./validator_management.md)
-  * [The `validator-manager` Command](./validator-manager.md)
+  * [The `validator-manager` Command](./validator_manager.md)
-    * [Creating validators](./validator-manager-create.md)
+    * [Creating validators](./validator_manager_create.md)
-    * [Moving validators](./validator-manager-move.md)
+    * [Moving validators](./validator_manager_move.md)
-    * [Managing validators](./validator-manager-api.md)
+    * [Managing validators](./validator_manager_api.md)
-  * [Slashing Protection](./slashing-protection.md)
+  * [Slashing Protection](./validator_slashing_protection.md)
-  * [Voluntary Exits](./voluntary-exit.md)
+  * [Voluntary Exits](./validator_voluntary_exit.md)
-  * [Partial Withdrawals](./partial-withdrawal.md)
+  * [Validator Sweep](./validator_sweep.md)
-  * [Validator Monitoring](./validator-monitoring.md)
+  * [Validator Monitoring](./validator_monitoring.md)
-  * [Doppelganger Protection](./validator-doppelganger.md)
+  * [Doppelganger Protection](./validator_doppelganger.md)
-  * [Suggested Fee Recipient](./suggested-fee-recipient.md)
+  * [Suggested Fee Recipient](./validator_fee_recipient.md)
-  * [Validator Graffiti](./graffiti.md)
+  * [Validator Graffiti](./validator_graffiti.md)
 * [APIs](./api.md)
-  * [Beacon Node API](./api-bn.md)
+  * [Beacon Node API](./api_bn.md)
-    * [Lighthouse API](./api-lighthouse.md)
+    * [Lighthouse API](./api_lighthouse.md)
-    * [Validator Inclusion APIs](./validator-inclusion.md)
+    * [Validator Inclusion APIs](./api_validator_inclusion.md)
-  * [Validator Client API](./api-vc.md)
+  * [Validator Client API](./api_vc.md)
-    * [Endpoints](./api-vc-endpoints.md)
+    * [Endpoints](./api_vc_endpoints.md)
-    * [Authorization Header](./api-vc-auth-header.md)
+    * [Authorization Header](./api_vc_auth_header.md)
-    * [Signature Header](./api-vc-sig-header.md)
+  * [Prometheus Metrics](./api_metrics.md)
-  * [Prometheus Metrics](./advanced_metrics.md)
+* [Lighthouse UI (Siren)](./ui.md)
-* [Lighthouse UI (Siren)](./lighthouse-ui.md)
+  * [Configuration](./ui_configuration.md)
-  * [Configuration](./ui-configuration.md)
+  * [Authentication](./ui_authentication.md)
-  * [Authentication](./ui-authentication.md)
+  * [Usage](./ui_usage.md)
-  * [Usage](./ui-usage.md)
+  * [FAQs](./ui_faqs.md)
-  * [FAQs](./ui-faqs.md)
 * [Advanced Usage](./advanced.md)
-  * [Checkpoint Sync](./checkpoint-sync.md)
+  * [Checkpoint Sync](./advanced_checkpoint_sync.md)
-  * [Custom Data Directories](./advanced-datadir.md)
+  * [Custom Data Directories](./advanced_datadir.md)
-  * [Proposer Only Beacon Nodes](./advanced-proposer-only.md)
+  * [Proposer Only Beacon Nodes](./advanced_proposer_only.md)
-  * [Remote Signing with Web3Signer](./validator-web3signer.md)
+  * [Remote Signing with Web3Signer](./advanced_web3signer.md)
   * [Database Configuration](./advanced_database.md)
-  * [Database Migrations](./database-migrations.md)
+  * [Database Migrations](./advanced_database_migrations.md)
-  * [Key Management (Deprecated)](./key-management.md)
+  * [Key Recovery](./advanced_key_recovery.md)
-  * [Key Recovery](./key-recovery.md)
   * [Advanced Networking](./advanced_networking.md)
-  * [Running a Slasher](./slasher.md)
+  * [Running a Slasher](./advanced_slasher.md)
-  * [Redundancy](./redundancy.md)
+  * [Redundancy](./advanced_redundancy.md)
-  * [Release Candidates](./advanced-release-candidates.md)
+  * [Release Candidates](./advanced_release_candidates.md)
-  * [MEV](./builders.md)
+  * [MEV](./advanced_builders.md)
-  * [Merge Migration](./merge-migration.md)
+  * [Late Block Re-orgs](./advanced_re-orgs.md)
-  * [Late Block Re-orgs](./late-block-re-orgs.md)
+  * [Blobs](./advanced_blobs.md)
-  * [Blobs](./advanced-blobs.md)
 * [Command Line Reference (CLI)](./help_general.md)
   * [Beacon Node](./help_bn.md)
   * [Validator Client](./help_vc.md)
@@ -62,7 +58,11 @@
     * [Import](./help_vm_import.md)
     * [Move](./help_vm_move.md)
 * [Contributing](./contributing.md)
-  * [Development Environment](./setup.md)
+  * [Development Environment](./contributing_setup.md)
 * [FAQs](./faq.md)
 * [Protocol Developers](./developers.md)
 * [Security Researchers](./security.md)
+* [Archived](./archived.md)
+  * [Merge Migration](./archived_merge_migration.md)
+  * [Raspberry Pi 4](./archived_pi.md)
+  * [Key Management](./archived_key_management.md)

book/src/advanced.md

@@ -6,19 +6,17 @@ elsewhere?
 This section provides detailed information about configuring Lighthouse for specific use cases, and
 tips about how things work under the hood.
 
-* [Checkpoint Sync](./checkpoint-sync.md): quickly sync the beacon chain to perform validator duties.
+* [Checkpoint Sync](./advanced_checkpoint_sync.md): quickly sync the beacon chain to perform validator duties.
-* [Custom Data Directories](./advanced-datadir.md): modify the data directory to your preferred location.
+* [Custom Data Directories](./advanced_datadir.md): modify the data directory to your preferred location.
-* [Proposer Only Beacon Nodes](./advanced-proposer-only.md): beacon node only for proposer duty for increased anonymity.
+* [Proposer Only Beacon Nodes](./advanced_proposer_only.md): beacon node only for proposer duty for increased anonymity.
-* [Remote Signing with Web3Signer](./validator-web3signer.md): don't want to store your keystore in local node? Use web3signer.
+* [Remote Signing with Web3Signer](./advanced_web3signer.md): don't want to store your keystore in local node? Use web3signer.
 * [Database Configuration](./advanced_database.md): understanding space-time trade-offs in the database.
-* [Database Migrations](./database-migrations.md): have a look at all previous Lighthouse database scheme versions.
+* [Database Migrations](./advanced_database_migrations.md): have a look at all previous Lighthouse database scheme versions.
-* [Key Management](./key-management.md): explore how to generate wallet with Lighthouse.
+* [Key Recovery](./advanced_key_recovery.md): explore how to recover wallet and validator with Lighthouse.
-* [Key Recovery](./key-recovery.md): explore how to recover wallet and validator with Lighthouse.
 * [Advanced Networking](./advanced_networking.md): open your ports to have a diverse and healthy set of peers.
-* [Running a Slasher](./slasher.md): contribute to the health of the network by running a slasher.
+* [Running a Slasher](./advanced_slasher.md): contribute to the health of the network by running a slasher.
-* [Redundancy](./redundancy.md): want to have more than one beacon node as backup? This is for you.
+* [Redundancy](./advanced_redundancy.md): want to have more than one beacon node as backup? This is for you.
-* [Release Candidates](./advanced-release-candidates.md): latest release of Lighthouse to get feedback from users.
+* [Release Candidates](./advanced_release_candidates.md): latest release of Lighthouse to get feedback from users.
-* [Maximal Extractable Value](./builders.md): use external builders for a potential higher rewards during block proposals
+* [Maximal Extractable Value](./advanced_builders.md): use external builders for a potential higher rewards during block proposals
-* [Merge Migration](./merge-migration.md): look at what you need to do during a significant network upgrade: The Merge
+* [Late Block Re-orgs](./advanced_re-orgs.md): read information about Lighthouse late block re-orgs.
-* [Late Block Re-orgs](./late-block-re-orgs.md): read information about Lighthouse late block re-orgs.
+* [Blobs](./advanced_blobs.md): information about blobs in Deneb upgrade
-* [Blobs](./advanced-blobs.md): information about blobs in Deneb upgrade

book/src/advanced_blobs.md

@@ -38,4 +38,4 @@ In the Deneb network upgrade, one of the changes is the implementation of EIP-48
    curl "http://localhost:5052/lighthouse/database/info" | jq
    ```
 
-   Refer to [Lighthouse API](./api-lighthouse.md#lighthousedatabaseinfo) for an example response.
+   Refer to [Lighthouse API](./api_lighthouse.md#lighthousedatabaseinfo) for an example response.

book/src/advanced_builders.md

@@ -83,11 +83,11 @@ is something afoot.
 
 To update gas limit per-validator you can use the [standard key manager API][gas-limit-api].
 
-Alternatively, you can use the [lighthouse API](api-vc-endpoints.md). See below for an example.
+Alternatively, you can use the [lighthouse API](api_vc_endpoints.md). See below for an example.
 
 ### Enable/Disable builder proposals via HTTP
 
-Use the [lighthouse API](api-vc-endpoints.md) to enable/disable use of the builder API on a per-validator basis.
+Use the [lighthouse API](api_vc_endpoints.md) to enable/disable use of the builder API on a per-validator basis.
 You can also update the configured gas limit with these requests.
 
 #### `PATCH /lighthouse/validators/:voting_pubkey`
@@ -98,7 +98,7 @@ You can also update the configured gas limit with these requests.
 |-------------------|--------------------------------------------|
 | Path              | `/lighthouse/validators/:voting_pubkey`    |
 | Method            | PATCH                                      |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 200, 400                                   |
 
 #### Example Path
@@ -147,7 +147,7 @@ INFO Published validator registrations to the builder network, count: 3, service
 
 ### Fee Recipient
 
-Refer to [suggested fee recipient](suggested-fee-recipient.md) documentation.
+Refer to [suggested fee recipient](validator_fee_recipient.md) documentation.
 
 ### Validator definitions example
 
@@ -244,16 +244,9 @@ INFO Builder payload ignored
 INFO Chain is unhealthy, using local payload
 ```
 
-In case of fallback you should see a log indicating that the locally produced payload was
-used in place of one from the builder:
-
-```text
-INFO Reconstructing a full block using a local payload
-```
-
 ## Information for block builders and relays
 
-Block builders and relays can query beacon node events from the [Events API](https://ethereum.github.io/beacon-APIs/#/Events/eventstream). An example of querying the payload attributes in the Events API is outlined in [Beacon node API - Events API](./api-bn.md#events-api)
+Block builders and relays can query beacon node events from the [Events API](https://ethereum.github.io/beacon-APIs/#/Events/eventstream). An example of querying the payload attributes in the Events API is outlined in [Beacon node API - Events API](./api_bn.md#events-api)
 
 [mev-rs]: https://github.com/ralexstokes/mev-rs
 [mev-boost]: https://github.com/flashbots/mev-boost

book/src/advanced_checkpoint_sync.md

@@ -134,7 +134,7 @@ Important information to be aware of:
 * It is safe to interrupt state reconstruction by gracefully terminating the node – it will pick up
   from where it left off when it restarts.
 * You can start reconstruction from the HTTP API, and view its progress. See the
-  [`/lighthouse/database`](./api-lighthouse.md) APIs.
+  [`/lighthouse/database`](./api_lighthouse.md) APIs.
 
 For more information on historic state storage see the
 [Database Configuration](./advanced_database.md) page.

book/src/advanced_database.md

@@ -61,6 +61,26 @@ that we have observed are:
   to apply. We observed no significant performance benefit from `--hierarchy-exponents 5,7,11`, and
   a substantial increase in space consumed.
 
+The following table lists the data for different configurations. Note that the disk space requirement is for the `chain_db` and `freezer_db`, excluding the `blobs_db`.
+
+| Hierarchy Exponents | Storage Requirement | Sequential Slot Query | Uncached Query | Time to Sync |
+|---|---|---|---|---|
+| 5,9,11,13,16,18,21 (default) | 418 GiB | 250-700 ms | up to 10 s | 1 week |
+| 5,7,11 (frequent snapshots) | 589 GiB | 250-700 ms | up to 6 s | 1 week |
+| 0,5,7,11 (per-slot diffs) | 2500 GiB | 250-700 ms | up to 4 s | 7 weeks |
+
+[Jim](https://github.com/mcdee) has done some experiments to study the response time of querying random slots (uncached query) for `--hierarchy-exponents 0,5,7,11` (per-slot diffs) and `--hierarchy-exponents 5,9,11,13,17,21` (per-epoch diffs), as show in the figures below. From the figures, two points can be concluded:
+
+- response time (y-axis) increases with slot number (x-axis) due to state growth.
+- response time for per-slot configuration in general is 2x faster than that of per-epoch.
+
+In short, setting different configurations is a trade-off between disk space requirement, sync time and response time. The data presented here is useful to help users choosing the configuration that suit their needs.
+
+_We acknowledge the data provided by [Jim](https://github.com/mcdee) and his consent for us to share it here._
+
+![Response time for per-epoch archive](./imgs/per-epoch.png)
+![Response time for per-slot archive](./imgs/per-slot.png)
+
 If in doubt, we recommend running with the default configuration! It takes a long time to
 reconstruct states in any given configuration, so it might be some time before the optimal
 configuration is determined.

book/src/advanced_datadir.md

@@ -12,7 +12,7 @@ lighthouse --network mainnet --datadir /var/lib/my-custom-dir bn --staking
 lighthouse --network mainnet --datadir /var/lib/my-custom-dir vc
 ```
 
-The first step creates a `validators` directory under `/var/lib/my-custom-dir` which contains the imported keys and [`validator_definitions.yml`](./validator-management.md).
+The first step creates a `validators` directory under `/var/lib/my-custom-dir` which contains the imported keys and [`validator_definitions.yml`](./validator_management.md).
 After that, we simply run the beacon chain and validator client with the custom dir path.
 
 ## Relative Paths

book/src/advanced_networking.md

@@ -123,8 +123,12 @@ Lighthouse listens for connections, and the parameters used to tell other peers
 how to connect to your node. This distinction is relevant and applies to most
 nodes that do not run directly on a public network.
 
+Since Lighthouse v7.0.0, Lighthouse listens to both IPv4 and IPv6 by default if it detects a globally routable IPv6 address. This means that dual-stack is enabled by default.
+
 ### Configuring Lighthouse to listen over IPv4/IPv6/Dual stack
 
+To listen over only IPv4 and not IPv6, use the flag `--listen-address 0.0.0.0`.
+
 To listen over only IPv6 use the same parameters as done when listening over
 IPv4 only:
 
@@ -136,7 +140,7 @@ TCP and UDP.
   If the specified port is 9909, QUIC will use port 9910 for IPv6 UDP connections.
   This can be configured with `--quic-port`.
 
-To listen over both IPv4 and IPv6:
+To listen over both IPv4 and IPv6 and using a different port for IPv6::
 
 - Set two listening addresses using the `--listen-address` flag twice ensuring
   the two addresses are one IPv4, and the other IPv6. When doing so, the
@@ -165,7 +169,7 @@ To listen over both IPv4 and IPv6:
 > It listens on the default value of --port6 (`9000`) for both UDP and TCP.
 > QUIC will use port `9001` for UDP, which is the default `--port6` value (`9000`) + 1.
 
-> When using `--listen-address :: --listen-address --port 9909 --discovery-port6 9999`, listening will be set up as follows:
+> When using `--listen-address :: --listen-address 0.0.0.0 --port 9909 --discovery-port6 9999`, listening will be set up as follows:
 >
 > **IPv4**:
 >

book/src/advanced_proposer_only.md

@@ -56,7 +56,7 @@ these nodes for added security).
 
 The intended set-up to take advantage of this mechanism is to run one (or more)
 normal beacon nodes in conjunction with one (or more) proposer-only beacon
-nodes. See the [Redundancy](./redundancy.md) section for more information about
+nodes. See the [Redundancy](./advanced_redundancy.md) section for more information about
 setting up redundant beacon nodes. The proposer-only beacon nodes should be
 setup to use a different IP address than the primary (non proposer-only) nodes.
 For added security, the IP addresses of the proposer-only nodes should be

book/src/advanced_redundancy.md

@@ -9,7 +9,7 @@ There are three places in Lighthouse where redundancy is notable:
 We mention (3) since it is unsafe and should not be confused with the other two
 uses of redundancy. **Running the same validator keypair in more than one
 validator client (Lighthouse, or otherwise) will eventually lead to slashing.**
-See [Slashing Protection](./slashing-protection.md) for more information.
+See [Slashing Protection](./validator_slashing_protection.md) for more information.
 
 From this paragraph, this document will *only* refer to the first two items (1, 2). We
 *never* recommend that users implement redundancy for validator keypairs.
@@ -58,8 +58,8 @@ following flags:
 
  > Note: You could also use `--http-address 0.0.0.0`, but this allows *any* external IP address to access the HTTP server. As such, a firewall should be configured to deny unauthorized access to port `5052`.
 
-- `--execution-endpoint`: see [Merge Migration](./merge-migration.md).
+- `--execution-endpoint`: see [Merge Migration](./archived_merge_migration.md).
-- `--execution-jwt`: see [Merge Migration](./merge-migration.md).
+- `--execution-jwt`: see [Merge Migration](./archived_merge_migration.md).
 
 For example one could use the following command to provide a backup beacon node:
 
@@ -107,7 +107,7 @@ The default is `--broadcast subscriptions`. To also broadcast blocks for example
 Lighthouse previously supported redundant execution nodes for fetching data from the deposit
 contract. On merged networks *this is no longer supported*. Each Lighthouse beacon node must be
 configured in a 1:1 relationship with an execution node. For more information on the rationale
-behind this decision please see the [Merge Migration](./merge-migration.md) documentation.
+behind this decision please see the [Merge Migration](./archived_merge_migration.md) documentation.
 
 To achieve redundancy we recommend configuring [Redundant beacon nodes](#redundant-beacon-nodes)
 where each has its own execution engine.

book/src/advanced_slasher.md

@@ -81,7 +81,7 @@ WARN Slasher backend override failed    advice: delete old MDBX database or enab
 
 In this case you should either obtain a Lighthouse binary with the MDBX backend enabled, or delete
 the files for the old backend. The pre-built Lighthouse binaries and Docker images have MDBX enabled,
-or if you're [building from source](./installation-source.md) you can enable the `slasher-mdbx` feature.
+or if you're [building from source](./installation_source.md) you can enable the `slasher-mdbx` feature.
 
 To delete the files, use the `path` from the `WARN` log, and then delete the `mbdx.dat` and
 `mdbx.lck` files.

book/src/advanced_web3signer.md

@@ -30,7 +30,7 @@ or effectiveness.
 ## Usage
 
 A remote signing validator is added to Lighthouse in much the same way as one that uses a local
-keystore, via the [`validator_definitions.yml`](./validator-management.md) file or via the [`POST /lighthouse/validators/web3signer`](./api-vc-endpoints.md#post-lighthousevalidatorsweb3signer) API endpoint.
+keystore, via the [`validator_definitions.yml`](./validator_management.md) file or via the [`POST /lighthouse/validators/web3signer`](./api_vc_endpoints.md#post-lighthousevalidatorsweb3signer) API endpoint.
 
 Here is an example of a `validator_definitions.yml` file containing one validator which uses a
 remote signer:

book/src/api.md

@@ -5,5 +5,5 @@ RESTful HTTP/JSON APIs.
 
 There are two APIs served by Lighthouse:
 
-- [Beacon Node API](./api-bn.md)
+- [Beacon Node API](./api_bn.md)
-- [Validator Client API](./api-vc.md)
+- [Validator Client API](./api_vc.md)

book/src/api_lighthouse.md

@@ -347,11 +347,11 @@ curl -X GET "http://localhost:5052/lighthouse/proto_array" -H  "accept: applicat
 
 ## `/lighthouse/validator_inclusion/{epoch}/{validator_id}`
 
-See [Validator Inclusion APIs](./validator-inclusion.md).
+See [Validator Inclusion APIs](./api_validator_inclusion.md).
 
 ## `/lighthouse/validator_inclusion/{epoch}/global`
 
-See [Validator Inclusion APIs](./validator-inclusion.md).
+See [Validator Inclusion APIs](./api_validator_inclusion.md).
 
 ## `/lighthouse/eth1/syncing`
 
@@ -565,7 +565,7 @@ For archive nodes, the `anchor` will be:
 
 indicating that all states with slots `>= 0` are available, i.e., full state history. For more information
 on the specific meanings of these fields see the docs on [Checkpoint
-Sync](./checkpoint-sync.md#reconstructing-states).
+Sync](./advanced_checkpoint_sync.md#reconstructing-states).
 
 ## `/lighthouse/merge_readiness`
 
@@ -812,9 +812,15 @@ Checks if the ports are open.
 curl -X GET "http://localhost:5052/lighthouse/nat" | jq
 ```
 
-An open port will return:
+An example of response:
 
 ```json
 {
-  "data": true
+  "data": {
+    "discv5_ipv4": true,
+    "discv5_ipv6": false,
+    "libp2p_ipv4": true,
+    "libp2p_ipv6": false
+  }
 }
+```

book/src/api_metrics.md

@@ -68,7 +68,7 @@ The specification for the monitoring endpoint can be found here:
 
 - <https://github.com/gobitfly/eth2-client-metrics>
 
-_Note: the similarly named [Validator Monitor](./validator-monitoring.md) feature is entirely
+_Note: the similarly named [Validator Monitor](./validator_monitoring.md) feature is entirely
 independent of remote metric monitoring_.
 
 ### Update Period

book/src/api_vc.md

@@ -6,11 +6,10 @@ of validators and keys.
 The API includes all of the endpoints from the [standard keymanager
 API](https://ethereum.github.io/keymanager-APIs/) that is implemented by other clients and remote
 signers. It also includes some Lighthouse-specific endpoints which are described in
-[Endpoints](./api-vc-endpoints.md).
+[Endpoints](./api_vc_endpoints.md).
 
 > Note: All requests to the HTTP server must supply an
-> [`Authorization`](./api-vc-auth-header.md) header. All responses contain a
+> [`Authorization`](./api_vc_auth_header.md) header.
-> [`Signature`](./api-vc-sig-header.md) header for optional verification.
 
 ## Starting the server
 

book/src/api_vc_endpoints.md

@@ -19,7 +19,7 @@
 | [`POST /lighthouse/validators/web3signer`](#post-lighthousevalidatorsweb3signer) | Add web3signer validators. |
 | [`GET /lighthouse/logs`](#get-lighthouselogs) | Get logs |
 
-The query to Lighthouse API endpoints requires authorization, see [Authorization Header](./api-vc-auth-header.md).
+The query to Lighthouse API endpoints requires authorization, see [Authorization Header](./api_vc_auth_header.md).
 
 In addition to the above endpoints Lighthouse also supports all of the [standard keymanager APIs](https://ethereum.github.io/keymanager-APIs/).
 
@@ -33,7 +33,7 @@ Returns the software version and `git` commit hash for the Lighthouse binary.
 |-------------------|--------------------------------------------|
 | Path              | `/lighthouse/version`                      |
 | Method            | GET                                        |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 200                                        |
 
 Command:
@@ -71,7 +71,7 @@ Returns information regarding the health of the host machine.
 |-------------------|--------------------------------------------|
 | Path              | `/lighthouse/health`                       |
 | Method            | GET                                        |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 200                                        |
 
 *Note: this endpoint is presently only available on Linux.*
@@ -132,7 +132,7 @@ Returns information regarding the health of the host machine.
 |-------------------|--------------------------------------------|
 | Path              | `/lighthouse/ui/health`                       |
 | Method            | GET                                        |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 200                                        |
 
 Command:
@@ -178,7 +178,7 @@ Returns the graffiti that will be used for the next block proposal of each valid
 |-------------------|--------------------------------------------|
 | Path              | `/lighthouse/ui/graffiti`                    |
 | Method            | GET                                        |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 200                                        |
 
 Command:
@@ -210,7 +210,7 @@ Returns the Ethereum proof-of-stake consensus specification loaded for this vali
 |-------------------|--------------------------------------------|
 | Path              | `/lighthouse/spec`                         |
 | Method            | GET                                        |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 200                                        |
 
 Command:
@@ -326,7 +326,7 @@ Example Response Body
 
 ## `GET /lighthouse/auth`
 
-Fetch the filesystem path of the [authorization token](./api-vc-auth-header.md).
+Fetch the filesystem path of the [authorization token](./api_vc_auth_header.md).
 Unlike the other endpoints this may be called *without* providing an authorization token.
 
 This API is intended to be called from the same machine as the validator client, so that the token
@@ -365,7 +365,7 @@ Lists all validators managed by this validator client.
 |-------------------|--------------------------------------------|
 | Path              | `/lighthouse/validators`                   |
 | Method            | GET                                        |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 200                                        |
 
 Command:
@@ -409,7 +409,7 @@ Get a validator by their `voting_pubkey`.
 |-------------------|--------------------------------------------|
 | Path              | `/lighthouse/validators/:voting_pubkey`    |
 | Method            | GET                                        |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 200, 400                                   |
 
 Command:
@@ -441,7 +441,7 @@ and `graffiti`.  The following example updates a validator from `enabled: true`
 |-------------------|--------------------------------------------|
 | Path              | `/lighthouse/validators/:voting_pubkey`    |
 | Method            | PATCH                                      |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 200, 400                                   |
 
 Example Request Body
@@ -491,7 +491,7 @@ Validators are generated from the mnemonic according to
 |-------------------|--------------------------------------------|
 | Path              | `/lighthouse/validators`                   |
 | Method            | POST                                       |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 200                                        |
 
 ### Example Request Body
@@ -580,7 +580,7 @@ Import a keystore into the validator client.
 |-------------------|--------------------------------------------|
 | Path              | `/lighthouse/validators/keystore`          |
 | Method            | POST                                       |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 200                                        |
 
 ### Example Request Body
@@ -676,7 +676,7 @@ generated with the path `m/12381/3600/i/42`.
 |-------------------|--------------------------------------------|
 | Path              | `/lighthouse/validators/mnemonic`          |
 | Method            | POST                                       |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 200                                        |
 
 ### Example Request Body
@@ -739,7 +739,7 @@ Create any number of new validators, all of which will refer to a
 |-------------------|--------------------------------------------|
 | Path              | `/lighthouse/validators/web3signer`        |
 | Method            | POST                                       |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 200, 400                                   |
 
 ### Example Request Body

book/src/archived-key-management.md

@@ -1,4 +1,4 @@
-# Key Management (Deprecated)
+# Key Management
 
 [launchpad]: https://launchpad.ethereum.org/
 
@@ -22,7 +22,7 @@ Rather than continuing to read this page, we recommend users visit either:
 
 - The [Staking Launchpad][launchpad] for detailed, beginner-friendly instructions.
 - The [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli) for a CLI tool used by the [Staking Launchpad][launchpad].
-- The [validator-manager documentation](./validator-manager.md) for a Lighthouse-specific tool for streamlined validator management tools.
+- The [validator-manager documentation](./validator_manager.md) for a Lighthouse-specific tool for streamlined validator management tools.
 
 ## The `lighthouse account-manager`
 

book/src/archived-merge-migration.md

@@ -14,7 +14,7 @@ the merge:
 2. If your Lighthouse node has validators attached you *must* nominate an Ethereum address to
    receive transactions tips from blocks proposed by your validators. These changes should
    be made to your `lighthouse vc` configuration, and are covered on the
-   [Suggested fee recipient](./suggested-fee-recipient.md) page.
+   [Suggested fee recipient](./validator_fee_recipient.md) page.
 
 Additionally, you *must* update Lighthouse to v3.0.0 (or later), and must update your execution
 engine to a merge-ready version.

book/src/archived.md

@@ -0,0 +1,3 @@
+# Archived
+
+This section keeps the topics that are deprecated or less applicable for archived purposes.

book/src/archived_pi.md

@@ -7,7 +7,7 @@ Tested on:
 - Raspberry Pi 4 Model B (4GB)
 - `Ubuntu 20.04 LTS (GNU/Linux 5.4.0-1011-raspi aarch64)`
 
-*Note: [Lighthouse supports cross-compiling](./cross-compiling.md) to target a
+*Note: [Lighthouse supports cross-compiling](./installation_cross_compiling.md) to target a
 Raspberry Pi (`aarch64`). Compiling on a faster machine (i.e., `x86_64`
 desktop) may be convenient.*
 
@@ -58,7 +58,7 @@ make
 >
 > Compiling Lighthouse can take up to an hour. The safety guarantees provided by the Rust language
 unfortunately result in a lengthy compilation time on a low-spec CPU like a Raspberry Pi. For faster
-compilation on low-spec hardware, try [cross-compiling](./cross-compiling.md) on a more powerful
+compilation on low-spec hardware, try [cross-compiling](./installation_cross_compiling.md) on a more powerful
 computer (e.g., compile for RasPi from your desktop computer).
 
 Once installation has finished, confirm Lighthouse is installed by viewing the

book/src/contributing.md

@@ -15,7 +15,7 @@ to work on.
 To start contributing,
 
 1. Read our [how to contribute](https://github.com/sigp/lighthouse/blob/unstable/CONTRIBUTING.md) document.
-2. Setup a [development environment](./setup.md).
+2. Setup a [development environment](./contributing_setup.md).
 3. Browse through the [open issues](https://github.com/sigp/lighthouse/issues)
    (tip: look for the [good first
    issue](https://github.com/sigp/lighthouse/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
@@ -127,5 +127,5 @@ suggest:
 - [Rust by example](https://doc.rust-lang.org/stable/rust-by-example/)
 - [Learning Rust With Entirely Too Many Linked Lists](http://cglab.ca/~abeinges/blah/too-many-lists/book/)
 - [Rustlings](https://github.com/rustlings/rustlings)
-- [Rust Exercism](https://exercism.io/tracks/rust)
+- [Rust Exercism](https://exercism.org/tracks/rust)
 - [Learn X in Y minutes - Rust](https://learnxinyminutes.com/docs/rust/)

book/src/faq.md

@@ -146,7 +146,7 @@ An example of the full log is shown below:
 WARN BlockProcessingFailure                  outcome: MissingBeaconBlock(0xbdba211f8d72029554e405d8e4906690dca807d1d7b1bc8c9b88d7970f1648bc), msg: unexpected condition in processing block.
 ```
 
-`MissingBeaconBlock` suggests that the database has corrupted. You should wipe the database and use [Checkpoint Sync](./checkpoint-sync.md) to resync the beacon chain.
+`MissingBeaconBlock` suggests that the database has corrupted. You should wipe the database and use [Checkpoint Sync](./advanced_checkpoint_sync.md) to resync the beacon chain.
 
 ### <a name="bn-download-slow"></a> After checkpoint sync, the progress of `downloading historical blocks` is slow. Why?
 
@@ -281,7 +281,7 @@ You should **never** use duplicate/redundant validator keypairs or validator cli
 duplicate your JSON keystores and don't run `lighthouse vc` twice). This will lead to slashing.
 
 However, there are some components which can be configured with redundancy. See the
-[Redundancy](./redundancy.md) guide for more information.
+[Redundancy](./advanced_redundancy.md) guide for more information.
 
 ### <a name="vc-missed-attestations"></a> I am missing attestations. Why?
 
@@ -323,7 +323,7 @@ Another possible reason for missing the head vote is due to a chain "reorg". A r
 
 ### <a name="vc-exit"></a> Can I submit a voluntary exit message without running a beacon node?
 
-Yes. Beaconcha.in provides the tool to broadcast the message. You can create the voluntary exit message file with [ethdo](https://github.com/wealdtech/ethdo/releases/tag/v1.30.0) and submit the message via the [beaconcha.in](https://beaconcha.in/tools/broadcast) website. A guide on how to use `ethdo` to perform voluntary exit can be found [here](https://github.com/eth-educators/ethstaker-guides/blob/main/voluntary-exit.md).
+Yes. Beaconcha.in provides the tool to broadcast the message. You can create the voluntary exit message file with [ethdo](https://github.com/wealdtech/ethdo/releases/tag/v1.30.0) and submit the message via the [beaconcha.in](https://beaconcha.in/tools/broadcast) website. A guide on how to use `ethdo` to perform voluntary exit can be found [here](https://github.com/eth-educators/ethstaker-guides/blob/main/docs/voluntary-exit.md).
 
 It is also noted that you can submit your BLS-to-execution-change message to update your withdrawal credentials from type `0x00` to `0x01` using the same link.
 
@@ -341,13 +341,13 @@ No. You can just import new validator keys to the destination directory. If the
 
 Generally yes.
 
-If you do not want to stop `lighthouse vc`, you can use the [key manager API](./api-vc-endpoints.md) to import keys.
+If you do not want to stop `lighthouse vc`, you can use the [key manager API](./api_vc_endpoints.md) to import keys.
 
 ### <a name="vc-delete"></a> How can I delete my validator once it is imported?
 
 Lighthouse supports the [KeyManager API](https://ethereum.github.io/keymanager-APIs/#/Local%20Key%20Manager/deleteKeys) to delete validators and remove them from the `validator_definitions.yml` file. To do so, start the validator client with the flag `--http` and call the API.
 
-If you are looking to delete the validators in one node and import it to another, you can use the [validator-manager](./validator-manager-move.md) to move the validators across nodes without the hassle of deleting and importing the keys.
+If you are looking to delete the validators in one node and import it to another, you can use the [validator-manager](./validator_manager_move.md) to move the validators across nodes without the hassle of deleting and importing the keys.
 
 ## Network, Monitoring and Maintenance
 
@@ -389,9 +389,9 @@ expect, there are a few things to check on:
 
 ### <a name="net-update"></a> How do I update lighthouse?
 
-If you are updating to new release binaries, it will be the same process as described [here.](./installation-binaries.md)
+If you are updating to new release binaries, it will be the same process as described [here.](./installation_binaries.md)
 
-If you are updating by rebuilding from source, see [here.](./installation-source.md#update-lighthouse)
+If you are updating by rebuilding from source, see [here.](./installation_source.md#update-lighthouse)
 
 If you are running the docker image provided by Sigma Prime on Dockerhub, you can update to specific versions, for example:
 
@@ -399,7 +399,7 @@ If you are running the docker image provided by Sigma Prime on Dockerhub, you ca
 docker pull sigp/lighthouse:v1.0.0
 ```
 
-If you are building a docker image, the process will be similar to the one described [here.](./docker.md#building-the-docker-image)
+If you are building a docker image, the process will be similar to the one described [here.](./installation_docker.md#building-the-docker-image)
 You just need to make sure the code you have checked out is up to date.
 
 ### <a name="net-port-forwarding"></a> Do I need to set up any port mappings (port forwarding)?
@@ -436,7 +436,7 @@ Opening these ports will make your Lighthouse node maximally contactable.
 
 Apart from using block explorers, you may use the "Validator Monitor" built into Lighthouse which
 provides logging and Prometheus/Grafana metrics for individual validators. See [Validator
-Monitoring](./validator-monitoring.md) for more information. Lighthouse has also developed Lighthouse UI (Siren) to monitor performance, see [Lighthouse UI (Siren)](./lighthouse-ui.md).
+Monitoring](./validator_monitoring.md) for more information. Lighthouse has also developed Lighthouse UI (Siren) to monitor performance, see [Lighthouse UI (Siren)](./ui.md).
 
 ### <a name="net-bn-vc"></a> My beacon node and validator client are on different servers. How can I point the validator client to the beacon node?
 
@@ -454,7 +454,7 @@ The setting on the beacon node is the same for both cases below. In the beacon n
    curl "http://local_IP:5052/eth/v1/node/version"
    ```
 
-   You can refer to [Redundancy](./redundancy.md) for more information.
+   You can refer to [Redundancy](./advanced_redundancy.md) for more information.
 
 2. If the beacon node and validator clients are on different servers _and different networks_, it is necessary to perform port forwarding of the SSH port (e.g., the default port 22) on the router, and also allow firewall on the SSH port. The connection can be established via port forwarding on the router.
 
@@ -514,11 +514,11 @@ which shows that there are a total of 36 peers connected via QUIC.
 
 ### <a name="misc-slashing"></a> What should I do if I lose my slashing protection database?
 
-See [here](./slashing-protection.md#misplaced-slashing-database).
+See [here](./validator_slashing_protection.md#misplaced-slashing-database).
 
 ### <a name="misc-compile"></a> I can't compile lighthouse
 
-See [here.](./installation-source.md#troubleshooting)
+See [here.](./installation_source.md#troubleshooting)
 
 ### <a name="misc-version"></a> How do I check the version of Lighthouse that is running?
 
@@ -550,7 +550,7 @@ which says that the version is v4.1.0.
 
 ### <a name="misc-prune"></a> Does Lighthouse have pruning function like the execution client to save disk space?
 
-Yes, Lighthouse supports [state pruning](./database-migrations.md#how-to-prune-historic-states) which can help to save disk space.
+Yes, Lighthouse supports [state pruning](./advanced_database_migrations.md#how-to-prune-historic-states) which can help to save disk space.
 
 ### <a name="misc-freezer"></a> Can I use a HDD for the freezer database and only have the hot db on SSD?
 

book/src/installation.md

@@ -4,18 +4,18 @@ Lighthouse runs on Linux, macOS, and Windows.
 
 There are three core methods to obtain the Lighthouse application:
 
-- [Pre-built binaries](./installation-binaries.md).
+- [Pre-built binaries](./installation_binaries.md).
-- [Docker images](./docker.md).
+- [Docker images](./installation_docker.md).
-- [Building from source](./installation-source.md).
+- [Building from source](./installation_source.md).
 
 Additionally, there are two extra guides for specific uses:
 
-- [Raspberry Pi 4 guide](./pi.md). (Archived)
+- [Raspberry Pi 4 guide](./archived_pi.md). (Archived)
-- [Cross-compiling guide for developers](./cross-compiling.md).
+- [Cross-compiling guide for developers](./installation_cross_compiling.md).
 
 There are also community-maintained installation methods:
 
-- [Homebrew package](./homebrew.md).
+- [Homebrew package](./installation_homebrew.md).
 - Arch Linux AUR packages: [source](https://aur.archlinux.org/packages/lighthouse-ethereum),
   [binary](https://aur.archlinux.org/packages/lighthouse-ethereum-bin).
 

book/src/installation_cross_compiling.md

@@ -34,10 +34,10 @@ in `lighthouse/target/aarch64-unknown-linux-gnu/release`.
 
 When using the makefile the set of features used for building can be controlled with
 the environment variable `CROSS_FEATURES`. See [Feature
- Flags](./installation-source.md#feature-flags) for available features.
+ Flags](./installation_source.md#feature-flags) for available features.
 
 ## Compilation Profiles
 
 When using the makefile the build profile can be controlled with the environment variable
-`CROSS_PROFILE`. See [Compilation Profiles](./installation-source.md#compilation-profiles) for
+`CROSS_PROFILE`. See [Compilation Profiles](./installation_source.md#compilation-profiles) for
 available profiles.

book/src/installation_source.md

@@ -23,6 +23,8 @@ The rustup installer provides an easy way to update the Rust compiler, and works
 With Rust installed, follow the instructions below to install dependencies relevant to your
 operating system.
 
+> Note: For Linux OS, general Linux File Systems such as Ext4 or XFS are fine. We recommend to avoid using Btrfs file system as it has been reported to be slow and the node will suffer from performance degradation as a result.
+
 ### Ubuntu
 
 Install the following packages:
@@ -216,7 +218,7 @@ Rust Version (MSRV) which is listed under the `rust-version` key in Lighthouse's
 
 If compilation fails with `(signal: 9, SIGKILL: kill)`, this could mean your machine ran out of
 memory during compilation. If you are on a resource-constrained device you can
-look into [cross compilation](./cross-compiling.md), or use a [pre-built
+look into [cross compilation](./installation_cross_compiling.md), or use a [pre-built
 binary](https://github.com/sigp/lighthouse/releases).
 
 If compilation fails with `error: linking with cc failed: exit code: 1`, try running `cargo clean`.

book/src/intro.md

@@ -19,9 +19,9 @@ You may read this book from start to finish, or jump to some of these topics:
 
 - Follow the [Installation Guide](./installation.md) to install Lighthouse.
 - Run your very [own beacon node](./run_a_node.md).
-- Learn about [becoming a mainnet validator](./mainnet-validator.md).
+- Learn about [becoming a mainnet validator](./mainnet_validator.md).
-- Get hacking with the [Development Environment Guide](./setup.md).
+- Get hacking with the [Development Environment Guide](./contributing_setup.md).
-- Utilize the whole stack by starting a [local testnet](./setup.md#local-testnets).
+- Utilize the whole stack by starting a [local testnet](./contributing_setup.md#local-testnets).
 - Query the [RESTful HTTP API](./api.md) using `curl`.
 
 Prospective contributors can read the [Contributing](./contributing.md) section

book/src/mainnet_validator.md

@@ -1,9 +1,9 @@
 # Become an Ethereum Consensus Mainnet Validator
 
 [launchpad]: https://launchpad.ethereum.org/
-[advanced-datadir]: ./advanced-datadir.md
+[advanced-datadir]: ./advanced_datadir.md
 [license]: https://github.com/sigp/lighthouse/blob/stable/LICENSE
-[slashing]: ./slashing-protection.md
+[slashing]: ./validator_slashing_protection.md
 [discord]: https://discord.gg/cyAszAh
 
 Becoming an Ethereum consensus validator is rewarding, but it's not for the faint of heart. You'll need to be
@@ -54,7 +54,7 @@ and follow the instructions to generate the keys. When prompted for a network, s
 
 Upon completing this step, the files `deposit_data-*.json` and `keystore-m_*.json` will be created. The keys that are generated from staking-deposit-cli can be easily loaded into a Lighthouse validator client (`lighthouse vc`) in [Step 3](#step-3-import-validator-keys-to-lighthouse). In fact, both of these programs are designed to work with each other.
 
-> Lighthouse also supports creating validator keys, see [Key management](./key-management.md) for more info.
+> Lighthouse also supports creating validator keys, see [Validator Manager Create](./validator_manager_create.md) for more info.
 
 ### Step 2. Start an execution client and Lighthouse beacon node
 
@@ -99,7 +99,7 @@ Enter the keystore password, or press enter to omit it:
 ```
 
 The user can choose whether or not they'd like to store the validator password
-in the [`validator_definitions.yml`](./validator-management.md) file. If the
+in the [`validator_definitions.yml`](./validator_management.md) file. If the
 password is *not* stored here, the validator client (`lighthouse vc`)
 application will ask for the password each time it starts. This might be nice
 for some users from a security perspective (i.e., if it is a shared computer),
@@ -179,7 +179,7 @@ After the validator is running and performing its duties, it is important to kee
 
 The next important thing is to stay up to date with updates to Lighthouse and the execution client. Updates are released from time to time, typically once or twice a month. For Lighthouse updates, you can subscribe to notifications on [Github](https://github.com/sigp/lighthouse) by clicking on `Watch`. If you only want to receive notification on new releases, select `Custom`, then `Releases`. You could also join [Lighthouse Discord](https://discord.gg/cyAszAh) where we will make an announcement when there is a new release.
 
-You may also want to try out [Siren](./lighthouse-ui.md), a UI developed by Lighthouse to monitor validator performance.
+You may also want to try out [Siren](./ui.md), a UI developed by Lighthouse to monitor validator performance.
 
 Once you are familiar with running a validator and server maintenance, you'll find that running Lighthouse is easy. Install it, start it, monitor it and keep it updated. You shouldn't need to interact with it on a day-to-day basis. Happy staking!
 

book/src/run_a_node.md

@@ -129,7 +129,7 @@ INFO Downloading historical blocks  est_time: 5 hrs 0 mins, speed: 111.96 slots/
 
 Once backfill is complete, a `INFO Historical block download complete` log will be emitted.
 
-Check out the [FAQ](./checkpoint-sync.md#faq) for more information on checkpoint sync.
+Check out the [FAQ](./advanced_checkpoint_sync.md#faq) for more information on checkpoint sync.
 
 ### Logs - Syncing
 
@@ -146,11 +146,10 @@ Once you see the above message - congratulations! This means that your node is s
 
 Several other resources are the next logical step to explore after running your beacon node:
 
-- If you intend to run a validator, proceed to [become a validator](./mainnet-validator.md);
+- If you intend to run a validator, proceed to [become a validator](./mainnet_validator.md);
-- Explore how to [manage your keys](./key-management.md);
+- Explore how to [manage your keys](./archived_key_management.md);
-- Research on [validator management](./validator-management.md);
+- Research on [validator management](./validator_management.md);
 - Dig into the [APIs](./api.md) that the beacon node and validator client provide;
-- Study even more about [checkpoint sync](./checkpoint-sync.md); or
+- Study even more about [checkpoint sync](./advanced_checkpoint_sync.md); or
-- Investigate what steps had to be taken in the past to execute a smooth [merge migration](./merge-migration.md).
 
 Finally, if you are struggling with anything, join our [Discord](https://discord.gg/cyAszAh). We are happy to help!

book/src/ui-installation.md

@@ -1,73 +0,0 @@
-# 📦 Installation
-
-Siren supports any operating system that supports containers and/or NodeJS 18, this includes Linux, macOS, and Windows. The recommended way of running Siren is by launching the [docker container](https://hub.docker.com/r/sigp/siren) , but running the application directly is also possible.
-
-## Version Requirement
-
-To ensure proper functionality, the Siren app requires Lighthouse v4.3.0 or higher. You can find these versions on the [releases](https://github.com/sigp/lighthouse/releases) page of the Lighthouse repository.
-
-## Running the Docker container (Recommended)
-
-The most convenient way to run Siren is to use the Docker images built and published by Sigma Prime.
-
- They can be found on [Docker hub](https://hub.docker.com/r/sigp/siren/tags), or pulled directly with `docker pull sigp/siren`
-
-Configuration is done through environment variables, the easiest way to get started is by copying `.env.example` to `.env` and editing the relevant sections (typically, this would at least include adding `BEACON_URL`, `VALIDATOR_URL`, `API_TOKEN` and `SESSION_PASSWORD`)
-
-Then to run the image:
-
-`docker compose up`
-or
-`docker run --rm -ti --name siren -p 4443:443 --env-file $PWD/.env sigp/siren`
-
-This command will open port 4443, allowing your browser to connect.
-
-To start Siren, visit `https://localhost:4443` in your web browser.
-
-Advanced users can mount their own certificates, see the `SSL Certificates` section below
-
-## Building From Source
-
-### Docker
-
-The docker image can be built with the following command:
-`docker build -f Dockerfile -t siren .`
-
-### Building locally
-
-To build from source, ensure that your system has `Node v18.18` and `yarn` installed.
-
-#### Build and run the backend
-
-Navigate to the backend directory `cd backend`. Install all required Node packages by running `yarn`. Once the installation is complete, compile the backend with `yarn build`. Deploy the backend in a production environment, `yarn start:production`. This ensures optimal performance.
-
-#### Build and run the frontend
-
-After initializing the backend, return to the root directory. Install all frontend dependencies by executing `yarn`. Build the frontend using `yarn build`. Start the frontend production server with `yarn start`.
-
-This will allow you to access siren at `http://localhost:3000` by default.
-
-## Advanced configuration
-
-### About self-signed SSL certificates
-
-By default, Siren will generate and use a self-signed certificate on startup.
-This will generate a security warning when you try to access the interface.
-We recommend to only disable SSL if you would access Siren over a local LAN or otherwise highly trusted or encrypted network (i.e. VPN).
-
-#### Generating persistent SSL certificates and installing them to your system
-
-[mkcert](https://github.com/FiloSottile/mkcert) is a tool that makes it super easy to generate a self-signed certificate that is trusted by your browser.
-
-To use it for `siren`, install it following the instructions. Then, run `mkdir certs; mkcert -cert-file certs/cert.pem -key-file certs/key.pem 127.0.0.1 localhost` (add or replace any IP or hostname that you would use to access it at the end of this command)
-
-The nginx SSL config inside Siren's container expects 3 files: `/certs/cert.pem` `/certs/key.pem` `/certs/key.pass`. If `/certs/cert.pem` does not exist, it will generate a self-signed certificate as mentioned above. If `/certs/cert.pem` does exist, it will attempt to use your provided or persisted certificates.
-
-### Configuration through environment variables
-
-For those who prefer to use environment variables to configure Siren instead of using an `.env` file, this is fully supported. In some cases this may even be preferred.
-
-#### Docker installed through `snap`
-
-If you installed Docker through a snap (i.e. on Ubuntu), Docker will have trouble accessing the `.env` file. In this case it is highly recommended to pass the config to the container with environment variables.
-Note that the defaults in `.env.example` will be used as fallback, if no other value is provided.

book/src/ui.md

@@ -21,11 +21,11 @@ The UI is currently in active development. It resides in the
 See the following Siren specific topics for more context-specific
 information:
 
-- [Configuration Guide](./ui-configuration.md) - Explanation of how to setup
+- [Configuration Guide](./ui_configuration.md) - Explanation of how to setup
  and configure Siren.
-- [Authentication Guide](./ui-authentication.md) - Explanation of how Siren authentication works and protects validator actions.
+- [Authentication Guide](./ui_authentication.md) - Explanation of how Siren authentication works and protects validator actions.
-- [Usage](./ui-usage.md) - Details various Siren components.
+- [Usage](./ui_usage.md) - Details various Siren components.
-- [FAQs](./ui-faqs.md) - Frequently Asked Questions.
+- [FAQs](./ui_faqs.md) - Frequently Asked Questions.
 
 ## Contributing
 

book/src/ui_authentication.md

@@ -2,12 +2,12 @@
 
 ## Siren Session
 
-For enhanced security, Siren will require users to authenticate with their session password to access the dashboard. This is crucial because Siren now includes features that can permanently alter the status of the user's validators. The session password must be set during the [configuration](./ui-configuration.md) process before running the Docker or local build, either in an `.env` file or via Docker flags.
+For enhanced security, Siren will require users to authenticate with their session password to access the dashboard. This is crucial because Siren now includes features that can permanently alter the status of the user's validators. The session password must be set during the [configuration](./ui_configuration.md) process before running the Docker or local build, either in an `.env` file or via Docker flags.
 
 ![exit](imgs/ui-session.png)
 
 ## Protected Actions
 
-Prior to executing any sensitive validator action, Siren will request authentication of the session password. If you wish to update your password please refer to the Siren [configuration process](./ui-configuration.md).
+Prior to executing any sensitive validator action, Siren will request authentication of the session password. If you wish to update your password please refer to the Siren [configuration process](./ui_configuration.md).
 
 ![exit](imgs/ui-auth.png)

book/src/ui_configuration.md

@@ -29,7 +29,7 @@ We recommend running Siren's container next to your beacon node (on the same ser
     cd Siren
     ```
 
- 1. Create a configuration file in the `Siren` directory: `nano .env` and insert the following fields to the `.env` file. The field values are given here as an example, modify the fields as necessary. For example, the `API_TOKEN` can be obtained from [`Validator Client Authorization Header`](./api-vc-auth-header.md)
+ 1. Create a configuration file in the `Siren` directory: `nano .env` and insert the following fields to the `.env` file. The field values are given here as an example, modify the fields as necessary. For example, the `API_TOKEN` can be obtained from [`Validator Client Authorization Header`](./api_vc_auth_header.md)
 
     A full example with all possible configuration options can be found [here](https://github.com/sigp/siren/blob/stable/.env.example).  
 

book/src/ui_faqs.md

@@ -6,11 +6,11 @@ Yes, the most current Siren version requires Lighthouse v4.3.0 or higher to func
 
 ## 2. Where can I find my API token?
 
-The required API token may be found in the default data directory of the validator client. For more information please refer to the lighthouse ui configuration [`api token section`](./api-vc-auth-header.md).
+The required API token may be found in the default data directory of the validator client. For more information please refer to the lighthouse ui configuration [`api token section`](./api_vc_auth_header.md).
 
 ## 3. How do I fix the Node Network Errors?
 
-If you receive a red notification with a BEACON or VALIDATOR NODE NETWORK ERROR you can refer to the lighthouse ui [`configuration`](./ui-configuration.md#configuration).
+If you receive a red notification with a BEACON or VALIDATOR NODE NETWORK ERROR you can refer to the lighthouse ui [`configuration`](./ui_configuration.md#configuration).
 
 ## 4. How do I connect Siren to Lighthouse from a different computer on the same network?
 
@@ -19,7 +19,7 @@ That being said, it is entirely possible to have it published over the internet,
 
 ## 5. How can I use Siren to monitor my validators remotely when I am not at home?
 
-Most contemporary home routers provide options for VPN access in various ways. A VPN permits a remote computer to establish a connection with internal computers within a home network. With a VPN configuration in place, connecting to the VPN enables you to treat your computer as if it is part of your local home network. The connection process involves following the setup steps for connecting via another machine on the same network on the Siren configuration page and [`configuration`](./ui-configuration.md#configuration).
+Most contemporary home routers provide options for VPN access in various ways. A VPN permits a remote computer to establish a connection with internal computers within a home network. With a VPN configuration in place, connecting to the VPN enables you to treat your computer as if it is part of your local home network. The connection process involves following the setup steps for connecting via another machine on the same network on the Siren configuration page and [`configuration`](./ui_configuration.md#configuration).
 
 ## 6. Does Siren support reverse proxy or DNS named addresses?
 

book/src/validator_doppelganger.md

@@ -1,8 +1,8 @@
 # Doppelganger Protection
 
 [doppelgänger]: https://en.wikipedia.org/wiki/Doppelg%C3%A4nger
-[Slashing Protection]: ./slashing-protection.md
+[Slashing Protection]: ./validator_slashing_protection.md
-[VC HTTP API]: ./api-vc.md
+[VC HTTP API]: ./api_vc.md
 
 From Lighthouse `v1.5.0`, the *Doppelganger Protection* feature is available for the Validator
 Client. Taken from the German *[doppelgänger]*, which translates literally to "double-walker", a

book/src/validator_fee_recipient.md

@@ -82,7 +82,7 @@ validator client in order for the execution node to be given adequate notice of
 
 ## Setting the fee recipient dynamically using the keymanager API
 
-When the [validator client API](api-vc.md) is enabled, the
+When the [validator client API](api_vc.md) is enabled, the
 [standard keymanager API](https://ethereum.github.io/keymanager-APIs/) includes an endpoint
 for setting the fee recipient dynamically for a given public key. When used, the fee recipient
 will be saved in `validator_definitions.yml` so that it persists across restarts of the validator
@@ -92,7 +92,7 @@ client.
 |-------------------|--------------------------------------------|
 | Path              | `/eth/v1/validator/{pubkey}/feerecipient`  |
 | Method            | POST                                       |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 202, 404                                   |
 
 ### Example Request Body
@@ -117,7 +117,7 @@ curl -X POST \
     http://localhost:5062/eth/v1/validator/${PUBKEY}/feerecipient | jq
 ```
 
-Note that an authorization header is required to interact with the API. This is specified with the header `-H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)"` which read the API token to supply the authentication. Refer to [Authorization Header](./api-vc-auth-header.md) for more information. If you are having permission issue with accessing the API token file, you can modify the header to become `-H "Authorization: Bearer $(sudo cat ${DATADIR}/validators/api-token.txt)"`.
+Note that an authorization header is required to interact with the API. This is specified with the header `-H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)"` which read the API token to supply the authentication. Refer to [Authorization Header](./api_vc_auth_header.md) for more information. If you are having permission issue with accessing the API token file, you can modify the header to become `-H "Authorization: Bearer $(sudo cat ${DATADIR}/validators/api-token.txt)"`.
 
 #### Successful Response (202)
 
@@ -135,7 +135,7 @@ The same path with a `GET` request can be used to query the fee recipient for a
 |-------------------|--------------------------------------------|
 | Path              | `/eth/v1/validator/{pubkey}/feerecipient`  |
 | Method            | GET                                        |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 200, 404                                   |
 
 Command:
@@ -170,7 +170,7 @@ This is useful if you want the fee recipient to fall back to the validator clien
 |-------------------|--------------------------------------------|
 | Path              | `/eth/v1/validator/{pubkey}/feerecipient`  |
 | Method            | DELETE                                     |
-| Required Headers  | [`Authorization`](./api-vc-auth-header.md) |
+| Required Headers  | [`Authorization`](./api_vc_auth_header.md) |
 | Typical Responses | 204, 404                                   |
 
 Command:

book/src/validator_graffiti.md

@@ -32,7 +32,7 @@ Lighthouse will first search for the graffiti corresponding to the public key of
 
 Users can set validator specific graffitis in `validator_definitions.yml` with the `graffiti` key. This option is recommended for static setups where the graffitis won't change on every new block proposal.
 
-You can also update the graffitis in the `validator_definitions.yml` file using the [Lighthouse API](api-vc-endpoints.html#patch-lighthousevalidatorsvoting_pubkey). See example in [Set Graffiti via HTTP](#set-graffiti-via-http).
+You can also update the graffitis in the `validator_definitions.yml` file using the [Lighthouse API](api_vc_endpoints.html#patch-lighthousevalidatorsvoting_pubkey). See example in [Set Graffiti via HTTP](#set-graffiti-via-http).
 
 Below is an example of the validator_definitions.yml with validator specific graffitis:
 
@@ -74,11 +74,11 @@ Usage: `lighthouse bn --graffiti fortytwo`
 
 ## Set Graffiti via HTTP
 
-Use the [Lighthouse API](api-vc-endpoints.md) to set graffiti on a per-validator basis. This method updates the graffiti
+Use the [Lighthouse API](api_vc_endpoints.md) to set graffiti on a per-validator basis. This method updates the graffiti
 both in memory and in the `validator_definitions.yml` file. The new graffiti will be used in the next block proposal
 without requiring a validator client restart.
 
-Refer to [Lighthouse API](api-vc-endpoints.html#patch-lighthousevalidatorsvoting_pubkey) for API specification.
+Refer to [Lighthouse API](api_vc_endpoints.html#patch-lighthousevalidatorsvoting_pubkey) for API specification.
 
 ### Example Command
 

book/src/validator_management.md

@@ -13,7 +13,7 @@ standard directories and do not start their `lighthouse vc` with the
 this document. However, users with more complex needs may find this document
 useful.
 
-The [lighthouse validator-manager](./validator-manager.md) command can be used
+The [lighthouse validator-manager](./validator_manager.md) command can be used
 to create and import validators to a Lighthouse VC. It can also be used to move
 validators between two Lighthouse VCs.
 
@@ -54,7 +54,7 @@ Each permitted field of the file is listed below for reference:
 - `enabled`: A `true`/`false` indicating if the validator client should consider this
  validator "enabled".
 - `voting_public_key`: A validator public key.
-- `type`: How the validator signs messages (this can be `local_keystore` or `web3signer` (see [Web3Signer](./validator-web3signer.md))).
+- `type`: How the validator signs messages (this can be `local_keystore` or `web3signer` (see [Web3Signer](./advanced_web3signer.md))).
 - `voting_keystore_path`: The path to a EIP-2335 keystore.
 - `voting_keystore_password_path`: The path to the password for the EIP-2335 keystore.
 - `voting_keystore_password`: The password to the EIP-2335 keystore.

book/src/validator_manager.md

@@ -30,6 +30,6 @@ The `validator-manager` boasts the following features:
 
 ## Guides
 
-- [Creating and importing validators using the `create` and `import` commands.](./validator-manager-create.md)
+- [Creating and importing validators using the `create` and `import` commands.](./validator_manager_create.md)
-- [Moving validators between two VCs using the `move` command.](./validator-manager-move.md)
+- [Moving validators between two VCs using the `move` command.](./validator_manager_move.md)
-- [Managing validators such as delete, import and list validators.](./validator-manager-api.md)
+- [Managing validators such as delete, import and list validators.](./validator_manager_api.md)

book/src/validator_manager_create.md

@@ -69,7 +69,7 @@ lighthouse \
 > Be sure to remove `./validators.json` after the import is successful since it
 > contains unencrypted validator keystores.
 
-> Note: To import validators with validator-manager using keystore files created using the staking deposit CLI, refer to [Managing Validators](./validator-manager-api.md#import).
+> Note: To import validators with validator-manager using keystore files created using the staking deposit CLI, refer to [Managing Validators](./validator_manager_api.md#import).
 
 ## Detailed Guide
 
@@ -179,7 +179,7 @@ INFO Modified key_cache saved successfully
 
 The WARN message means that the `validators.json` file does not contain the slashing protection data. This is normal if you are starting a new validator. The flag `--enable-doppelganger-protection` will also protect users from potential slashing risk.
 The validators will now go through 2-3 epochs of [doppelganger
-protection](./validator-doppelganger.md) and will automatically start performing
+protection](./validator_doppelganger.md) and will automatically start performing
 their duties when they are deposited and activated.
 
 If the host VC contains the same public key as the `validators.json` file, an error will be shown and the `import` process will stop:

book/src/validator_monitoring.md

@@ -5,7 +5,7 @@ Generally users will want to use this function to track their own validators, ho
 used for any validator, regardless of who controls it.
 
 _Note: If you are looking for remote metric monitoring, please see the docs on
-[Prometheus Metrics](./advanced_metrics.md)_.
+[Prometheus Metrics](./api_metrics.md)_.
 
 ## Monitoring is in the Beacon Node
 
@@ -64,7 +64,7 @@ lighthouse bn --validator-monitor-pubkeys 0x933ad9491b62059dd065b560d256d8957a8c
 Enrolling a validator for additional monitoring results in:
 
 - Additional logs to be printed during BN operation.
-- Additional [Prometheus metrics](./advanced_metrics.md) from the BN.
+- Additional [Prometheus metrics](./api_metrics.md) from the BN.
 
 ### Logging
 

book/src/validator_slashing_protection.md

@@ -22,9 +22,9 @@ and carefully to keep your validators safe. See the [Troubleshooting](#troublesh
 The database will be automatically created, and your validators registered with it when:
 
 * Importing keys from another source (e.g. [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli/releases), Lodestar, Nimbus, Prysm, Teku, [ethdo](https://github.com/wealdtech/ethdo)).
-  See [import validator keys](./mainnet-validator.md#step-3-import-validator-keys-to-lighthouse).
+  See [import validator keys](./mainnet_validator.md#step-3-import-validator-keys-to-lighthouse).
 * Creating keys using Lighthouse itself (`lighthouse account validator create`)
-* Creating keys via the [validator client API](./api-vc.md).
+* Creating keys via the [validator client API](./api_vc.md).
 
 ## Avoiding Slashing
 
@@ -79,7 +79,7 @@ lighthouse account validator slashing-protection import filename.json
 ```
 
 When importing an interchange file, you still need to import the validator keystores themselves
-separately, using the instructions for [import validator keys](./mainnet-validator.md#step-3-import-validator-keys-to-lighthouse).
+separately, using the instructions for [import validator keys](./mainnet_validator.md#step-3-import-validator-keys-to-lighthouse).
 
 ---
 

book/src/validator_sweep.md

@@ -1,15 +1,15 @@
-# Partial Withdrawals
+# Validator "Sweeping" (Automatic Partial Withdrawals)
 
 After the [Capella](https://ethereum.org/en/history/#capella) upgrade on 12<sup>th</sup> April 2023:
 
 - if a validator has a withdrawal credential type `0x00`, the rewards will continue to accumulate and will be locked in the beacon chain.
-- if a validator has a withdrawal credential type `0x01`, any rewards above 32ETH will be periodically withdrawn to the withdrawal address. This is also known as the "validator sweep", i.e., once the "validator sweep" reaches your validator's index, your rewards will be withdrawn to the withdrawal address.  At the time of writing, with 560,000+ validators on the Ethereum mainnet, you shall expect to receive the rewards approximately every 5 days.
+- if a validator has a withdrawal credential type `0x01`, any rewards above 32ETH will be periodically withdrawn to the withdrawal address. This is also known as the "validator sweep", i.e., once the "validator sweep" reaches your validator's index, your rewards will be withdrawn to the withdrawal address.  The validator sweep is automatic and it does not incur any fees to withdraw.
 
 ## FAQ
 
 1. How to know if I have the withdrawal credentials type `0x00` or `0x01`?
 
-   Refer [here](./voluntary-exit.md#1-how-to-know-if-i-have-the-withdrawal-credentials-type-0x01).
+   Refer [here](./validator_voluntary_exit.md#1-how-to-know-if-i-have-the-withdrawal-credentials-type-0x01).
 
 2. My validator has withdrawal credentials type `0x00`, is there a deadline to update my withdrawal credentials?
 
@@ -17,7 +17,7 @@ After the [Capella](https://ethereum.org/en/history/#capella) upgrade on 12<sup>
 
 3. Do I have to do anything to get my rewards after I update the withdrawal credentials to type `0x01`?
 
-    No. The "validator sweep" occurs automatically and you can expect to receive the rewards every *n* days, [more information here](./voluntary-exit.md#4-when-will-i-get-my-staked-fund-after-voluntary-exit-if-my-validator-is-of-type-0x01).
+    No. The "validator sweep" occurs automatically and you can expect to receive the rewards every *n* days, [more information here](./validator_voluntary_exit.md#4-when-will-i-get-my-staked-fund-after-voluntary-exit-if-my-validator-is-of-type-0x01).
 
     Figure below summarizes partial withdrawals.
 

wordlist.txt

@@ -12,6 +12,7 @@ BN
 BNs
 BTC
 BTEC
+Btrfs
 Casper
 CentOS
 Chiado
@@ -38,6 +39,7 @@ Exercism
 Extractable
 FFG
 Geth
+GiB
 Gitcoin
 Gnosis
 Goerli
@@ -91,6 +93,7 @@ TLS
 TODOs
 UDP
 UI
+Uncached
 UPnP
 USD
 UX
@@ -100,6 +103,7 @@ VCs
 VPN
 Withdrawable
 WSL
+XFS
 YAML
 aarch
 anonymize
@@ -196,6 +200,7 @@ redb
 reimport
 resync
 roadmap
+routable
 rustfmt
 rustup
 schemas
@@ -220,6 +225,7 @@ tweakers
 ui
 unadvanced
 unaggregated
+uncached
 unencrypted
 unfinalized
 untrusted