Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

added best practices section according to https://github.com/ethereum… #2107

Merged
merged 5 commits into from
Nov 4, 2020
Merged

added best practices section according to https://github.com/ethereum… #2107

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
73cd1a8
added best practices section according to https://github.com/ethereum…
alonmuroch Oct 20, 2020
fe5e2f6
table of content
alonmuroch Oct 20, 2020
0835c78
Apply suggestions from Dankrad's code review
alonmuroch Oct 27, 2020
5b95219
Apply suggestions from code review
alonmuroch Nov 4, 2020
6996a89
Apply suggestions from code review
alonmuroch Nov 4, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions specs/phase0/validator.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -65,6 +65,7 @@
- [How to avoid slashing](#how-to-avoid-slashing)
- [Proposer slashing](#proposer-slashing)
- [Attester slashing](#attester-slashing)
- [Protection best practices](#protection-best-practices)

<!-- END doctoc generated TOC please keep comment here to allow auto update -->
<!-- /TOC -->
Expand Down Expand Up @@ -604,3 +605,13 @@ Specifically, when signing an `Attestation`, a validator should perform the foll
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.

## Protection best practices
alonmuroch marked this conversation as resolved.
Show resolved Hide resolved

A validator client should be considered standalone and should consider the beacon node as untrusted. This means that the validator client should protect:

1) Private keys -- private keys should be protected from being exported accidentally or by an attacker.
2) Slashing -- before a validator client signs a message it should validate the data, check it against a local slashing database (do not sign a slashable attestation or block) and update its internal slashing database with the newly signed object.
3) Recovered validator -- Recovering a validator from a private key will result in an empty local slashing db. Best practice is to import (from a trusted source) that validator's attestation history. See [EIP 3076](https://github.com/ethereum/EIPs/pull/3076/files) for a standard slashing interchange format.
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 this message, 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 ejection due to low balance.
A validator client should prevent itself from signing such requests by: a) keeping a local time clock if possible and following best practices to stop time server attacks and b) refusing to sign, by default, any message that has a large (>6h) gap from the current slashing protection database indicated a time "jump" or a long offline event. The administrator can manually override this protection to restart the validator after a genuine long offline event.