From 6996a897b5dd170e2a8d6d33cd41ea7cabfc234c Mon Sep 17 00:00:00 2001 From: Alon Muroch Date: Wed, 4 Nov 2020 15:29:06 +0200 Subject: [PATCH] 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.