status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

added best practices section according to https://github.com/ethereum/eth2.0-specs/issues/2085

This commit is contained in:
Alon Muroch 2020-10-20 12:00:40 +03:00
parent 0f2fcac133
commit 73cd1a84fd
1 changed files with 8 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
specs/phase0/validator.md
View File

@ -604,3 +604,11 @@ Specifically, when signing an `Attestation`, a validator should perform the foll
2. Generate and broadcast attestation. 2. Generate and broadcast attestation.
If the software crashes at some point within this routine, then when the validator comes back online, the hard disk has the record of the *potentially* signed/broadcast attestation and can effectively avoid slashing. If the software crashes at some point within this routine, then when the validator comes back online, the hard disk has the record of the *potentially* signed/broadcast attestation and can effectively avoid slashing.
## Protection best practices
A validator client should be considered standalone and should consider the node it's connected to as un-trusted. This means that the validator client should protect:
1) Private keys - private keys should be protected from ever being exported out accidentally or by an attacker. Attestations and blocks should be signed internally in the process itself, keys should always be encrypted on disk.
2) Slashing - before a validator client signs an attestation/ block it should validate the data, check against a local slashing db (do not sign slashable attestation/ block) and update its internal slashing db with the new signed object.
3) Recovered validator - Recovering a validator from a private key will result in an empty local slashing db. A best practice is to import (from a trusted source) that validator's attestation history.
4) Far future signing requests - A validator client can be requested to sign a far into the future attestation, resulting in a valid non slashable request. If the validator client signs it will result in it blocking itself from attesting any other attestation until the beacon-chain reaches that far into the future epoch. This will result in an inactivity leak and potential slashing.
A validator client should prevent itself from signing such requests by estimating the current slot with some deviation.