Forum
Finance
Specials
On-chain Eco
Entry
Podcasts
Activities
OPRR
Ethereum Distributed Validator Specification
Original title: "Ethereum Distributed Validator Specification"
Original author: Aditya Asgaonkar
Original compilation: ETH Chinese
Introduction
Motivation
Traditional Authenticator Client Setup< /b>
Ethereum validators participate in Proof of Stake (PoS) by signing messages (such as blocks or proofs) with their staked private keys ) agreement. 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 with the traditional validator client setup:
· Staking private keys exist 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 stake private keys to the operator. In order to keep their staked private keys safe, they must trust that operator.
· If the validator client software fails to create timely messages to fulfill the validator's duties, the validator will suffer inactivity and the balance will be reduced.
This may be caused by software crash, network disconnection, hardware failure, etc.
· If the beacon node connected by the verifier client fails, the verifier may follow a fork where a small number of nodes are located, resulting in The rest of the display is offline.
Distributed Validator Protocol
Distribution The Model Validator Protocol provides a solution to mitigate the risks and concerns associated with traditional single validator setups. Additionally, the protocol can be used to implement advanced staking setups, such as decentralized staking pools.
Basic concepts
Please note: Please refer to the glossary for the distributed validator specification Explanation of new terms introduced in . (Translator's Note: See the end of the 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 signing any message.
· M-of-N threshold signatures (threshold signatures): the pledge private key of the verifier is divided into N parts, and each co-verifier holds a share. When at least M co-validators agree on how to vote, they each sign the message with their shares, 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 fashion. Secrets are split into parts called share, these shares can be used to reconstruct the original secret. Decryption through Shamir's Secret Sharing requires a minimum number of shares, which is called the threshold.)
Pass Combining a suitable (safety-biased) consensus algorithm and an M-of-N threshold signature scheme, the DV protocol ensures that consensus is cryptographically guaranteed and that at least M co-validators agree on any decision unanimous.
Resource
Implementation
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.
· ssv: Go implementation of the distributed validator protocol, interacting with the Ethereum client Prysm.
Documentation
· Distributed validators Architecture Video Introduction
Overall Architecture
< img src="https://image.blockbeats.cn/upload/2022-04-18/83b09d33d356993a0a64f413d1caa2fff50b8de7.png?x-oss-process=image/quality,q_50/format,webp">
This specification proposes a method for implementing Distributed Validator Client (DVC) software as a communication between a beacon node and a Remote Signer (RS) Middleware for:
All communication between beacon nodes and remote signers is managed by DVC so that it can provide additional distributed validator functionality .
· Beacon nodes and remote signers are unaware of the existence of the DVC, that is, they think they are connected to each other as usual.
Assumption
· 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 validator client is running securely Usual prerequisites for this include an up-to-date slash-resistant database, correct system clock, etc.
· We are temporarily disregarding votes for the "correct" Ethereum fork - this feature will be added in a future update.
Ideal Guarantee
Security (protection against 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 will never be slashed unless more than two-thirds of the co-validators become defectors .
· Liveness: In a partially synchronized network, unless more than one-third of the co-validators become traitors, the protocol will eventually generate a new proof/block.
Specification
The technical details about the specification are described in src/dvspec/: https ://github.com/ethereum/distributed-validator-specs/blob/dev/src/dvspec.
Glossary
Ethereum concepts
< /p>
· Verifier: The public key that participates in the proof-of-stake Ethereum verification. In phase 0, validators are expected to perform attestation and block proposal responsibilities for beacon chain blocks.
· Validator Client (VC): Software that performs the role of a validator. VC has access to the verifier's private key.
Remote Signer (RS): Software responsible for the management of Ethereum private keys, especially for signing Ethereum messages (e.g. blocks, proofs, etc.) signature. RS runs a server that accepts incoming requests to sign messages of this type.
Cryptography concept
· Private Key Fragmentation (Key Share): as a threshold signature A single key that is part of a scheme.
Signature Share: Signature of some data from a single private key share. Multiple such signature shares need to be combined to generate a complete signature.
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 (Co-Validator): Participate in the DV protocol to become a BLS public key threshold verifier of a specific verifier.
Distributed Validator Client (DVC): By running the DV protocol (or, participating as multiple co-validators, each co-validator identity and different validators) participate in software that becomes a co-validator. DVC has access to the co-validator's private key, which is the corresponding validator's secret shared threshold private key.
Example
Example using the above terms:
< br>
· 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 such that A 3-of-4 threshold signature scheme is established.
More simply, the private key of 0xa5c91... is split into 4 shares, each of which is hosted by one of the co-certifiers , such that at least three of the co-certifiers must cooperate to produce a signature from 0xa5c91... .
Each co-validator is running the distributed validator client software to participate in the distributed validator.
Original link
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
