diff --git a/book/.markdownlint.yml b/book/.markdownlint.yml index 5d6bda29f1e..4f7d1133648 100644 --- a/book/.markdownlint.yml +++ b/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 diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md index 44d7702e5ff..3d09e3a6a5a 100644 --- a/book/src/SUMMARY.md +++ b/book/src/SUMMARY.md @@ -2,58 +2,54 @@ * [Introduction](./intro.md) * [Installation](./installation.md) - * [Pre-Built Binaries](./installation-binaries.md) - * [Docker](./docker.md) - * [Build from Source](./installation-source.md) - * [Raspberry Pi 4](./pi.md) - * [Cross-Compiling](./cross-compiling.md) - * [Homebrew](./homebrew.md) - * [Update Priorities](./installation-priorities.md) + * [Pre-Built Binaries](./installation_binaries.md) + * [Docker](./installation_docker.md) + * [Build from Source](./installation_source.md) + * [Cross-Compiling](./installation_cross_compiling.md) + * [Homebrew](./installation_homebrew.md) + * [Update Priorities](./installation_priorities.md) * [Run a Node](./run_a_node.md) -* [Become a Validator](./mainnet-validator.md) -* [Validator Management](./validator-management.md) - * [The `validator-manager` Command](./validator-manager.md) - * [Creating validators](./validator-manager-create.md) - * [Moving validators](./validator-manager-move.md) - * [Managing validators](./validator-manager-api.md) - * [Slashing Protection](./slashing-protection.md) - * [Voluntary Exits](./voluntary-exit.md) - * [Partial Withdrawals](./partial-withdrawal.md) - * [Validator Monitoring](./validator-monitoring.md) - * [Doppelganger Protection](./validator-doppelganger.md) - * [Suggested Fee Recipient](./suggested-fee-recipient.md) - * [Validator Graffiti](./graffiti.md) +* [Become a Validator](./mainnet_validator.md) +* [Validator Management](./validator_management.md) + * [The `validator-manager` Command](./validator_manager.md) + * [Creating validators](./validator_manager_create.md) + * [Moving validators](./validator_manager_move.md) + * [Managing validators](./validator_manager_api.md) + * [Slashing Protection](./validator_slashing_protection.md) + * [Voluntary Exits](./validator_voluntary_exit.md) + * [Validator Sweep](./validator_sweep.md) + * [Validator Monitoring](./validator_monitoring.md) + * [Doppelganger Protection](./validator_doppelganger.md) + * [Suggested Fee Recipient](./validator_fee_recipient.md) + * [Validator Graffiti](./validator_graffiti.md) * [APIs](./api.md) - * [Beacon Node API](./api-bn.md) - * [Lighthouse API](./api-lighthouse.md) - * [Validator Inclusion APIs](./validator-inclusion.md) - * [Validator Client API](./api-vc.md) - * [Endpoints](./api-vc-endpoints.md) - * [Authorization Header](./api-vc-auth-header.md) - * [Signature Header](./api-vc-sig-header.md) - * [Prometheus Metrics](./advanced_metrics.md) -* [Lighthouse UI (Siren)](./lighthouse-ui.md) - * [Configuration](./ui-configuration.md) - * [Authentication](./ui-authentication.md) - * [Usage](./ui-usage.md) - * [FAQs](./ui-faqs.md) + * [Beacon Node API](./api_bn.md) + * [Lighthouse API](./api_lighthouse.md) + * [Validator Inclusion APIs](./api_validator_inclusion.md) + * [Validator Client API](./api_vc.md) + * [Endpoints](./api_vc_endpoints.md) + * [Authorization Header](./api_vc_auth_header.md) + * [Prometheus Metrics](./api_metrics.md) +* [Lighthouse UI (Siren)](./ui.md) + * [Configuration](./ui_configuration.md) + * [Authentication](./ui_authentication.md) + * [Usage](./ui_usage.md) + * [FAQs](./ui_faqs.md) * [Advanced Usage](./advanced.md) - * [Checkpoint Sync](./checkpoint-sync.md) - * [Custom Data Directories](./advanced-datadir.md) - * [Proposer Only Beacon Nodes](./advanced-proposer-only.md) - * [Remote Signing with Web3Signer](./validator-web3signer.md) + * [Checkpoint Sync](./advanced_checkpoint_sync.md) + * [Custom Data Directories](./advanced_datadir.md) + * [Proposer Only Beacon Nodes](./advanced_proposer_only.md) + * [Remote Signing with Web3Signer](./advanced_web3signer.md) * [Database Configuration](./advanced_database.md) - * [Database Migrations](./database-migrations.md) - * [Key Management (Deprecated)](./key-management.md) - * [Key Recovery](./key-recovery.md) + * [Database Migrations](./advanced_database_migrations.md) + * [Key Recovery](./advanced_key_recovery.md) * [Advanced Networking](./advanced_networking.md) - * [Running a Slasher](./slasher.md) - * [Redundancy](./redundancy.md) - * [Release Candidates](./advanced-release-candidates.md) - * [MEV](./builders.md) - * [Merge Migration](./merge-migration.md) - * [Late Block Re-orgs](./late-block-re-orgs.md) - * [Blobs](./advanced-blobs.md) + * [Running a Slasher](./advanced_slasher.md) + * [Redundancy](./advanced_redundancy.md) + * [Release Candidates](./advanced_release_candidates.md) + * [MEV](./advanced_builders.md) + * [Late Block Re-orgs](./advanced_re-orgs.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) diff --git a/book/src/advanced.md b/book/src/advanced.md index 1a882835a47..76a7fed2029 100644 --- a/book/src/advanced.md +++ b/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. -* [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. -* [Remote Signing with Web3Signer](./validator-web3signer.md): don't want to store your keystore in local node? Use web3signer. +* [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. +* [Proposer Only Beacon Nodes](./advanced_proposer_only.md): beacon node only for proposer duty for increased anonymity. +* [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. -* [Key Management](./key-management.md): explore how to generate wallet with Lighthouse. -* [Key Recovery](./key-recovery.md): explore how to recover wallet and validator with Lighthouse. +* [Database Migrations](./advanced_database_migrations.md): have a look at all previous Lighthouse database scheme versions. +* [Key Recovery](./advanced_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. -* [Redundancy](./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. -* [Maximal Extractable Value](./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](./late-block-re-orgs.md): read information about Lighthouse late block re-orgs. -* [Blobs](./advanced-blobs.md): information about blobs in Deneb upgrade +* [Running a Slasher](./advanced_slasher.md): contribute to the health of the network by running a slasher. +* [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. +* [Maximal Extractable Value](./advanced_builders.md): use external builders for a potential higher rewards during block proposals +* [Late Block Re-orgs](./advanced_re-orgs.md): read information about Lighthouse late block re-orgs. +* [Blobs](./advanced_blobs.md): information about blobs in Deneb upgrade diff --git a/book/src/advanced-blobs.md b/book/src/advanced_blobs.md similarity index 96% rename from book/src/advanced-blobs.md rename to book/src/advanced_blobs.md index 785bd5797dd..aa995b8e1d5 100644 --- a/book/src/advanced-blobs.md +++ b/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. diff --git a/book/src/builders.md b/book/src/advanced_builders.md similarity index 95% rename from book/src/builders.md rename to book/src/advanced_builders.md index 5b8e9ddb8b7..d9468898b4a 100644 --- a/book/src/builders.md +++ b/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 diff --git a/book/src/checkpoint-sync.md b/book/src/advanced_checkpoint_sync.md similarity index 99% rename from book/src/checkpoint-sync.md rename to book/src/advanced_checkpoint_sync.md index 8dd63f77c9b..45aed6ef58a 100644 --- a/book/src/checkpoint-sync.md +++ b/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. diff --git a/book/src/advanced_database.md b/book/src/advanced_database.md index b558279730e..4e77046c2dd 100644 --- a/book/src/advanced_database.md +++ b/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. diff --git a/book/src/database-migrations.md b/book/src/advanced_database_migrations.md similarity index 100% rename from book/src/database-migrations.md rename to book/src/advanced_database_migrations.md diff --git a/book/src/advanced-datadir.md b/book/src/advanced_datadir.md similarity index 98% rename from book/src/advanced-datadir.md rename to book/src/advanced_datadir.md index 7ad993a1072..1be8ed5a348 100644 --- a/book/src/advanced-datadir.md +++ b/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 diff --git a/book/src/key-recovery.md b/book/src/advanced_key_recovery.md similarity index 100% rename from book/src/key-recovery.md rename to book/src/advanced_key_recovery.md diff --git a/book/src/advanced_networking.md b/book/src/advanced_networking.md index 0dc1000aa04..0dc53bd42aa 100644 --- a/book/src/advanced_networking.md +++ b/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**: > diff --git a/book/src/advanced-proposer-only.md b/book/src/advanced_proposer_only.md similarity index 97% rename from book/src/advanced-proposer-only.md rename to book/src/advanced_proposer_only.md index 1ea36109883..f55e51606cf 100644 --- a/book/src/advanced-proposer-only.md +++ b/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 diff --git a/book/src/late-block-re-orgs.md b/book/src/advanced_re-orgs.md similarity index 100% rename from book/src/late-block-re-orgs.md rename to book/src/advanced_re-orgs.md diff --git a/book/src/redundancy.md b/book/src/advanced_redundancy.md similarity index 94% rename from book/src/redundancy.md rename to book/src/advanced_redundancy.md index daf0eb4a5b4..4582866657a 100644 --- a/book/src/redundancy.md +++ b/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-jwt`: see [Merge Migration](./merge-migration.md). +- `--execution-endpoint`: see [Merge Migration](./archived_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. diff --git a/book/src/advanced-release-candidates.md b/book/src/advanced_release_candidates.md similarity index 100% rename from book/src/advanced-release-candidates.md rename to book/src/advanced_release_candidates.md diff --git a/book/src/slasher.md b/book/src/advanced_slasher.md similarity index 99% rename from book/src/slasher.md rename to book/src/advanced_slasher.md index 3310f6c9eff..b354c9deb25 100644 --- a/book/src/slasher.md +++ b/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. diff --git a/book/src/validator-web3signer.md b/book/src/advanced_web3signer.md similarity index 95% rename from book/src/validator-web3signer.md rename to book/src/advanced_web3signer.md index 6a518af3cfc..6145fd4a716 100644 --- a/book/src/validator-web3signer.md +++ b/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: diff --git a/book/src/api.md b/book/src/api.md index 5837ad9654a..912c8658b67 100644 --- a/book/src/api.md +++ b/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) -- [Validator Client API](./api-vc.md) +- [Beacon Node API](./api_bn.md) +- [Validator Client API](./api_vc.md) diff --git a/book/src/api-bn.md b/book/src/api_bn.md similarity index 100% rename from book/src/api-bn.md rename to book/src/api_bn.md diff --git a/book/src/api-lighthouse.md b/book/src/api_lighthouse.md similarity index 98% rename from book/src/api-lighthouse.md rename to book/src/api_lighthouse.md index 5428ab8f9ae..b65bef47628 100644 --- a/book/src/api-lighthouse.md +++ b/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 + } } +``` diff --git a/book/src/advanced_metrics.md b/book/src/api_metrics.md similarity index 97% rename from book/src/advanced_metrics.md rename to book/src/api_metrics.md index 323ba8f58a7..c124d3acb75 100644 --- a/book/src/advanced_metrics.md +++ b/book/src/api_metrics.md @@ -68,7 +68,7 @@ The specification for the monitoring endpoint can be found here: - -_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 diff --git a/book/src/validator-inclusion.md b/book/src/api_validator_inclusion.md similarity index 100% rename from book/src/validator-inclusion.md rename to book/src/api_validator_inclusion.md diff --git a/book/src/api-vc.md b/book/src/api_vc.md similarity index 91% rename from book/src/api-vc.md rename to book/src/api_vc.md index 630a0320066..f5df5df76c3 100644 --- a/book/src/api-vc.md +++ b/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 -> [`Signature`](./api-vc-sig-header.md) header for optional verification. +> [`Authorization`](./api_vc_auth_header.md) header. ## Starting the server diff --git a/book/src/api-vc-auth-header.md b/book/src/api_vc_auth_header.md similarity index 100% rename from book/src/api-vc-auth-header.md rename to book/src/api_vc_auth_header.md diff --git a/book/src/api-vc-endpoints.md b/book/src/api_vc_endpoints.md similarity index 97% rename from book/src/api-vc-endpoints.md rename to book/src/api_vc_endpoints.md index 98605a3dcd0..a7c6f0ad5e1 100644 --- a/book/src/api-vc-endpoints.md +++ b/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 diff --git a/book/src/key-management.md b/book/src/archived-key-management.md similarity index 98% rename from book/src/key-management.md rename to book/src/archived-key-management.md index fa6e99a2aa6..3f600794e06 100644 --- a/book/src/key-management.md +++ b/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` diff --git a/book/src/merge-migration.md b/book/src/archived-merge-migration.md similarity index 99% rename from book/src/merge-migration.md rename to book/src/archived-merge-migration.md index 7a123254bf7..ac9c78c5e3b 100644 --- a/book/src/merge-migration.md +++ b/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. diff --git a/book/src/archived.md b/book/src/archived.md new file mode 100644 index 00000000000..7b6e4b7e8ef --- /dev/null +++ b/book/src/archived.md @@ -0,0 +1,3 @@ +# Archived + +This section keeps the topics that are deprecated or less applicable for archived purposes. diff --git a/book/src/pi.md b/book/src/archived_pi.md similarity index 91% rename from book/src/pi.md rename to book/src/archived_pi.md index b91ecab548c..6afbcebd66e 100644 --- a/book/src/pi.md +++ b/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 diff --git a/book/src/contributing.md b/book/src/contributing.md index 312acccbc04..332afbfd702 100644 --- a/book/src/contributing.md +++ b/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/) diff --git a/book/src/setup.md b/book/src/contributing_setup.md similarity index 100% rename from book/src/setup.md rename to book/src/contributing_setup.md diff --git a/book/src/faq.md b/book/src/faq.md index d23951c8c77..a741834501c 100644 --- a/book/src/faq.md +++ b/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. ### 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. ### 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 ### 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. ### 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: ### 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. ### 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). ### 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. ### 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). ### I can't compile lighthouse -See [here.](./installation-source.md#troubleshooting) +See [here.](./installation_source.md#troubleshooting) ### How do I check the version of Lighthouse that is running? @@ -550,7 +550,7 @@ which says that the version is v4.1.0. ### 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. ### Can I use a HDD for the freezer database and only have the hot db on SSD? diff --git a/book/src/imgs/per-epoch.png b/book/src/imgs/per-epoch.png new file mode 100644 index 00000000000..d4ac77ecbbe Binary files /dev/null and b/book/src/imgs/per-epoch.png differ diff --git a/book/src/imgs/per-slot.png b/book/src/imgs/per-slot.png new file mode 100644 index 00000000000..91b9c12e4c6 Binary files /dev/null and b/book/src/imgs/per-slot.png differ diff --git a/book/src/installation.md b/book/src/installation.md index 137a00b918b..95550e0807e 100644 --- a/book/src/installation.md +++ b/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). -- [Docker images](./docker.md). -- [Building from source](./installation-source.md). +- [Pre-built binaries](./installation_binaries.md). +- [Docker images](./installation_docker.md). +- [Building from source](./installation_source.md). Additionally, there are two extra guides for specific uses: -- [Raspberry Pi 4 guide](./pi.md). (Archived) -- [Cross-compiling guide for developers](./cross-compiling.md). +- [Raspberry Pi 4 guide](./archived_pi.md). (Archived) +- [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). diff --git a/book/src/installation-binaries.md b/book/src/installation_binaries.md similarity index 100% rename from book/src/installation-binaries.md rename to book/src/installation_binaries.md diff --git a/book/src/cross-compiling.md b/book/src/installation_cross_compiling.md similarity index 90% rename from book/src/cross-compiling.md rename to book/src/installation_cross_compiling.md index c90001d561f..4f6ba9af38a 100644 --- a/book/src/cross-compiling.md +++ b/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. diff --git a/book/src/docker.md b/book/src/installation_docker.md similarity index 100% rename from book/src/docker.md rename to book/src/installation_docker.md diff --git a/book/src/homebrew.md b/book/src/installation_homebrew.md similarity index 100% rename from book/src/homebrew.md rename to book/src/installation_homebrew.md diff --git a/book/src/installation-priorities.md b/book/src/installation_priorities.md similarity index 100% rename from book/src/installation-priorities.md rename to book/src/installation_priorities.md diff --git a/book/src/installation-source.md b/book/src/installation_source.md similarity index 95% rename from book/src/installation-source.md rename to book/src/installation_source.md index 19098a5bc8d..0aa8a99a5e5 100644 --- a/book/src/installation-source.md +++ b/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`. diff --git a/book/src/intro.md b/book/src/intro.md index 9892a8a49db..e5729046854 100644 --- a/book/src/intro.md +++ b/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). -- Get hacking with the [Development Environment Guide](./setup.md). -- Utilize the whole stack by starting a [local testnet](./setup.md#local-testnets). +- Learn about [becoming a mainnet validator](./mainnet_validator.md). +- Get hacking with the [Development Environment Guide](./contributing_setup.md). +- 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 diff --git a/book/src/mainnet-validator.md b/book/src/mainnet_validator.md similarity index 96% rename from book/src/mainnet-validator.md rename to book/src/mainnet_validator.md index c53be97ccf9..d21d49f0c90 100644 --- a/book/src/mainnet-validator.md +++ b/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! diff --git a/book/src/run_a_node.md b/book/src/run_a_node.md index 9b9e0cba8e5..15567497e50 100644 --- a/book/src/run_a_node.md +++ b/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); -- Explore how to [manage your keys](./key-management.md); -- Research on [validator management](./validator-management.md); +- If you intend to run a validator, proceed to [become a validator](./mainnet_validator.md); +- Explore how to [manage your keys](./archived_key_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 -- Investigate what steps had to be taken in the past to execute a smooth [merge migration](./merge-migration.md). +- Study even more about [checkpoint sync](./advanced_checkpoint_sync.md); or Finally, if you are struggling with anything, join our [Discord](https://discord.gg/cyAszAh). We are happy to help! diff --git a/book/src/ui-installation.md b/book/src/ui-installation.md deleted file mode 100644 index 9cd84e5160b..00000000000 --- a/book/src/ui-installation.md +++ /dev/null @@ -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. diff --git a/book/src/lighthouse-ui.md b/book/src/ui.md similarity index 79% rename from book/src/lighthouse-ui.md rename to book/src/ui.md index f2662f4a69a..e980e902687 100644 --- a/book/src/lighthouse-ui.md +++ b/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. -- [Usage](./ui-usage.md) - Details various Siren components. -- [FAQs](./ui-faqs.md) - Frequently Asked Questions. +- [Authentication Guide](./ui_authentication.md) - Explanation of how Siren authentication works and protects validator actions. +- [Usage](./ui_usage.md) - Details various Siren components. +- [FAQs](./ui_faqs.md) - Frequently Asked Questions. ## Contributing diff --git a/book/src/ui-authentication.md b/book/src/ui_authentication.md similarity index 87% rename from book/src/ui-authentication.md rename to book/src/ui_authentication.md index 81b867bae26..36e3835e3bf 100644 --- a/book/src/ui-authentication.md +++ b/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) diff --git a/book/src/ui-configuration.md b/book/src/ui_configuration.md similarity index 99% rename from book/src/ui-configuration.md rename to book/src/ui_configuration.md index 34cc9fe7ca6..64b293372bb 100644 --- a/book/src/ui-configuration.md +++ b/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). diff --git a/book/src/ui-faqs.md b/book/src/ui_faqs.md similarity index 92% rename from book/src/ui-faqs.md rename to book/src/ui_faqs.md index 29de889e5fc..db365e2fa0e 100644 --- a/book/src/ui-faqs.md +++ b/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? diff --git a/book/src/ui-usage.md b/book/src/ui_usage.md similarity index 100% rename from book/src/ui-usage.md rename to book/src/ui_usage.md diff --git a/book/src/validator-doppelganger.md b/book/src/validator_doppelganger.md similarity index 98% rename from book/src/validator-doppelganger.md rename to book/src/validator_doppelganger.md index a3d60d31b3c..006df50bd90 100644 --- a/book/src/validator-doppelganger.md +++ b/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 -[VC HTTP API]: ./api-vc.md +[Slashing Protection]: ./validator_slashing_protection.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 diff --git a/book/src/suggested-fee-recipient.md b/book/src/validator_fee_recipient.md similarity index 96% rename from book/src/suggested-fee-recipient.md rename to book/src/validator_fee_recipient.md index 4a9be7b963a..2b125f5033d 100644 --- a/book/src/suggested-fee-recipient.md +++ b/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: diff --git a/book/src/graffiti.md b/book/src/validator_graffiti.md similarity index 95% rename from book/src/graffiti.md rename to book/src/validator_graffiti.md index 7b402ea866f..9908d056da3 100644 --- a/book/src/graffiti.md +++ b/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 diff --git a/book/src/validator-management.md b/book/src/validator_management.md similarity index 98% rename from book/src/validator-management.md rename to book/src/validator_management.md index b9610b69675..18abfb15381 100644 --- a/book/src/validator-management.md +++ b/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. diff --git a/book/src/validator-manager.md b/book/src/validator_manager.md similarity index 93% rename from book/src/validator-manager.md rename to book/src/validator_manager.md index 11df2af0378..c610340b390 100644 --- a/book/src/validator-manager.md +++ b/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) -- [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) +- [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) +- [Managing validators such as delete, import and list validators.](./validator_manager_api.md) diff --git a/book/src/validator-manager-api.md b/book/src/validator_manager_api.md similarity index 100% rename from book/src/validator-manager-api.md rename to book/src/validator_manager_api.md diff --git a/book/src/validator-manager-create.md b/book/src/validator_manager_create.md similarity index 98% rename from book/src/validator-manager-create.md rename to book/src/validator_manager_create.md index b4c86dc6da8..458907bc65b 100644 --- a/book/src/validator-manager-create.md +++ b/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: diff --git a/book/src/validator-manager-move.md b/book/src/validator_manager_move.md similarity index 100% rename from book/src/validator-manager-move.md rename to book/src/validator_manager_move.md diff --git a/book/src/validator-monitoring.md b/book/src/validator_monitoring.md similarity index 98% rename from book/src/validator-monitoring.md rename to book/src/validator_monitoring.md index bbc95460ec9..d7f00521c41 100644 --- a/book/src/validator-monitoring.md +++ b/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 diff --git a/book/src/slashing-protection.md b/book/src/validator_slashing_protection.md similarity index 97% rename from book/src/slashing-protection.md rename to book/src/validator_slashing_protection.md index 2d580f1c312..3e0fe184e5b 100644 --- a/book/src/slashing-protection.md +++ b/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). --- diff --git a/book/src/partial-withdrawal.md b/book/src/validator_sweep.md similarity index 75% rename from book/src/partial-withdrawal.md rename to book/src/validator_sweep.md index 26003e1f2fe..b707988e84c 100644 --- a/book/src/partial-withdrawal.md +++ b/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 12th 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 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. diff --git a/book/src/voluntary-exit.md b/book/src/validator_voluntary_exit.md similarity index 100% rename from book/src/voluntary-exit.md rename to book/src/validator_voluntary_exit.md diff --git a/wordlist.txt b/wordlist.txt index bb8b46b525e..7adbfe90326 100644 --- a/wordlist.txt +++ b/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