Secret Shared Validator (SSV) technology is the first secure and robust way to split a validator key for ETH staking between non-trusting nodes, or operators. It is a unique protocol that enables the distributed control and operation of an Ethereum validator. The validator key is encrypted, split and distributed in such a way that no operator must trust another to perform validator duties,, a certain amount can be offline without affecting network performance, and no operator can take unilateral control of a validator or the network. The result is a decentralized, fault tolerant, and 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 a Proof of Work (PoW) to a Proof of Stake (PoS) consensus mechanism. When this happens, Ethereum miners will no longer secure the network. Instead, “validators” owned by those willing to lock-up their Ethereum in a process called “staking” will perform all network duties.
In the current Ethereum staking ecosystem, in addition to putting 32 ETH at stake, one must run a dedicated software (validator client, and run both a legacy Ethereum node and beacon chain node. As a result, the process of staking Ethereum can be too technologically complex for many individuals.
Managing Ethereum Validator Keys
Diving a little deeper, a validator will generate 2 separate BLS12-381 key pairs -a Validator key (public and private) and a Withdrawal key (public and private). The withdrawal key is solely used to withdraw and transfer staked ETH and should always be stored securely offline. In contrast, the validator key performs network duties by signing data once every ~ 6.4 minutes (an “epoch”), and must be online at all times. In return for signing the data both correctly and in a timely manner , the validator is rewarded with a small amount of ETH However, keeping the validator key online and available at all times has presented a number of connectivity and security challenges for even the most sophisticated operators on the network.
Securely storing validator keys while ensuring optimal connectivity and performance is, perhaps, the biggest pain point for Ethereum stakers and staking service providers. If a validator key gets hacked or otherwise compromised, goes offline for extended periods, or is stored incorrectly, the staker risks penalties in lost ETH they have at stake, in addition to the validator being forcibly removed from the network. This is known as slashing. If a validator key goes offline for short periods, a staker risks losing out on opportunities to earn ETH, in addition to receiving minor penalties.
The difficulty of managing a validator and its and associated keys has led to the rise of staking services to help streamline the process of Ethereum staking for end users. Unfortunately, each staking service in existence today is vulnerable to single operator failure – simply put, there is no staking solution that can protect users’ validator keys and optimize uptime and performance with absolute certainty.
Ethereum Staking Services & Associated Risks
Solutions for Ethereum staking range from fully-custodial services that retain unilateral operative control of both private keys to non-custodial services that provide the staking infrastructure while allowing users to retain control of their private keys.. Both have caveats. Non-custodial services provide optimal security and privacy, yet come at the cost of a more technically challenging user experience. In addition, they cannot currently implement active failover for infrastructure components or protect against network-wide disruptions more on that below).
Custodial solutions are more convenient and user-friendly, yet introduce the risk of severe slashing penalties, potential hacks, and centralized control of the network. If a malicious actor gains control of the service, all user keys can become compromised. And, if the service makes a mistake and takes part in a slashable offense, each validator will be punished with great severity due to 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, hacks, and slashings just by performing routine system maintenance! Given strict protocol rules, active-active redundancy (having active failover in place as a backup if some part of a system goes down) is difficult, if not impossible to achieve. Operators have found that switching from active to passive solutions while performing maintenance tasks can be a stress-inducing task to say the least.
Additionally, efforts by operators to implement active-active redundancy can have disastrous outcomes. In fact, the majority of slashing events to date have occurred when an operator tried to run the same validator keys on different validator client instances, leading to slashing when both became active at the same time in response to a call to perform network duties. This is a big no-no and a breach of the Ethereum protocol rules. As such, validator resilience is a challenge for even the most technologically advanced operators.
SSV: The New Age of Staking on Ethereum
Secret Shared Validators (SSV) aka Distributed Validator Technology (DVT) is a protocol that encrypts a validator key and splits it into four (4) “KeyShares”. These KeyShares are then distributed between four non-trusting parties, known as operators. ’ As a result, it delivers robust, fault-tolerant, active-active redundancy for staking on Ethereum.
With SSV, If a KeyShare is unavailable or faulty (due to a hack, error, scheduled maintenance, etc.), the rest of the KeyShares will respond and the validator will continue to perform its duties without pause.
Even more, 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, SSV enables the distributed operation of an Ethereum validator across varying operators. ssv.network is an infrastructure layer designed to promote decentralization, diversity, fault tolerance and resilience in the ETH staking space.
SSV / DVT at a High Level
SSV is a way to decentralize risk and reduce failures by combining individual SSV nodes into a robust network that can outperform any individual staking service in the areas of robustness, uptime, and security. Validators run portions of their validator key (KeyShares) across different staking setups (nodes) joined together by a consensus layer.
Nodes on the network do not need to trust each other in order to operate, and a certain number of faulty nodes (up to the threshold) can be tolerated without affecting validator performance. In addition, no one node can recreate a validator key signature on its own or make unilateral decisions,which paves the way for trustless networks to be distributed across multiple stakers or staking services.
SSV works as a middle layer between a beacon chain node and a validator client, and manages the process of splitting a validator key and reconstructing it for signing. 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 4 nodes, 3 nodes are needed to recreate a validator key signature, which allows 1 node to be faulty or offline without affecting validator performance in any way.
The truly amazing part is that each node can operate their KeyShare in the way they see fit and can leverage a different validator client on a completely different infrastructure, anywhere in the world. This allows SSV stakers to easily diversify their validators between operators, geolocations, validator clients, and other infrastructure vectors. If one of the nodes is faulty in any way, suffering from poor performance, or even commits a slashable offense, the SSV network will keep on validating despite that node’s shortcomings. This is excellent for both validator liveness (uptime) and security.
Layered Infrastructure Design
In order to operate, ssv.network has 2 distinct layers:
- 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 by the DAO resulting in a decentralized and transparent network scoring of their quality, experience, and service. Actions like adding an operator, creating a validator, and distributing fees occur on the contract layer.
The decision-making component of ssv.network will be handled by a DAO of SSV Token holders. The DAO’s areas of responsibilities will include:
- Operator Scoring – On a scale of 0-100. The score is crucial for users to decide which operators to use. In addition, DAO governance decisions can remove an operator from the network.
- Fee – The fee amount is controlled by the DAO and can be changed by a governance decision.
- Treasury – Responsible for Grant distribution to different initiatives for and by the community. Makes Other decisions for accumulated fees and investment inflows.
- Other decisions – Key protocol decisions such as roadmap and protocol improvements.
Promoting Validator Liveness and Security
For any staking use case, there are two main concerns:
- Optimal performance: “Liveness” (Uptime)
- Optimal security: Slashing protection + private key protection
To optimize for performance and security, as well as protect against validator failure, redundancy is critical. 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.
In terms of validator performance, an SSV implementation takes advantage of the varying benefits that different systems bring to the table and joins them together as one. And, remarkably, it joins them in such a way that their negative characteristics do not carry weight. Each system actively protects the others . SSV can tolerate some nodes being offline while still allowing the validator to attest correctly and reap optimal 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.
When a distributed network of nodes can run a validator in a secure way, security breaches and slashings become much more difficult. From an accidental slashing standpoint, if one or some nodes (up to the threshold) in an SSV fail, 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 do not need to give up private key custody to operators,thus 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. In order to have any effect, a bad actor would have to gain access to a majority of KeyShares operating an SSV validator. This 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 single point of failure that might affect validator performance and safety, while simultaneously increasing network security by focusing on decentralization across the entire Ethereum protocol.
Who Benefits from SSV
In a very 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. This also enables groups of individuals to securely validate together as a group.
- Validators Leveraging Staking Services – Rather than entrusting one staking service with a 32 ETH validator, a user can divide their stake, optimize rewards, and significantly decrease risks.
- Staking Pool Participants – SSV enables decentralized staking pools at the operational level as well as the withdrawal level. Single operator failure affecting the rewards of the users they represent can be avoided by banding operators together with SSV.
- Staking Services/Infrastructure Providers – SSV enables active-active redundancy configurations across all core system components and mitigates risks by eliminating single points of failure.
How SSV Benefits the Ethereum Protocol
Widespread adoption of SSV is not only great for individual stakers and staking providers, but also serves to strengthen the Ethereum protocol itself. Centralization of ETH staking is a real risk given the significant 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 are two-fold – 1. Users entrust their stake with a single operator and risk severe slashing penalties given the protocol’s key aggregation rules. 2. The more validators a staking service manages, the larger the effect will be 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 not being able to finalize.
Centralized staking services are not the only ones to blame for network centralization. Upwards of 70% of validators have traditionally leveraged the same validator client, Prysm. However, No client is perfect and if a large number of validators use the same one, the network can go down if it fails . This was made 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 was able to reach finality, but a different issue 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 of all three working together can reduce their individual risk and strengthen Ethereum by building customizable and unique SSV networks.
This is a real win-win scenario for all parties, as centralized services can now offer decentralized services! By joining forces with others in an SSV network they safeguard themselves and their users from centralized staking risks and safeguard the network by reducing the potential negative effects if they are to fail. If a prominent centralized service fails, the other operators in their SSV will back them up until they are back online and the whole network will continue to function properly.
Finally, touching on the diversity of other components (such as validator clients and cloud providers), SSV promotes the use of varying components without the challenge of implementing active-passive redundancy. By joining an SSV network, a staker or staking service can easily leverage many different components 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 take a look under the hood, SSV is really a sophisticated multisignature wallet with a consensus layer. It is a middle layer that comes between a beacon node and a validator client. From a user’s perspective, it is just a component to plug in and take care of everything on their behalf.
The main components of an SSV configuration are as follows:
Distributed Key Generation
A cryptographic process to generate a shared public and private key set calculated by the operators running an SSV instance. 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 the validator.
Shamir Secret Sharing
Eth2 validator keys use BLS signatures. BLS signatures are additive, allowing for 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.
Applying secure Multi-Party Computation (MPC) to secret sharing allows for KeyShares of an SSV to be distributed amongst operators securely as well as perform decentralized computation of validator duties without reconstructing the validator key on a single device.
Istanbul Byzantine Fault Tolerance Consensus
Tying it all together, the consensus layer of SSV is based on the Istanbul Byzantine Fault Tolerance (IBFT) algorithm. The algorithm randomly selects a validator node (KeyShare) responsible for block proposals and sharing the information with the other participants. Once the predefined threshold of KeyShares deems the block to be valid, it is added to the chain. As such, consensus can be reached even if some operators are faulty or not currently online.
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 uptime, SSV will improve ROI for stakers, increase network decentralization, and significantly reduce staking risks for all.