gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-04-16 12:28:24 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update Lighthouse book Sec 3-6 and FAQ (#4221)

Browse Source 
## Issue Addressed

Update Lighthouse book to include latest information especially after Capella upgrade

## Proposed Changes

Notable changes:
- Combine Sec 4.1 & 6.1 into Sec 4, because Sec 6.1 is importing validator key which is a required step when want to run a validator
- Combine Sec 5.1 & 5.2 with Sec 5, and move Sec 5 to under Sec 9
- Added partial withdrawals in Sec 6



## Additional Info

Please provide any additional information. For example, future considerations
or information useful for reviewers.


Co-authored-by: chonghe <tanck2005@gmail.com>
This commit is contained in:
chonghe
2023-05-05 00:51:56 +00:00
parent b1416c8a43
commit 45835f6a6b
21 changed files with 522 additions and 604 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
book/src/validator-doppelganger.md
View File

@@ -16,8 +16,7 @@ achieves this by staying silent for 2-3 epochs after a validator is started so i
other instances of that validator before starting to sign potentially slashable messages.
> Note: Doppelganger Protection is not yet interoperable, so if it is configured on a Lighthouse
> validator client, the client must be connected to a Lighthouse beacon node. Because Infura
> uses Teku, Lighthouse's Doppelganger Protection cannot yet be used with Infura's Eth2 service.
> validator client, the client must be connected to a Lighthouse beacon node.
## Initial Considerations
@@ -30,9 +29,9 @@ is no guarantee that your Beacon Node (BN) will see messages from it. **It is fe
doppelganger protection to fail to detect another validator due to network faults or other common
circumstances.**
DP should be considered a last-line-of-defence that *might* save a validator from being slashed due
DP should be considered as a last-line-of-defence that *might* save a validator from being slashed due
to operator error (i.e. running two instances of the same validator). Users should
*never* rely upon DP and should practice the same caution with regards to duplicating validators as
*never* rely upon DP and should practice the same caution with regard to duplicating validators as
if it did not exist.
**Remember: even with doppelganger protection enabled, it is not safe to run two instances of the
@@ -44,7 +43,7 @@ DP works by staying silent on the network for 2-3 epochs before starting to sign
Staying silent and refusing to sign messages will cause the following:
- 2-3 missed attestations, incurring penalties and missed rewards.
- 2-3 epochs of missed sync committee contributions (if the validator is in a sync committee, which is unlikely), incurring penalties and missed rewards (post-Altair upgrade only).
- 2-3 epochs of missed sync committee contributions (if the validator is in a sync committee, which is unlikely), incurring penalties and missed rewards.
- Potentially missed rewards by missing a block proposal (if the validator is an elected block
proposer, which is unlikely).
@@ -105,7 +104,7 @@ there is no other instance of that validator running elsewhere!**
The steps to solving a doppelganger vary depending on the case, but some places to check are:
1. Is there another validator process running on this host?
- Unix users can check `ps aux | grep lighthouse`
- Unix users can check by running the command `ps aux | grep lighthouse`
- Windows users can check the Task Manager.
1. Has this validator recently been moved from another host? Check to ensure it's not running.
1. Has this validator been delegated to a staking service?