mirror of
https://github.com/sigp/lighthouse.git
synced 2026-05-07 00:42:42 +00:00
chonghe
125
book/src/faq.md
125
book/src/faq.md
@@ -17,7 +17,6 @@
|
||||
|
||||
## [Validator](#validator-1)
|
||||
|
||||
- [Why does it take so long for a validator to be activated?](#vc-activation)
|
||||
- [Can I use redundancy in my staking setup?](#vc-redundancy)
|
||||
- [I am missing attestations. Why?](#vc-missed-attestations)
|
||||
- [Sometimes I miss the attestation head vote, resulting in penalty. Is this normal?](#vc-head-vote)
|
||||
@@ -112,10 +111,7 @@ After checkpoint forwards sync completes, the beacon node will start to download
|
||||
INFO Downloading historical blocks est_time: --, distance: 4524545 slots (89 weeks 5 days), service: slot_notifier
|
||||
```
|
||||
|
||||
If the same log appears every minute and you do not see progress in downloading historical blocks, you can try one of the followings:
|
||||
|
||||
- Check the number of peers you are connected to. If you have low peers (less than 50), try to do port forwarding on the ports 9000 TCP/UDP and 9001 UDP to increase peer count.
|
||||
- Restart the beacon node.
|
||||
If the same log appears every minute and you do not see progress in downloading historical blocks, check the number of peers you are connected to. If you have low peers (less than 50), try to do port forwarding on the ports 9000 TCP/UDP and 9001 UDP to increase peer count.
|
||||
|
||||
### <a name="bn-duplicate"></a> I proposed a block but the beacon node shows `could not publish message` with error `duplicate` as below, should I be worried?
|
||||
|
||||
@@ -154,29 +150,13 @@ This is a normal behaviour. Since [v4.1.0](https://github.com/sigp/lighthouse/re
|
||||
|
||||
### <a name="bn-http"></a> My beacon node logs `WARN Error processing HTTP API request`, what should I do?
|
||||
|
||||
This warning usually comes with an http error code. Some examples are given below:
|
||||
An example of the log is shown below
|
||||
|
||||
1. The log shows:
|
||||
```text
|
||||
WARN Error processing HTTP API request method: GET, path: /eth/v1/validator/attestation_data, status: 500 Internal Server Error, elapsed: 305.65µs
|
||||
```
|
||||
|
||||
```text
|
||||
WARN Error processing HTTP API request method: GET, path: /eth/v1/validator/attestation_data, status: 500 Internal Server Error, elapsed: 305.65µs
|
||||
```
|
||||
|
||||
The error is `500 Internal Server Error`. This suggests that the execution client is not synced. Once the execution client is synced, the error will disappear.
|
||||
|
||||
1. The log shows:
|
||||
|
||||
```text
|
||||
WARN Error processing HTTP API request method: POST, path: /eth/v1/validator/duties/attester/199565, status: 503 Service Unavailable, elapsed: 96.787µs
|
||||
```
|
||||
|
||||
The error is `503 Service Unavailable`. This means that the beacon node is still syncing. When this happens, the validator client will log:
|
||||
|
||||
```text
|
||||
ERRO Failed to download attester duties err: FailedToDownloadAttesters("Some endpoints failed, num_failed: 2 http://localhost:5052/ => Unavailable(NotSynced), http://localhost:5052/ => RequestFailed(ServerMessage(ErrorMessage { code: 503, message: \"SERVICE_UNAVAILABLE: beacon node is syncing
|
||||
```
|
||||
|
||||
This means that the validator client is sending requests to the beacon node. However, as the beacon node is still syncing, it is therefore unable to fulfil the request. The error will disappear once the beacon node is synced.
|
||||
This warning usually happens when the validator client sends a request to the beacon node, but the beacon node is unable to fulfil the request. This can be due to the execution client is not synced/is syncing and/or the beacon node is syncing. The error show go away when the node is synced.
|
||||
|
||||
### <a name="bn-fork-choice"></a> My beacon node logs `WARN Error signalling fork choice waiter`, what should I do?
|
||||
|
||||
@@ -190,13 +170,21 @@ This suggests that the computer resources are being overwhelmed. It could be due
|
||||
|
||||
### <a name="bn-queue-full"></a> My beacon node logs `ERRO Aggregate attestation queue full`, what should I do?
|
||||
|
||||
An example of the full log is shown below:
|
||||
Some examples of the full log is shown below:
|
||||
|
||||
```text
|
||||
ERRO Aggregate attestation queue full, queue_len: 4096, msg: the system has insufficient resources for load, module: network::beacon_processor:1542
|
||||
ERRO Attestation delay queue is full msg: system resources may be saturated, queue_size: 16384, service: bproc
|
||||
```
|
||||
|
||||
This suggests that the computer resources are being overwhelmed. It could be due to high CPU usage or high disk I/O usage. This can happen, e.g., when the beacon node is downloading historical blocks, or when the execution client is syncing. The error will disappear when the resources used return to normal or when the node is synced.
|
||||
This suggests that the computer resources are being overwhelmed. It could be due to high CPU usage or high disk I/O usage. Some common reasons are:
|
||||
|
||||
- when the beacon node is downloading historical blocks
|
||||
- the execution client is syncing
|
||||
- disk IO is being overwhelmed
|
||||
- parallel API queries to the beacon node
|
||||
|
||||
If the node is syncing or downloading historical blocks, the error should disappear when the resources used return to normal or when the node is synced.
|
||||
|
||||
### <a name="bn-deposit-cache"></a> My beacon node logs `WARN Failed to finalize deposit cache`, what should I do?
|
||||
|
||||
@@ -204,77 +192,6 @@ This is a known [bug](https://github.com/sigp/lighthouse/issues/3707) that will
|
||||
|
||||
## Validator
|
||||
|
||||
### <a name="vc-activation"></a> Why does it take so long for a validator to be activated?
|
||||
|
||||
After validators create their execution layer deposit transaction there are two waiting
|
||||
periods before they can start producing blocks and attestations:
|
||||
|
||||
1. Waiting for the beacon chain to recognise the execution layer block containing the
|
||||
deposit (generally takes ~13.6 hours).
|
||||
1. Waiting in the queue for validator activation.
|
||||
|
||||
Detailed answers below:
|
||||
|
||||
#### 1. Waiting for the beacon chain to detect the execution layer deposit
|
||||
|
||||
Since the beacon chain uses the execution layer for validator on-boarding, beacon chain
|
||||
validators must listen to event logs from the deposit contract. Since the
|
||||
latest blocks of the execution chain are vulnerable to re-orgs due to minor network
|
||||
partitions, beacon nodes follow the execution chain at a distance of 2048 blocks
|
||||
(~6.8 hours) (see
|
||||
[`ETH1_FOLLOW_DISTANCE`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/validator.md#process-deposit)).
|
||||
This follow distance protects the beacon chain from on-boarding validators that
|
||||
are likely to be removed due to an execution chain re-org.
|
||||
|
||||
Now we know there's a 6.8 hours delay before the beacon nodes even _consider_ an
|
||||
execution layer block. Once they _are_ considering these blocks, there's a voting period
|
||||
where beacon validators vote on which execution block hash to include in the beacon chain. This
|
||||
period is defined as 64 epochs (~6.8 hours, see
|
||||
[`ETH1_VOTING_PERIOD`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#time-parameters)).
|
||||
During this voting period, each beacon block producer includes an
|
||||
[`Eth1Data`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#eth1data)
|
||||
in their block which counts as a vote towards what that validator considers to
|
||||
be the head of the execution chain at the start of the voting period (with respect
|
||||
to `ETH1_FOLLOW_DISTANCE`, of course). You can see the exact voting logic
|
||||
[here](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/validator.md#eth1-data).
|
||||
|
||||
These two delays combined represent the time between an execution layer deposit being
|
||||
included in an execution data vote and that validator appearing in the beacon chain.
|
||||
The `ETH1_FOLLOW_DISTANCE` delay causes a minimum delay of ~6.8 hours and
|
||||
`ETH1_VOTING_PERIOD` means that if a validator deposit happens just _before_
|
||||
the start of a new voting period then they might not notice this delay at all.
|
||||
However, if the validator deposit happens just _after_ the start of the new
|
||||
voting period the validator might have to wait ~6.8 hours for next voting
|
||||
period. In times of very severe network issues, the network may even fail
|
||||
to vote in new execution layer blocks, thus stopping all new validator deposits and causing the wait to be longer.
|
||||
|
||||
#### 2. Waiting for a validator to be activated
|
||||
|
||||
If a validator has provided an invalid public key or signature, they will
|
||||
_never_ be activated.
|
||||
They will simply be forgotten by the beacon chain! But, if those parameters were
|
||||
correct, once the execution layer delays have elapsed and the validator appears in the
|
||||
beacon chain, there's _another_ delay before the validator becomes "active"
|
||||
(canonical definition
|
||||
[here](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#is_active_validator)) and can start producing blocks and attestations.
|
||||
|
||||
Firstly, the validator won't become active until their beacon chain balance is
|
||||
equal to or greater than
|
||||
[`MAX_EFFECTIVE_BALANCE`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#gwei-values)
|
||||
(32 ETH on mainnet, usually 3.2 ETH on testnets). Once this balance is reached,
|
||||
the validator must wait until the start of the next epoch (up to 6.4 minutes)
|
||||
for the
|
||||
[`process_registry_updates`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#registry-updates)
|
||||
routine to run. This routine activates validators with respect to a [churn
|
||||
limit](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#get_validator_churn_limit);
|
||||
it will only allow the number of validators to increase (churn) by a certain
|
||||
amount. If a new validator isn't within the churn limit from the front of the queue,
|
||||
they will need to wait another epoch (6.4 minutes) for their next chance. This
|
||||
repeats until the queue is cleared. The churn limit for validators joining the beacon chain is capped at 8 per epoch or 1800 per day. If, for example, there are 9000 validators waiting to be activated, this means that the waiting time can take up to 5 days.
|
||||
|
||||
Once a validator has been activated, congratulations! It's time to
|
||||
produce blocks and attestations!
|
||||
|
||||
### <a name="vc-redundancy"></a> Can I use redundancy in my staking setup?
|
||||
|
||||
You should **never** use duplicate/redundant validator keypairs or validator clients (i.e., don't
|
||||
@@ -299,15 +216,15 @@ Another cause for missing attestations is the block arriving late, or there are
|
||||
An example of the log: (debug logs can be found under `$datadir/beacon/logs`):
|
||||
|
||||
```text
|
||||
Delayed head block, set_as_head_time_ms: 27, imported_time_ms: 168, attestable_delay_ms: 4209, available_delay_ms: 4186, execution_time_ms: 201, blob_delay_ms: 3815, observed_delay_ms: 3984, total_delay_ms: 4381, slot: 1886014, proposer_index: 733, block_root: 0xa7390baac88d50f1cbb5ad81691915f6402385a12521a670bbbd4cd5f8bf3934, service: beacon, module: beacon_chain::canonical_head:1441
|
||||
DEBG Delayed head block, set_as_head_time_ms: 37, imported_time_ms: 1824, attestable_delay_ms: 3660, available_delay_ms: 3491, execution_time_ms: 78, consensus_time_ms: 161, blob_delay_ms: 3291, observed_delay_ms: 3250, total_delay_ms: 5352, slot: 11429888, proposer_index: 778696, block_root: 0x34cc0675ad5fd052699af2ff37b858c3eb8186c5b29fdadb1dabd246caf79e43, service: beacon, module: beacon_chain::canonical_head:1440
|
||||
```
|
||||
|
||||
The field to look for is `attestable_delay`, which defines the time when a block is ready for the validator to attest. If the `attestable_delay` is greater than 4s which has past the window of attestation, the attestation will fail. In the above example, the delay is mostly caused by late block observed by the node, as shown in `observed_delay`. The `observed_delay` is determined mostly by the proposer and partly by your networking setup (e.g., how long it took for the node to receive the block). Ideally, `observed_delay` should be less than 3 seconds. In this example, the validator failed to attest the block due to the block arriving late.
|
||||
The field to look for is `attestable_delay`, which defines the time when a block is ready for the validator to attest. If the `attestable_delay` is greater than 4s then it has missed the window for attestation, and the attestation will fail. In the above example, the delay is mostly caused by a late block observed by the node, as shown in `observed_delay`. The `observed_delay` is determined mostly by the proposer and partly by your networking setup (e.g., how long it took for the node to receive the block). Ideally, `observed_delay` should be less than 3 seconds. In this example, the validator failed to attest to the block due to the block arriving late.
|
||||
|
||||
Another example of log:
|
||||
|
||||
```
|
||||
DEBG Delayed head block, set_as_head_time_ms: 22, imported_time_ms: 312, attestable_delay_ms: 7052, available_delay_ms: 6874, execution_time_ms: 4694, blob_delay_ms: 2159, observed_delay_ms: 2179, total_delay_ms: 7209, slot: 1885922, proposer_index: 606896, block_root: 0x9966df24d24e722d7133068186f0caa098428696e9f441ac416d0aca70cc0a23, service: beacon, module: beacon_chain::canonical_head:1441
|
||||
DEBG Delayed head block, set_as_head_time_ms: 22, imported_time_ms: 312, attestable_delay_ms: 7052, available_delay_ms: 6874, execution_time_ms: 4694, consensus_time_ms: 232, blob_delay_ms: 2159, observed_delay_ms: 2179, total_delay_ms: 7209, slot: 1885922, proposer_index: 606896, block_root: 0x9966df24d24e722d7133068186f0caa098428696e9f441ac416d0aca70cc0a23, service: beacon, module: beacon_chain::canonical_head:1441
|
||||
/159.69.68.247/tcp/9000, service: libp2p, module: lighthouse_network::service:1811
|
||||
```
|
||||
|
||||
@@ -323,7 +240,7 @@ Another possible reason for missing the head vote is due to a chain "reorg". A r
|
||||
|
||||
### <a name="vc-exit"></a> Can I submit a voluntary exit message without running a beacon node?
|
||||
|
||||
Yes. Beaconcha.in provides the tool to broadcast the message. You can create the voluntary exit message file with [ethdo](https://github.com/wealdtech/ethdo/releases/tag/v1.30.0) and submit the message via the [beaconcha.in](https://beaconcha.in/tools/broadcast) website. A guide on how to use `ethdo` to perform voluntary exit can be found [here](https://github.com/eth-educators/ethstaker-guides/blob/main/docs/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) 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/validator_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.
|
||||
|
||||
@@ -345,7 +262,7 @@ If you do not want to stop `lighthouse vc`, you can use the [key manager API](./
|
||||
|
||||
### <a name="vc-delete"></a> How can I delete my validator once it is imported?
|
||||
|
||||
Lighthouse supports the [KeyManager API](https://ethereum.github.io/keymanager-APIs/#/Local%20Key%20Manager/deleteKeys) to delete validators and remove them from the `validator_definitions.yml` file. To do so, start the validator client with the flag `--http` and call the API.
|
||||
You can use the `lighthouse vm delete` command to delete validator keys, see [validator manager delete](./validator_manager_api.md#delete).
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user