Read the Ethereum Distributed Validator Specification in One Article
Original title: "Ethereum Distributed Validator Specification"
Originally written by Aditya Asgaonkar
first level title
secondary title
motivation
Traditional validator client setup
Ethereum validators participate in the Proof-of-Stake (PoS) protocol by signing messages (such as blocks or proofs) with their staked private keys. Staking private keys are only accessible through client software, which arranges the creation and signing of messages according to the responsibilities assigned to validators. There are some risks associated with traditional validator client setups:
· The staked private key exists in one place. If an attacker obtained this key, it could create conflicting messages that would result in verification deposits being forfeited.
Stakers who do not run their own validators need to hand over their staking private keys to the operator. In order to keep their staked private keys safe, they must trust that operator.
· If the validator client software cannot create timely messages to fulfill the validator's duties, the validator will suffer inactivity and the balance will be reduced.
This may be due to software crashes, network outages, hardware failures, etc.
· If the beacon node that the validator client is connected to fails, the validator may follow a fork where a small number of nodes are located, resulting in an offline status in other parts of the PoS protocol.
Distributed Validator Protocol
basic concept
basic concept
Please Note: Please refer to the Glossary for explanations of new terms introduced in the Distributed Validator Specification. (Translator's Note: See end of article)
The two basic concepts behind distributed validators are:
Consensus: The responsibilities of a single validator are divided among several co-validators, who must collaborate to agree on how to vote before any message is signed.
· M-of-N threshold signatures: The staking private key of the verifier is divided into N parts, and each co-verifier holds a share. When at least M common validators reach a consensus on how to vote, they use their own shares to sign the message, and a combined signature can be reconstructed from these shares.
PoS Ethereum uses the BLS signature scheme, in which the private key can use M-of-N secret sharing technology (using Shamir's Secret Sharing scheme) to achieve M-of-N threshold signature.
(Translator's Note: Shamir's Secret Sharing is used to protect secrets in a distributed manner. Secrets are divided into multiple parts, these parts are called shares, and these shares can be used to reconstruct the original secret. And through Shamir's Secret Sharing decryption requires a minimum number of shares, known as the threshold.)
accomplish
resource
accomplish
The following are existing implementations of distributed validator technology (but not necessarily implementations of this specification).
python-ssv: A proof-of-concept implementation of a distributed validator protocol in Python, interacting with the Ethereum client Prysm.
document
document
secondary title
Overall architecture
This specification proposes a method for implementing Distributed Validator Client (DVC) software as a middleware between beacon nodes and a Remote Signer (RS):
· All communication between beacon nodes and remote signers is managed by the DVC so that it can provide additional distributed validator functionality.
secondary title
suppose
· We assume that there are a total of N nodes, and an M-of-N threshold signature scheme.
For compatibility with BFT consensus protocols, we assume M = ceil(2 * N / 3).
· This specification assumes some kind of leader-based, safety-oriented consensus protocol, allowing co-validators to choose the same proof/block to sign. We assume that the consensus protocol runs successfully under M correct nodes, and no more than F = (N-1)/3 Byzantine nodes out of N total nodes and no more than N - M - F fail-stop nodes ). (Translator's Note: A Byzantine node refers to a betrayal node that deliberately lies or misleads other nodes in the network.)
We assume that the usual prerequisites for a validator client to run securely include an up-to-date slash-resistant database, correct system clock, etc.
secondary title
ideal guarantee
Security (prevent key theft):
Pledger private keys are safe unless the security of more than M validators out of N co-validators is compromised.
· Security (prevention of slashing):
Under the assumption of an asynchronous network, validators are never slashed unless more than one-third of the co-validators become defectors.
Under the assumption of a synchronous network, validators are never slashed unless more than two-thirds of the co-validators become defectors.
specification
specification
first level title
secondary title
Ethereum concept
Validator: The public key that participates in proof-of-stake Ethereum validation. In Phase 0, validators are expected to perform attestation and block proposal responsibilities for beacon chain blocks.
· Validator Client (Validator Client, VC): software that performs the role of a validator. VC has access to the verifier's private key.
secondary title
Cryptography concepts
Key Share: A single key that is part of a threshold signature scheme.
secondary title
Distributed validator concept
· Distributed Validator (DV): A group of participants collectively perform the duties of a validator. The verifier's private key is shared secretly among multiple participants, so that a complete signature cannot be formed without a certain majority threshold of participants.
· Co-Validator: Participate in the DV protocol to become a BLS public key threshold verifier of a specific verifier.
secondary title
example
Example illustrations using the above terms:
· The Ethereum validator with public key 0xa5c91... is running as a distributed validator.
· There are 4 co-validators participating in the distributed validator for validator 0xa5c91....
· The private key associated with 0xa5c91... is split among the 4 co-certifiers using a 3-of-4 secret sharing scheme, thus establishing a 3-of-4 threshold signature scheme.
More simply, the private key of 0xa5c91... is split into 4 shares, each of which is hosted by one of the co-certifiers, so that at least three of the co-certifiers must cooperate to get the private key from 0xa5c91... Generate a signature.
Original link
