From 73cd1a84fd9b460f7b6479766706f58fea2d7aa3 Mon Sep 17 00:00:00 2001 From: Alon Muroch Date: Tue, 20 Oct 2020 12:00:40 +0300 Subject: [PATCH 1/5] added best practices section according to https://github.com/ethereum/eth2.0-specs/issues/2085 --- specs/phase0/validator.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/specs/phase0/validator.md b/specs/phase0/validator.md index 76dc12142..fb75db2e3 100644 --- a/specs/phase0/validator.md +++ b/specs/phase0/validator.md @@ -604,3 +604,11 @@ 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 +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. From fe5e2f6a8bf31c3d17fc9ef3dbf0641e5ec309f5 Mon Sep 17 00:00:00 2001 From: Alon Muroch Date: Tue, 20 Oct 2020 12:07:54 +0300 Subject: [PATCH 2/5] table of content --- specs/phase0/validator.md | 1 + 1 file changed, 1 insertion(+) diff --git a/specs/phase0/validator.md b/specs/phase0/validator.md index fb75db2e3..b0065dd81 100644 --- a/specs/phase0/validator.md +++ b/specs/phase0/validator.md @@ -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) From 0835c78b56604098ac663e0030ec093e6c73ab4a Mon Sep 17 00:00:00 2001 From: Alon Muroch Date: Tue, 27 Oct 2020 08:38:54 +0200 Subject: [PATCH 3/5] Apply suggestions from Dankrad's code review Co-authored-by: dankrad --- specs/phase0/validator.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/specs/phase0/validator.md b/specs/phase0/validator.md index b0065dd81..4a98a0518 100644 --- a/specs/phase0/validator.md +++ b/specs/phase0/validator.md @@ -607,9 +607,9 @@ Specifically, when signing an `Attestation`, a validator should perform the foll 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. +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. +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. From 5b95219d18b8aa521511340f62d0912c07dc62a7 Mon Sep 17 00:00:00 2001 From: Alon Muroch Date: Wed, 4 Nov 2020 15:19:41 +0200 Subject: [PATCH 4/5] Apply suggestions from code review Co-authored-by: Danny Ryan --- specs/phase0/validator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/phase0/validator.md b/specs/phase0/validator.md index 4a98a0518..4ce4be63a 100644 --- a/specs/phase0/validator.md +++ b/specs/phase0/validator.md @@ -610,6 +610,6 @@ If the software crashes at some point within this routine, then when the validat 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. +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. From 6996a897b5dd170e2a8d6d33cd41ea7cabfc234c Mon Sep 17 00:00:00 2001 From: Alon Muroch Date: Wed, 4 Nov 2020 15:29:06 +0200 Subject: [PATCH 5/5] Apply suggestions from code review Co-authored-by: Danny Ryan --- specs/phase0/validator.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/specs/phase0/validator.md b/specs/phase0/validator.md index 4ce4be63a..902b299fa 100644 --- a/specs/phase0/validator.md +++ b/specs/phase0/validator.md @@ -607,7 +607,9 @@ Specifically, when signing an `Attestation`, a validator should perform the foll 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 beacon node as untrusted. This means that the validator client should protect: + +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.