Introduction
Secret Shared Validator (SSV) technology is the first secure and robust way to split a validator key for ETH staking between non-trusting nodes run by operators. It is a unique protocol that enables the distributed operation of an Ethereum validator. The validator key is encrypted, split, and distributed so that no operator has to trust another to perform validator duties, a certain amount can be offline without affecting network performance, and no operator can make unilateral decisions on behalf of a validator. The result is a decentralized, fault-tolerant, highly secure method for staking on Ethereum.
Ethereum Staking & Validators
Ethereum’s new consensus layer (formerly known as Serenity, Ethereum 2.0, and Eth2) represents the blockchain’s transition from Proof of Work (PoW) to Proof of Stake (PoS). When this happens, Ethereum miners will no longer secure the network. Instead, validators owned by those willing to lock-up their Ethereum in a smart contract will perform all network duties in a process called staking.
In the current Ethereum staking ecosystem, in addition to putting 32 ETH at stake, a staker must run a dedicated software validator client along with both a legacy Ethereum node and a Beacon Chain node. This process is technologically complex, making the process of staking Ethereum inaccessible to many people.
Managing Ethereum Validator Keys
Diving a little deeper, when a validator is created, two separate BLS12-381 key pairs will be generated – a Validator key (public and private) and a Withdrawal key (public and private). The withdrawal key is used only to withdraw and transfer staked ETH and should always be stored securely offline. In contrast, the validator key must be online at all times to perform network duties by signing data transactions every ~ 6.4 minutes (an “epoch“). A validator earns small ETH rewards each time it signs the data correctly and on time. However, keeping the validator key online and available presents some connectivity and security challenges for even the most sophisticated users.
Securely storing a validator key while ensuring optimal connectivity and performance is perhaps the biggest pain point for Ethereum stakers and staking service providers. If a validator key goes offline for short periods, the staker risks losing out on opportunities to earn rewards, in addition to receiving minor penalties in subtracted ETH. However, if a validator key goes offline for extended periods, is stored incorrectly, or gets hacked or otherwise compromised, the staker is subject to slashing – penalties in lost ETH they have at stake or their validator being forcibly removed from the network.
The difficulty of managing validator keys has led to the rise of staking services to help streamline the process for end-users. Unfortunately, each staking service is vulnerable to single operator failure, and no staking solution can protect validator keys and optimize uptime and performance with absolute certainty.
Ethereum Staking Services & Associated Risks
Solutions for Ethereum staking range from full-custodial services that retain control of the validator and withdrawal private keys to non-custodial services that provide a staking infrastructure but allow users to maintain control of their private keys. Both have caveats.
Non-custodial services provide optimal security and privacy, but these come at the cost of a more technically challenging user experience. In addition, they are not fault-tolerant and can’t provide active failover for infrastructure components to protect against network-wide disruptions.
Custodial solutions are more convenient and user-friendly yet introduce the risk of severe slashing penalties, potential hacks, and centralized network control. If a malicious actor gains control of the service, all user keys can be compromised. Or, suppose the service makes a mistake and takes part in a slashable offense. Each validator will be subject to slashing as Ethereum’s anti-correlation rules dictate an exponential increase in penalties as more validators participate in the same event.
Avoiding such scenarios while optimizing for performance is no trivial task. In fact, services and individuals risk downtime and penalties each time they take their systems offline for reboots and routine system maintenance. Given the strict protocol rules, fault tolerance is difficult, if not impossible, to achieve.
Past efforts by operators to implement redundancy by running the duplicate validator keys on different validator clients have resulted in the majority of slashing events to date. Both keys became active simultaneously in response to a call to perform network duties and breached Ethereum protocol rules in these situations.
SSV: The New Age of Staking on Ethereum
Secret Shared Validators (SSV), or Distributed Validator Technology (DVT), is a protocol that encrypts a validator key and splits it into four KeyShares. These KeyShares are distributed to four non-trusting nodes run by operators, delivering a robust, fault-tolerant, active-active redundancy for Ethereum staking.
With SSV, if a KeyShare is unavailable or an operator node is faulty (due to scheduled maintenance, a hack, an error, etc.), the rest of the KeyShares will respond, and the validator will continue its duties without pause.
SSV is fully customizable, opening up the possibility for unique and complex staking configurations that will transform the entire Ethereum staking ecosystem.
History of SSV
SSV, later labeled DVT (Distributed Validator Technology), was originally a research paper conceptualized in collaboration with members of the Ethereum Foundation. At its core, the SSV protocol enables the distributed operation of an Ethereum validator, while ssv.network is the infrastructure layer designed to promote decentralization, diversity, fault tolerance, and resilience in the ETH staking space.
SSV / DVT at a High Level
SSV mitigates risk and reduces failures by combining individual nodes into a robust, decentralized network that can outperform any individual staking service in robustness, uptime, and security. Validators run portions of their validator key (KeyShares) across different staking setups run by independent operators joined together by a consensus layer.
Nodes on the network do not need to trust each other to operate, and the protocol can tolerate an offline or faulty node without affecting validator performance. In addition, no single node can recreate a validator key signature on its own or make unilateral decisions on behalf of a validator, increasing security by an order of magnitude.
SSV is a middle layer between a Beacon Chain node and a validator client. It manages the process of splitting and distributing a validator key and using its KeyShares on multiple nodes to reconstruct a data signature. For optimal security and fault tolerance, a majority of nodes is needed to recreate the key for signing. For example, in an SSV configuration of four nodes, three are needed to recreate a validator key signature. This allows one node to be faulty or offline without affecting the validator.
ssv.network allows operators to configure their node to operate their KeyShares in any way they see fit. They can leverage different validator clients on completely different infrastructures and be anywhere in the world. This allows SSV stakers to diversify their validators (and risk) between different operators, geolocations, validator clients, and other infrastructure vectors. If one of the nodes running a validator is faulty, suffers from poor performance, or commits a slashable offense, SSV will keep validating despite that node’s issues. This is excellent for both validator liveness (uptime) and security.
Layered Infrastructure Design
ssv.network has two distinct layers that allow it to operate:
- SSV Peer to Peer (P2P) network layer
- Ethereum contract layer (for network governance)
SSV Peer to Peer (P2P) Network Layer
The SSV P2P layer is the execution layer. It reads the current operator list and validator KeyShare assignments from the Ethereum smart contracts and operates the validators on the network.
Ethereum Contract Layer for Network Governance
The Ethereum contract layer is crucial for network governance. SSV operators will be assessed and ranked, resulting in a decentralized and transparent network score of their quality, experience, and service. Actions like adding an operator, creating a validator, and distributing fees occur on the contract layer.
DAO Governance
The decision-making component of ssv.network is handled by the SSV DAO and those that vote on proposals. The DAO’s responsibilities are:
- Operator Scoring – On a scale of 0-100%. The score is essential for stakers to decide which operators to use. In addition, DAO governance decisions can remove an operator from the network.
- Network Fee – The network fee is a fee stakers pay to use ssv.network to run their validators. This fee is controlled by the DAO and can be changed by a governance decision.
- Treasury – The DAO is responsible for distributing grant funds to initiatives the community has voted to pass. The DAO also makes other treasury decisions for things like accumulated fees and growth initiatives for the protocol.
- Other Decisions – The DAO decides on key protocol decisions such as the roadmap and programming improvements.
Promoting Validator Liveness and Security
For any staking use case, there are two main concerns:
- Performance: “Liveness” (Uptime)
- Security: Slashing protection + private key protection
Redundancy is critical to protect against validator failure and optimize for performance and security. If one component fails, there must be another that can actively take its place and keep the validator up and running without breach or penalty.
Liveness
In terms of validator performance, an SSV implementation takes advantage of the benefits different systems bring to the table and joins them together. Remarkably, it connects them so that their negative characteristics do not carry weight, and each system actively protects the others. SSV can tolerate some offline nodes while allowing the validator to attest correctly and reap maximum rewards. In this way, some nodes can fail or go offline for maintenance without risk, knowing that the rest of the network is effectively managing the stake.
Security
When a distributed network of nodes securely runs a validator, the chance of breach or slashing decreases significantly. From an accidental slashing standpoint, if one SSV node fails, the others can actively go on without pause. Protecting private keys also becomes much easier.
With SSV, the validator private key can be generated and stored securely offline while the KeyShares that represent it operate the validator.
This is advantageous for two reasons – 1. Stakers retain control of their private keys, avoiding single operator failure and mass slashing penalties; and 2. Theft from a bad actor is much less likely as the private key is not stored online. To have any effect, a bad actor would have to gain access to most of the KeyShares operating an SSV validator, which radically changes the narrative for ETH staking private key security.
By trustlessly splitting a validator key across different systems, SSV presents an Ethereum staking infrastructure solution that reduces reliance on any one component, eliminating single points of failure that might affect validator performance and safety. It simultaneously increases network security by focusing on decentralizing the entire Ethereum protocol.
Who Benefits from SSV?
In a broad sense, the entire Ethereum network, for the resilience and security it brings. More precisely:
- At-home Validators – Splitting one validator across multiple machines or cloud providers delivers redundancy and resilience. It also enables groups of individuals to securely validate together.
- Validators Leveraging Staking Services – Rather than entrusting one staking service with a 32 ETH validator, a staker can divide their stake, optimize rewards, and significantly decrease their risks.
- Staking Pool Participants – SSV enables decentralized staking pools at the operational and withdrawal levels. Banding operators together with SSV helps avoid single operator failure that can affect the staker rewards.
- Staking Services/Infrastructure Providers – Staking services and infrastructure providers can use ssv.network to provide active-active redundancy configurations across all core system components and mitigate risk for their subscribers by eliminating single points of failure.
How SSV Benefits the Ethereum Protocol
Widespread adoption of SSV doesn’t just benefit individual stakers and staking providers. It also strengthens the Ethereum protocol itself. Centralization of ETH staking is a significant risk given the financial and technical burdens of running a validator. They both encourage the use of staking services, the majority of which are centralized.
The dangers of centralized staking for the health of Ethereum as a whole are two-fold – 1. Users must entrust their entire stake to a single operator and risk severe slashing penalties given the protocol’s rules; and 2. The more validators a staking service manages, the larger the ripple effect is across the entire network if they fail as a group. The prospect of simultaneous downtime across large portions of the network can be an invitation for coordinated attacks that can lead to the chain being unable to finalize.
It is important to note that centralized staking services aren’t the only ones to blame for network centralization. Upwards of 70% of validators have traditionally leveraged the same validator client, Prysm. No client is perfect; if many validators use the same one, the network can go down if it fails. This became evident during the first major beacon chain event when an issue with the Prysm client led to missed attestations and block proposals across the entire network. In this case, the chain reached finality, but a different problem could have led to different results.
Promoting Decentralization at Scale
With SSV, the gates have opened for endless possibilities of complementary validator node configurations working together simultaneously. Across the board, staking services, at-home validators, infrastructure providers, and groups working together can reduce their risk and strengthen Ethereum by building customizable and unique SSV networks.
Centralized services can now offer decentralized services making this is a win-win scenario for all parties! By joining forces with others on ssv.network they safeguard themselves and their users from centralized staking risks and protect the network by reducing the potential negative effects if one component fails. If a prominent centralized service goes offline, the whole network will continue to function properly as the other operators in their SSV node cluster will back them up.
Finally, touching on the diversity of other components (such as validator clients and cloud providers), SSV promotes using varying components without the challenge of implementing active-passive redundancy. By joining ssv.network, a staker or staking service can easily leverage many different elements at once. Widespread adoption of SSV will significantly contribute to the diversified use of these components, mitigate centralization, and protect against network-wide failures.
SSV Technical Overview
For more details on the inner workings of SSV, check out the SSV Primer.
If you look under the hood, SSV is a sophisticated multisignature wallet with a consensus layer. It is a middle layer between a Beacon Chain node and a validator client. From a user’s perspective, it is simply a component to set and forget as it takes care of everything on their behalf.
The main components of an SSV configuration are as follows:
Distributed Key Generation
A cryptographic process that generates a shared public and private key set, as calculated by the operators running an SSV node. Each operator owns a single portion of the private key (KeyShare), ensuring that no single operator can affect or have control over the entire private key and make unilateral decisions on behalf of a validator.
Shamir Secret Sharing
Eth2 validator keys use BLS signatures. BLS signatures are additive, allowing multiple signatures to be combined to recreate a validator key signature. This allows for the use of Shamir Secret Sharing, a mechanism used to reconstruct a validator key using a predefined threshold of KeyShares. Individual KeyShares cannot be used to sign a duty, yet not all are needed if some are faulty, as described by n≥3f+1.
Multi-Party Computation
Applying secure Multi-Party Computation (MPC) to secret sharing allows KeyShares to be distributed to operators securely and perform decentralized computation of validator duties without reconstructing the validator key on a single device.
Istanbul Byzantine Fault Tolerance Consensus
The consensus layer of SSV is based on the Istanbul Byzantine Fault Tolerance (IBFT) algorithm and ties everything together. The algorithm randomly selects a validator node (KeyShare) responsible for a block proposal and shares the information with the other nodes. Once the predefined threshold of KeyShares deems the block valid, it is added to the chain. As such, consensus can be reached even if some operators are faulty or not currently online.
Conclusion
At its core, SSV is a way to reduce failures and diversify risk by combining independent SSV nodes into a robust network that can outperform any individual ETH staking setup. With regard to security, robustness, performance and validator uptime, SSV will improve ETH rewards for stakers, increase network decentralization, and significantly reduce staking risks for all.