From d5ee394792e1913f21222b69e39c11d0ba0f9bdc Mon Sep 17 00:00:00 2001 From: chonghe Date: Wed, 10 Apr 2024 18:16:18 +0800 Subject: [PATCH] mdlint --- book/src/api-lighthouse.md | 86 ++++++++++++++++-------------- book/src/api-vc-endpoints.md | 26 +++++---- book/src/mainnet-validator.md | 34 ++++++------ book/src/validator-manager-move.md | 9 ++-- 4 files changed, 84 insertions(+), 71 deletions(-) diff --git a/book/src/api-lighthouse.md b/book/src/api-lighthouse.md index ce71450987d..974cd1bdd40 100644 --- a/book/src/api-lighthouse.md +++ b/book/src/api-lighthouse.md @@ -16,12 +16,12 @@ Although we don't recommend that users rely on these endpoints, we document them briefly so they can be utilized by developers and researchers. - - ### `/lighthouse/health` + *Note: This endpoint is presently only available on Linux.* Returns information regarding the health of the host machine. + ```bash curl -X GET "http://localhost:5052/lighthouse/health" -H "accept: application/json" | jq ``` @@ -65,6 +65,7 @@ curl -X GET "http://localhost:5052/lighthouse/health" -H "accept: application/j ``` ### `/lighthouse/ui/health` + Returns information regarding the health of the host machine. ```bash @@ -102,7 +103,9 @@ curl -X GET "http://localhost:5052/lighthouse/ui/health" -H "accept: applicatio ``` ### `/lighthouse/ui/validator_count` + Returns an overview of validators. + ```bash curl -X GET "http://localhost:5052/lighthouse/ui/validator_count" -H "accept: application/json" | jq ``` @@ -123,9 +126,10 @@ curl -X GET "http://localhost:5052/lighthouse/ui/validator_count" -H "accept: ap } ``` - ### `/lighthouse/ui/validator_metrics` + Re-exposes certain metrics from the validator monitor to the HTTP API. This API requires that the beacon node to have the flag `--validator-monitor-auto`. This API will only return metrics for the validators currently being monitored and present in the POST data, or the validators running in the validator client. + ```bash curl -X POST "http://localhost:5052/lighthouse/ui/validator_metrics" -d '{"indices": [12345]}' -H "Content-Type: application/json" | jq ``` @@ -150,7 +154,9 @@ curl -X POST "http://localhost:5052/lighthouse/ui/validator_metrics" -d '{"indic } } ``` + Running this API without the flag `--validator-monitor-auto` in the beacon node will return null: + ```json { "data": { @@ -160,7 +166,9 @@ Running this API without the flag `--validator-monitor-auto` in the beacon node ``` ### `/lighthouse/syncing` + Returns the sync status of the beacon node. + ```bash curl -X GET "http://localhost:5052/lighthouse/syncing" -H "accept: application/json" | jq ``` @@ -168,6 +176,7 @@ curl -X GET "http://localhost:5052/lighthouse/syncing" -H "accept: application/ There are two possible outcomes, depending on whether the beacon node is syncing or synced. 1. Syncing: + ```json { "data": { @@ -178,7 +187,9 @@ There are two possible outcomes, depending on whether the beacon node is syncing } } ``` + 1. Synced: + ```json { "data": "Synced" @@ -191,7 +202,6 @@ There are two possible outcomes, depending on whether the beacon node is syncing curl -X GET "http://localhost:5052/lighthouse/peers" -H "accept: application/json" | jq ``` - ```json [ { @@ -256,13 +266,13 @@ curl -X GET "http://localhost:5052/lighthouse/peers" -H "accept: application/js ``` ### `/lighthouse/peers/connected` + Returns information about connected peers. + ```bash curl -X GET "http://localhost:5052/lighthouse/peers/connected" -H "accept: application/json" | jq ``` - - ```json [ { @@ -355,23 +365,23 @@ from the very head of the execution chain. Useful for understanding the immediat health of the execution node that the beacon node is connected to. - `latest_cached_block_number` & `latest_cached_block_timestamp`: the block number and timestamp of the latest block we have in our block cache. - - For correct execution client voting this timestamp should be later than the + - For correct execution client voting this timestamp should be later than the `voting_target_timestamp`. - `voting_target_timestamp`: The latest timestamp allowed for an execution layer block in this voting period. - `eth1_node_sync_status_percentage` (float): An estimate of how far the head of the execution node is from the head of the execution chain. - - `100.0` indicates a fully synced execution node. - - `0.0` indicates an execution node that has not verified any blocks past the - genesis block. + - `100.0` indicates a fully synced execution node. + - `0.0` indicates an execution node that has not verified any blocks past the + genesis block. - `lighthouse_is_cached_and_ready`: Is set to `true` if the caches in the - beacon node are ready for block production. - - This value might be set to - `false` whilst `eth1_node_sync_status_percentage == 100.0` if the beacon - node is still building its internal cache. - - This value might be set to `true` whilst - `eth1_node_sync_status_percentage < 100.0` since the cache only cares - about blocks a certain distance behind the head. + beacon node are ready for block production. + - This value might be set to + `false` whilst `eth1_node_sync_status_percentage == 100.0` if the beacon + node is still building its internal cache. + - This value might be set to `true` whilst + `eth1_node_sync_status_percentage < 100.0` since the cache only cares + about blocks a certain distance behind the head. #### Example @@ -488,8 +498,6 @@ curl -X POST "http://localhost:5052/lighthouse/liveness" -d '{"indices":["0","1" } ``` - - ### `/lighthouse/database/info` Information about the database's split point and anchor info. @@ -498,7 +506,6 @@ Information about the database's split point and anchor info. curl "http://localhost:5052/lighthouse/database/info" | jq ``` - ```json { "schema_version": 18, @@ -541,9 +548,10 @@ reconstruction has yet to be completed. For more information on the specific meanings of these fields see the docs on [Checkpoint Sync](./checkpoint-sync.md#reconstructing-states). - ### `/lighthouse/merge_readiness` + Returns the current difficulty and terminal total difficulty of the network. Before [The Merge](https://ethereum.org/en/roadmap/merge/) on 15th September 2022, you will see that the current difficulty is less than the terminal total difficulty, An example is shown below: + ```bash curl -X GET "http://localhost:5052/lighthouse/merge_readiness" | jq ``` @@ -574,7 +582,6 @@ As all testnets and Mainnet have been merged, both values will be the same after } ``` - ### `/lighthouse/analysis/attestation_performance/{index}` Fetch information about the attestation performance of a validator index or all validators for a @@ -582,8 +589,8 @@ range of consecutive epochs. Two query parameters are required: -* `start_epoch` (inclusive): the first epoch to compute attestation performance for. -* `end_epoch` (inclusive): the final epoch to compute attestation performance for. +- `start_epoch` (inclusive): the first epoch to compute attestation performance for. +- `end_epoch` (inclusive): the final epoch to compute attestation performance for. Example: @@ -649,8 +656,8 @@ curl -X GET "http://localhost:5052/lighthouse/analysis/attestation_performance/g Caveats: -* For maximum efficiency the start_epoch should satisfy `(start_epoch * slots_per_epoch) % slots_per_restore_point == 1`. - This is because the state _prior_ to the `start_epoch` needs to be loaded from the database, +- For maximum efficiency the start_epoch should satisfy `(start_epoch * slots_per_epoch) % slots_per_restore_point == 1`. + This is because the state *prior* to the `start_epoch` needs to be loaded from the database, and loading a state on a boundary is most efficient. ### `/lighthouse/analysis/block_rewards` @@ -659,8 +666,8 @@ Fetch information about the block rewards paid to proposers for a range of conse Two query parameters are required: -* `start_slot` (inclusive): the slot of the first block to compute rewards for. -* `end_slot` (inclusive): the slot of the last block to compute rewards for. +- `start_slot` (inclusive): the slot of the first block to compute rewards for. +- `end_slot` (inclusive): the slot of the last block to compute rewards for. Example: @@ -668,7 +675,6 @@ Example: curl -X GET "http://localhost:5052/lighthouse/analysis/block_rewards?start_slot=1&end_slot=1" | jq ``` - The first few lines of the response would look like: ```json @@ -698,11 +704,11 @@ The first few lines of the response would look like: Caveats: -* Presently only attestation and sync committee rewards are computed. -* The output format is verbose and subject to change. Please see [`BlockReward`][block_reward_src] +- Presently only attestation and sync committee rewards are computed. +- The output format is verbose and subject to change. Please see [`BlockReward`][block_reward_src] in the source. -* For maximum efficiency the `start_slot` should satisfy `start_slot % slots_per_restore_point == 1`. - This is because the state _prior_ to the `start_slot` needs to be loaded from the database, and +- For maximum efficiency the `start_slot` should satisfy `start_slot % slots_per_restore_point == 1`. + This is because the state *prior* to the `start_slot` needs to be loaded from the database, and loading a state on a boundary is most efficient. [block_reward_src]: @@ -715,8 +721,8 @@ epochs. Two query parameters are required: -* `start_epoch` (inclusive): the epoch of the first block to compute packing efficiency for. -* `end_epoch` (inclusive): the epoch of the last block to compute packing efficiency for. +- `start_epoch` (inclusive): the epoch of the first block to compute packing efficiency for. +- `end_epoch` (inclusive): the epoch of the last block to compute packing efficiency for. ```bash curl -X GET "http://localhost:5052/lighthouse/analysis/block_packing_efficiency?start_epoch=1&end_epoch=1" | jq @@ -745,12 +751,11 @@ An excerpt of the response looks like: Caveats: -* `start_epoch` must not be `0`. -* For maximum efficiency the `start_epoch` should satisfy `(start_epoch * slots_per_epoch) % slots_per_restore_point == 1`. - This is because the state _prior_ to the `start_epoch` needs to be loaded from the database, and +- `start_epoch` must not be `0`. +- For maximum efficiency the `start_epoch` should satisfy `(start_epoch * slots_per_epoch) % slots_per_restore_point == 1`. + This is because the state *prior* to the `start_epoch` needs to be loaded from the database, and loading a state on a boundary is most efficient. - ### `/lighthouse/logs` This is a Server Side Event subscription endpoint. This allows a user to read @@ -764,6 +769,7 @@ curl -N "http://localhost:5052/lighthouse/logs" ``` Should provide an output that emits log events as they occur: + ```json { "data": { @@ -780,6 +786,7 @@ Should provide an output that emits log events as they occur: ``` ### `/lighthouse/nat` + Checks if the ports are open. ```bash @@ -787,6 +794,7 @@ curl -X GET "http://localhost:5052/lighthouse/nat" | jq ``` An open port will return: + ```json { "data": true diff --git a/book/src/api-vc-endpoints.md b/book/src/api-vc-endpoints.md index cf52454c2db..61c7057edc6 100644 --- a/book/src/api-vc-endpoints.md +++ b/book/src/api-vc-endpoints.md @@ -18,11 +18,10 @@ HTTP Path | Description | [`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/). - ## `GET /lighthouse/version` Returns the software version and `git` commit hash for the Lighthouse binary. @@ -37,6 +36,7 @@ Returns the software version and `git` commit hash for the Lighthouse binary. | Typical Responses | 200 | Command: + ```bash DATADIR=/var/lib/lighthouse curl -X GET "http://localhost:5062/lighthouse/version" -H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" | jq @@ -44,7 +44,6 @@ curl -X GET "http://localhost:5062/lighthouse/version" -H "Authorization: Bearer Example Response Body: - ```json { "data": { @@ -52,9 +51,11 @@ Example Response Body: } } ``` + > Note: The command provided in this documentation links to the API token file. In this documentation, it is assumed that the API token file is located in `/var/lib/lighthouse/validators/API-token.txt`. If your database is saved in another directory, modify the `DATADIR` accordingly. 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)"`. > As an alternative, you can also provide the API token directly, for example, `-H "Authorization: Bearer api-token-0x02dc2a13115cc8c83baf170f597f22b1eb2930542941ab902df3daadebcb8f8176`. In this case, you obtain the token from the file `API token.txt` and the command becomes: + ```bash curl -X GET "http://localhost:5062/lighthouse/version" -H "Authorization: Bearer api-token-0x02dc2a13115cc8c83baf170f597f22b1eb2930542941ab902df3daadebcb8f8176" | jq ``` @@ -75,6 +76,7 @@ Returns information regarding the health of the host machine. *Note: this endpoint is presently only available on Linux.* Command: + ```bash DATADIR=/var/lib/lighthouse curl -X GET "http://localhost:5062/lighthouse/health" -H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" | jq @@ -133,6 +135,7 @@ Returns information regarding the health of the host machine. | Typical Responses | 200 | Command: + ```bash DATADIR=/var/lib/lighthouse curl -X GET "http://localhost:5062/lighthouse/ui/health" -H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" | jq @@ -178,10 +181,12 @@ Returns the graffiti that will be used for the next block proposal of each valid | Typical Responses | 200 | Command: + ```bash DATADIR=/var/lib/lighthouse curl -X GET "http://localhost:5062/lighthouse/ui/graffiti" -H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" | jq ``` + Example Response Body ```json @@ -323,7 +328,7 @@ Example Response Body ## `GET /lighthouse/auth` 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. +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 file may be read by a local user with access rights. @@ -440,7 +445,6 @@ and `graffiti`. The following example updates a validator from `enabled: true` | Required Headers | [`Authorization`](./api-vc-auth-header.md) | | Typical Responses | 200, 400 | - Example Request Body ```json @@ -458,6 +462,7 @@ curl -X PATCH "http://localhost:5062/lighthouse/validators/0xb0148e6348264131bf4 -H "Content-Type: application/json" \ -d "{\"enabled\":false}" | jq ``` + ### Example Response Body ```json @@ -471,7 +476,6 @@ INFO Disabled validator voting_pubkey: 0xb0148e6348264131bf INFO Modified key_cache saved successfully ``` - ## `POST /lighthouse/validators/` Create any number of new validators, all of which will share a common mnemonic @@ -510,7 +514,8 @@ Validators are generated from the mnemonic according to ] ``` -Command: +Command: + ```bash DATADIR=/var/lib/lighthouse curl -X POST http://localhost:5062/lighthouse/validators \ @@ -625,6 +630,7 @@ Import a keystore into the validator client. We can use [JSON to String Converter](https://jsontostring.com/) so that the above data can be properly presented as a command. The command is as below: Command: + ```bash DATADIR=/var/lib/lighthouse curl -X POST http://localhost:5062/lighthouse/validators/keystore \ @@ -636,6 +642,7 @@ curl -X POST http://localhost:5062/lighthouse/validators/keystore \ As this is an example for demonstration, the above command will return `InvalidPassword`. However, with a keystore file and correct password, running the above command will import the keystore to the validator client. An example of a success message is shown below: ### Example Response Body + ```json { "data": { @@ -759,8 +766,8 @@ Create any number of new validators, all of which will refer to a Some of the fields above may be omitted or nullified to obtain default values (e.g., `graffiti`, `request_timeout_ms`). - Command: + ```bash DATADIR=/var/lib/lighthouse curl -X POST http://localhost:5062/lighthouse/validators/web3signer \ @@ -769,10 +776,8 @@ curl -X POST http://localhost:5062/lighthouse/validators/web3signer \ -d "[{\"enable\":true,\"description\":\"validator_one\",\"graffiti\":\"Mr F was here\",\"suggested_fee_recipient\":\"0xa2e334e71511686bcfe38bb3ee1ad8f6babcc03d\",\"voting_public_key\":\"0xa062f95fee747144d5e511940624bc6546509eeaeae9383257a9c43e7ddc58c17c2bab4ae62053122184c381b90db380\",\"builder_proposals\":true,\"url\":\"http://path-to-web3signer.com\",\"root_certificate_path\":\"/path/to/certificate.pem\",\"client_identity_path\":\"/path/to/identity.p12\",\"client_identity_password\":\"pass\",\"request_timeout_ms\":12000}]" ``` - ### Example Response Body - ```json null ``` @@ -783,7 +788,6 @@ A `null` response indicates that the request is successful. At the same time, `l INFO Enabled validator voting_pubkey: 0xa062f95fee747144d5e511940624bc6546509eeaeae9383257a9c43e7ddc58c17c2bab4ae62053122184c381b90db380, signing_method: remote_signer ``` - ## `GET /lighthouse/logs` Provides a subscription to receive logs as Server Side Events. Currently the diff --git a/book/src/mainnet-validator.md b/book/src/mainnet-validator.md index 942ca09b8ec..c53be97ccf9 100644 --- a/book/src/mainnet-validator.md +++ b/book/src/mainnet-validator.md @@ -1,7 +1,6 @@ # Become an Ethereum Consensus Mainnet Validator [launchpad]: https://launchpad.ethereum.org/ -[lh-book]: https://lighthouse-book.sigmaprime.io/ [advanced-datadir]: ./advanced-datadir.md [license]: https://github.com/sigp/lighthouse/blob/stable/LICENSE [slashing]: ./slashing-protection.md @@ -18,7 +17,6 @@ Being educated is critical to a validator's success. Before submitting your main - Reading through this documentation, especially the [Slashing Protection][slashing] section. - Performing a web search and doing your own research. - > > **Please note**: the Lighthouse team does not take any responsibility for losses or damages > occurred through the use of Lighthouse. We have an experienced internal security team and have @@ -27,7 +25,6 @@ Being educated is critical to a validator's success. Before submitting your main > due to the actions of other actors on the consensus layer or software bugs. See the > [software license][license] for more detail on liability. - ## Become a validator There are five primary steps to become a validator: @@ -39,23 +36,24 @@ There are five primary steps to become a validator: 1. [Submit deposit](#step-5-submit-deposit-32eth-per-validator) > **Important note**: The guide below contains both mainnet and testnet instructions. We highly recommend *all* users to **run a testnet validator** prior to staking mainnet ETH. By far, the best technical learning experience is to run a testnet validator. You can get hands-on experience with all the tools and it's a great way to test your staking -hardware. 32 ETH is a significant outlay and joining a testnet is a great way to "try before you buy". +hardware. 32 ETH is a significant outlay and joining a testnet is a great way to "try before you buy". > **Never use real ETH to join a testnet!** Testnet such as the Holesky testnet uses Holesky ETH which is worthless. This allows experimentation without real-world costs. ### Step 1. Create validator keys The Ethereum Foundation provides the [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli/releases) for creating validator keys. Download and run the `staking-deposit-cli` with the command: + ```bash ./deposit new-mnemonic ``` + and follow the instructions to generate the keys. When prompted for a network, select `mainnet` if you want to run a mainnet validator, or select `holesky` if you want to run a Holesky testnet validator. A new mnemonic will be generated in the process. > **Important note:** A mnemonic (or seed phrase) is a 24-word string randomly generated in the process. It is highly recommended to write down the mnemonic and keep it safe offline. It is important to ensure that the mnemonic is never stored in any digital form (computers, mobile phones, etc) connected to the internet. Please also make one or more backups of the mnemonic to ensure your ETH is not lost in the case of data loss. It is very important to keep your mnemonic private as it represents the ultimate control of your ETH. 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. ### Step 2. Start an execution client and Lighthouse beacon node @@ -64,15 +62,17 @@ Start an execution client and Lighthouse beacon node according to the [Run a Nod ### Step 3. Import validator keys to Lighthouse -In [Step 1](#step-1-create-validator-keys), the staking-deposit-cli will generate the validator keys into a `validator_keys` directory. Let's assume that +In [Step 1](#step-1-create-validator-keys), the staking-deposit-cli will generate the validator keys into a `validator_keys` directory. Let's assume that this directory is `$HOME/staking-deposit-cli/validator_keys`. Using the default `validators` directory in Lighthouse (`~/.lighthouse/mainnet/validators`), run the following command to import validator keys: Mainnet: + ```bash lighthouse --network mainnet account validator import --directory $HOME/staking-deposit-cli/validator_keys ``` Holesky testnet: + ```bash lighthouse --network holesky account validator import --directory $HOME/staking-deposit-cli/validator_keys ``` @@ -85,7 +85,6 @@ lighthouse --network holesky account validator import --directory $HOME/staking- > Docker users should use the command from the [Docker](#docker-users) documentation. - The user will be prompted for a password for each keystore discovered: ``` @@ -122,11 +121,10 @@ WARNING: DO NOT USE THE ORIGINAL KEYSTORES TO VALIDATE WITH ANOTHER CLIENT, OR Y Once you see the above message, you have successfully imported the validator keys. You can now proceed to the next step to start the validator client. - ### Step 4. Start Lighthouse validator client After the keys are imported, the user can start performing their validator duties -by starting the Lighthouse validator client `lighthouse vc`: +by starting the Lighthouse validator client `lighthouse vc`: Mainnet: @@ -135,11 +133,12 @@ lighthouse vc --network mainnet --suggested-fee-recipient YourFeeRecipientAddres ``` Holesky testnet: + ```bash lighthouse vc --network holesky --suggested-fee-recipient YourFeeRecipientAddress ``` -The `validator client` manages validators using data obtained from the beacon node via a HTTP API. You are highly recommended to enter a fee-recipient by changing `YourFeeRecipientAddress` to an Ethereum address under your control. +The `validator client` manages validators using data obtained from the beacon node via a HTTP API. You are highly recommended to enter a fee-recipient by changing `YourFeeRecipientAddress` to an Ethereum address under your control. When `lighthouse vc` starts, check that the validator public key appears as a `voting_pubkey` as shown below: @@ -156,9 +155,9 @@ by the protocol. After you have successfully run and synced the execution client, beacon node and validator client, you can now proceed to submit the deposit. Go to the mainnet [Staking launchpad](https://launchpad.ethereum.org/en/) (or [Holesky staking launchpad](https://holesky.launchpad.ethereum.org/en/) for testnet validator) and carefully go through the steps to becoming a validator. Once you are ready, you can submit the deposit by sending 32ETH per validator to the deposit contract. Upload the `deposit_data-*.json` file generated in [Step 1](#step-1-create-validator-keys) to the Staking launchpad. -> **Important note:** Double check that the deposit contract for mainnet is `0x00000000219ab540356cBB839Cbe05303d7705Fa` before you confirm the transaction. +> **Important note:** Double check that the deposit contract for mainnet is `0x00000000219ab540356cBB839Cbe05303d7705Fa` before you confirm the transaction. -Once the deposit transaction is confirmed, it will take a minimum of ~16 hours to a few days/weeks for the beacon chain to process and activate your validator, depending on the queue. Refer to our [FAQ - Why does it take so long for a validator to be activated](./faq.md#why-does-it-take-so-long-for-a-validator-to-be-activated) for more info. +Once the deposit transaction is confirmed, it will take a minimum of ~16 hours to a few days/weeks for the beacon chain to process and activate your validator, depending on the queue. Refer to our [FAQ - Why does it take so long for a validator to be activated](./faq.md#why-does-it-take-so-long-for-a-validator-to-be-activated) for more info. Once your validator is activated, the validator client will start to publish attestations each epoch: @@ -172,10 +171,11 @@ If you propose a block, the log will look like: Dec 03 08:49:36.225 INFO Successfully published block slot: 98, attestations: 2, deposits: 0, service: block ``` -Congratulations! Your validator is now performing its duties and you will receive rewards for securing the Ethereum network. +Congratulations! Your validator is now performing its duties and you will receive rewards for securing the Ethereum network. ### What is next? -After the validator is running and performing its duties, it is important to keep the validator online to continue accumulating rewards. However, there could be problems with the computer, the internet or other factors that cause the validator to be offline. For this, it is best to subscribe to notifications, e.g., via [beaconcha.in](https://beaconcha.in/) which will send notifications about missed attestations and/or proposals. You will be notified about the validator's offline status and will be able to react promptly. + +After the validator is running and performing its duties, it is important to keep the validator online to continue accumulating rewards. However, there could be problems with the computer, the internet or other factors that cause the validator to be offline. For this, it is best to subscribe to notifications, e.g., via [beaconcha.in](https://beaconcha.in/) which will send notifications about missed attestations and/or proposals. You will be notified about the validator's offline status and will be able to react promptly. 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. @@ -202,9 +202,10 @@ Here we use two `-v` volumes to attach: - `~/.lighthouse` on the host to `/root/.lighthouse` in the Docker container. - The `validator_keys` directory in the present working directory of the host - to the `/root/validator_keys` directory of the Docker container. + to the `/root/validator_keys` directory of the Docker container. ### Start Lighthouse beacon node and validator client + Those using Docker images can start the processes with: ```bash @@ -222,8 +223,5 @@ $ docker run \ lighthouse --network mainnet vc ``` - If you get stuck you can always reach out on our [Discord][discord] or [create an issue](https://github.com/sigp/lighthouse/issues/new). - - diff --git a/book/src/validator-manager-move.md b/book/src/validator-manager-move.md index 5009e6407e9..10de1fe87c6 100644 --- a/book/src/validator-manager-move.md +++ b/book/src/validator-manager-move.md @@ -100,7 +100,7 @@ lighthouse \ > it is recommended for an additional layer of safety. It will result in 2-3 > epochs of downtime for the validator after it is moved, which is generally an > inconsequential cost in lost rewards or penalties. -> +> > Optionally, users can add the `--http-store-passwords-in-secrets-dir` flag if they'd like to have > the import validator keystore passwords stored in separate files rather than in the > `validator-definitions.yml` file. If you don't know what this means, you can safely omit the flag. @@ -158,7 +158,9 @@ Moved keystore 1 of 2 Moved keystore 2 of 2 Done. ``` + At the same time, `lighthouse vc` will log: + ```bash INFO Importing keystores via standard HTTP API, count: 1 INFO Enabled validator voting_pubkey: 0xab6e29f1b98fedfca878edce2b471f1b5ee58ee4c3bd216201f98254ef6f6eac40a53d74c8b7da54f51d3e85cacae92f, signing_method: local_keystore @@ -183,12 +185,13 @@ lighthouse \ ``` > Note: If you have the `validator-monitor-auto` turned on, the source beacon node may still be reporting the attestation status of the validators that have been moved: + ``` INFO Previous epoch attestation(s) success validators: ["validator_index"], epoch: 100000, service: val_mon, service: beacon ``` -> This is fine as the validator monitor does not know that the validators have been moved (it *does not* mean that the validators have attested twice for the same slot). A restart of the beacon node will resolve this. +> This is fine as the validator monitor does not know that the validators have been moved (it *does not* mean that the validators have attested twice for the same slot). A restart of the beacon node will resolve this. Any errors encountered during the operation should include information on how to proceed. Assistance is also available on our -[Discord](https://discord.gg/cyAszAh). \ No newline at end of file +[Discord](https://discord.gg/cyAszAh).