Update README (#9)

Update README for clarity

Co-authored-by: Carl Beekhuizen <[email protected]>

Author: adiasg

README.md

@@ -1,32 +1,76 @@
 # Ethereum Distributed Validator Specification
 
-Distributed Validators allow for implementing an Ethereum validator using a set of distributed nodes in a way that improves the resilience as compared to running a client on a single machine.
+Distributed Validators (DV) are a technique for distributing the job of an Ethereum validator among a set of distributed nodes in order to improve resilience (safety, liveness, or both) as compared to running a validator client on a single machine.
 
 ## Introduction
 
-![General Architecture](figures/general-architecture.png)
+### Motivation
 
-This specification presents a way to implement Distributed Validator software as middleware between the Beacon Node and Validator Client. 
+#### Traditional Validator Client Setup
+Ethereum validators participate in the [proof-of-stake (PoS) protocol](https://github.com/ethereum/consensus-specs) by signing messages (such as blocks or attestations) using their staking private key. The staking key is accessible only by the validator client software, which schedules the creation & signing of messages according to the duties assigned to the validator. Some risks involved in a traditional validator client setup are:
+- The staking private key resides in one location. If an adversary gains access to this key, it can create conflicting messages that result in slashing of the validator's deposit.
+    - Stakers who do not operate their own validator need to hand over their staking private key to the operator. They must trust the operator for the security of their staking private key.
+- If the validator client software is unable to create timely messages to perform validator duties, the validator suffers an inactivity leak that reduces its balance.
+    - This could happen due to causes such as software crashes, loss of network connection, hardware faults, etc.
+- If the Beacon Node to which the validator client is connected has a fault, a validator may end up following a minority fork resulting it appearing to be offline to the rest of the PoS protocol.
 
-### Desired Guarantees
-- Safety: Validator is never slashed unless `X` fraction of the Validator Client nodes are Byzantine, even under asynchronous network
-- No Deadlock: The protocol never ends up in a deadlock state where no progress can be made
-- Liveness: The protocol will eventually produce a new attestation/block, under partially synchronous network
+#### Distributed Validator Protocol
+The Distributed Validator protocol presents a solution to mitigate the risks & concerns associated with traditional, single Validator Client setups. In addition, this protocol can be used to enable advanced staking setups such as decentralized staking pools.
+
+### Basic Concepts
+
+The two fundamental concepts behind Distributed Validators are:
+- **consensus**: the responsibilities of a single validator are split among several co-validators, who must work together to reach agreement on how to vote before signing any message.
+- ***M-of-N* threshold signatures**: the validator's staking key is split into *N* pieces and each of the co-validators holds a share. When at least *M* of the co-validators reach consensus on how to vote, they each sign the message with their share and a combined signature can be reconstructed from the shares.
+
+Ethereum proof-of-stake uses the BLS signature scheme, in which the private keys can be *M-of-N* secret-shared to implement *M-of-N* threshold signatures.
+
+**Note**: Refer to the [glossary](glossary.md) for an explanation of new terms introduced in the Distributed Validator specifications.
+
+By combining a suitable (safety-favouring) consensus algorithm with an *M-of-N* threshold signature scheme, the DV protocol ensures that agreement is backed up by cryptography and at least *M* co-validators agree about any decision.
+
+### Resources
+
+#### Implementations
+
+The following are existing implementations of DIstributed Validator technology (but not necessarily implementations of this specification).
+
+- [`python-ssv`](https://github.com/dankrad/python-ssv): A proof-of-concept implementation of the distributed validator protocol in Python that interacts with the [Prysm Ethereum client](https://github.com/prysmaticlabs/prysm).
+- [`ssv`](https://github.com/bloxapp/ssv): An implementation of the distributed validator protocol in Go that interacts with the [Prysm Ethereum client](https://github.com/prysmaticlabs/prysm).
+
+#### Documents
+- [Distributed Validator Architecture Video Introduction](https://www.youtube.com/watch?v=awBX1SrXOhk)
+
+### General Architecture
+
+![General Architecture](figures/general-architecture.png)
+
+This specification presents a way to implement Distributed Validator Client software as middleware between the Beacon Node (BN) and Validator Client (VC):
+- all communication between the BN and VC is intercepted by the DVC in order for it to provide the additional DV functionality.
+- the BN & VC are unaware of the presence of the DVC, i.e., they think they are connected to each other as usual.
 
 ### Assumptions
-- This specification assumes [some leader-based consensus protocol](src/dvspec/consensus.py) for the DV nodes to decide on signing upon the same attestation/block.
+- We assume *N* total nodes and an *M-of-N* threshold signature scheme.
+    - For general compatibility with BFT consensus protocols, we assume that `M = (2 * N / 3) + 1`.
+- This specification assumes [some leader-based safety-favoring consensus protocol](src/dvspec/consensus.py) for the Co-Validators to decide on signing upon the same attestation/block. We assume that the consensus protocol runs successfully with *M* correct nodes out of *N* total nodes.
+- We assume the usual prerequisites for safe operation of the Validator Client, such as an up-to-date anti-slashing database, correct system clock, etc.
 - We disregard the voting on the "correct" Ethereum fork for now - this functionality will be added in a future update.
 
-### Design Rationale
-- Validity of attestation data must be checked against the slashing DB at the beginning of the consensus process
-- If the consensus process returns an attestation, then the slashing DB must allow it at that time
-- There can only be one consensus process running at any given moment
-- Slashing DB cannot be updated when a consensus process is running
-- Consensus processes for attestation duties must be spawned in increasing order of slot
+### Desired Guarantees
+- **Safety (against key theft)**:
+    - The Validator's staking private key is secure unless security is compromised at more than *M* of the *N* Co-Validators.
+- **Safety (against slashing)**: 
+    - Under the assumption of an asynchronous network, the Validator is never slashed unless more than 2/3rd of the Co-Validators are Byzantine.
+    - Under the assumption of a synchronous network, the Validator is never slashed unless more than 1/3rd of the Co-Validators are Byzantine.
+- **Liveness**: The protocol will eventually produce a new attestation/block under partially synchronous network unless more than 1/3rd of the Co-Validators are Byzantine.
 
 ## Spec
 
-The distributed validator [specification](src/dvspec/spec.py) defines the behavior of the distributed validator regarding attestation & block production processes. It utilizes the [standard Ethereum node interface](src/dvspec/eth_node_interface.py) to communicate with the associated Beacon Node & Validator Client.
+The specifications are organized as follows:
+- The [distributed validator specification](src/dvspec/spec.py) defines the behavior of a Co-Validator regarding attestation & block production processes.
+- The [Ethereum node interface](src/dvspec/eth_node_interface.py) describes the interface to communicate with the associated Beacon Node & Validator Client.
+- The [consensus specification](src/dvspec/consensus.py) describes the basic structure for the consensus protocol used between Co-Validators.
+- The [networking specification](src/dvspec/networking.py) defines the required networking logic between Distributed Validator Clients.
 
 ### Attestation Production Process
 

figures/general-architecture.png

@@ -9,4 +9,13 @@
 
 - **Distributed Validator (DV)**: A group of participants collboratively performing the duties of a Validator. The Validator's private key is secret-shared among the participants so that a complete signature cannot be formed without some majority threshold of participants.
 - **Co-Validator**: A threshold BLS public key participating in the DV protocol for a *particular* Validator.
-- **Distributed Validator Client (DVC)**: Software to participate as a Co-Validator by running the DV protocol (or, to participate as multiple Co-Validators that are each associated with a different Validator). The DVC has access to the private key(s) of the Co-Validator(s), which is(are) the secret-shared threshold private key of the respective Validator(s).
+- **Distributed Validator Client (DVC)**: Software to participate as a Co-Validator by running the DV protocol (or, to participate as multiple Co-Validators that are each associated with a different Validator). The DVC has access to the private key(s) of the Co-Validator(s), which is(are) the secret-shared threshold private key of the respective Validator(s).
+
+## Example
+
+An illustrative example for usage of terms described above:
+- Ethereum Validator with pubkey `0xa5c91...` is operated as a Distributed Validator.
+- 4 Co-Validators are participating in the Distributed Validator for Validator `0xa5c91...`. 
+- The private key associated with `0xa5c91...` is split using *3-of-4* secret-sharing among the 4 Co-Validators such that a *3-of-4* threshold signature scheme is setup.
+    - In simpler terms, the private key for `0xa5c91...` is split into 4 pieces, each in the custody of one of the Co-Validators such that at least 3 of them have to collaborate to produce a signature from `0xa5c91...`.
+- Each Co-Validator is running the Distributed Validator Client software to participate the in the Distributed Validator.