Eth2 SSV Community Call — Fireside Chat — 2021–02–24
Notes from the SSV Community Call that took place on Feb 24, 2021.
Topics: SSV Overview and Use Case Discussion: How does SSV Benefit Staking Providers, At-Home Validators, and Staking Pools
Participants: Mara Schmiedt (moderator) — BisonTrails, Collin Myers — Consensys, Dankrad Feist — Ethereum Foundation, Alon Muroch — Blox Staking, Aditya Asgaonkar — Ethereum Foundation
What Does SSV stand for?
SSV stands for Secret Shared Validator. The concept is to split an Eth2 validator key across several different machines. The key is split in such a way that a minimum threshold of parts is required to create a validator key signature. Less than this threshold, and the key cannot be created for signing.
What is SSV trying to solve for?
SSVs can increase both liveness and security because even if one or several machines are compromised, a key cannot be recreated in its entirety and get the validator slashed. An SSV setup can tolerate some machines being offline while still attesting correctly. For most use cases, SSVs will enable more robust and fault-tolerant infrastructure.
Why is SSV needed? What is the specific added value for Eth2?
For any staking use case, there are two main concerns; slashing + optimal uptime. SSV should improve both of these fronts significantly. When several different machines can run a validator in a secure way, slashings become more difficult (both from an accidental standpoint and an attack) and performance should also improve as the system is more robust with much more redundancy.
On a higher level, SSV does a lot for Eth2 but it also introduces new node configuration possibilities inside a blockchain itself. It allows for any validator on Eth2 to create an active-active setup and involves a larger innovation inside of how validators manage themselves and how they can configure and diversify their nodes on the network. This can extend far past Eth2 and be used across different blockchains.
The slashings on Eth2 up until now have been due to operators trying to build redundancy in their validator client setups. By running the same keys on a different validator node, both can become active simultaneously and get the validator slashed. SSV on the other hand is the correct way to build redundancy into Eth2 nodes and avoid this problem. In this way, SSVs can both help performance and security of a validator setup.
What specific modes of validator failure are SSVs trying to address?
- Poor performance / missing validator duties
- Key compromise / security failures
SSVs are a bit like Horcruxes in Harry Potter, where you’re splitting your soul into multiple pieces, and unless someone has all of them (or in the case of SSVs, a very high number of them) they cannot attack you, so to speak. — Aditya Asgaonkar
What are the different components of an SSV standard configuration?
- BLS threshold key — split a key into a polynomial. Any shares more than the threshold are enough to reconstruct the signature.
- key generation — algorithms that allow distributed key generation.
- byzantine fault tolerance — system to decide what to sign.
- SSV nodes — to put everything together + add a protocol for SSV nodes to speak to each other, validator clients, and beacon nodes.
SSV is a middle layer that comes between a beacon node and a validator client. From the user’s perspective, it is just a component to plug in and take care of everything on their behalf. Essentially, a sophisticated multisignature wallet with a consensus layer.
How does SSV differentiate from the architectural setups we’re seeing today?
Current setups vary by operator, but the common feature is that there is only 1 validator component.
If that component fails, then you stop validating. If that component’s slashing protection fails, you risk getting slashed. SSV is taking that one component and splitting it up — this could be into different entities, machines, cloud providers, or basically any diverse vector you can think of, and by doing so, downtime and slashing risks are greatly reduced. — Alon Muroch
There is also the benefit of easier maintenance. Nodes can be taken offline one by one to update them, which won’t affect overall performance.
How can different operators integrate and leverage SSVs?
At-Home Validators
SSV is kind of like a new, valuable tool in one’s toolbox which can be used in many different ways for liveness and/or security. — Dankrad Feist
Splitting a key across various machines can increase security should any one be compromised. For at-home validators using cloud providers, SSV enables multi-cloud redundancy, reducing reliance on the performance of just one provider. Additionally, a group of individuals or a small community can validate together as a group in a robust way.
Decentralized Staking Pools
The biggest challenge for staking pools is how to make them secure and decentralized while minimizing slashing risks. Currently, there are good solutions for decentralized withdrawals, but the actual operational side still needs a robust solution, of which SSV can play a major role. A common issue for existing staking pool setups is that risks and rewards are both socialized; one compromised validator can affect the rewards of the individuals they are validating for.
With SSV, several trusted entities can work together to form a trustless network. Each operator does not need to trust the other to operate, and a few (up to the threshold) can be compromised, without compromising the network as a whole.
As an example, users of the 5 most prominent staking pools in existence today are all susceptible to signal operator failure. If these 5 operators were to band together leveraging SSV, each provider would be able to further secure themselves and their users. If an operator consistently fails, they can be voted out of the pool and perhaps not voted back in. Reputation is the basis of access to provide infrastructure to the staking pool. Users can have more confidence in the performance of their pool as it is diversified across providers.
Users also have the opportunity to build their own pools of providers (or cloud accounts etc.) and in the future, there is the possibility to divide signing rights amongst unknown parties so that they can act trustlessly. This presents an opportunity to build new incentive models around collaborative work behavior.
Infrastructure Providers
Existing solutions for redundancy are only active-passive configurations. Backup nodes serve as failover for primary nodes if they fail to perform their duties, but achieving complete redundancy at the level of the client is really hard to do.
SSV creates an opportunity to create superior redundancy across all of the core components that comprise an infrastructure setup — which is a massive value add for customers. For providers that operate at scale, this is not only great for risk reduction but also does not introduce a massive amount of operating costs.
It’s a win-win for a configuration that drives significantly better resiliency without introducing a significant amount of overhead for deployment. — Mara Schmiedt
There are a lot of very large infrastructure customers who have a lot of stakers (custodians, exchanges, etc.) who may have a critical mass of voting power in the network. SSV drives the potential to enable customers of other providers to have a preconfigured set that introduces diversification. Enabling configurations between different providers to service the risk diversification needs of other customers through a middleware software.
Development costs are also reduced. Single, sensitive components can lead to development bottlenecks and risks. SSV from a development point of view can alleviate some of these by splitting sensitive key holding or signature points into various nodes and thus changes or updates become much less worrisome. If something doesn’t go well, it can be reverted back without affecting any of the other nodes — this is useful for any service developing on top of ETH staking.
SSV Development Roadmap
There is currently one SSV testnet validator running on Pyrmont. The next big milestone will be a testnet of a few validators with diversity in terms of who is actually running the nodes. As of now, the test nodes are on Blox’s staking environment but to start truly testing for efficiency and scale, the team needs as many partners to join in. Having a healthy mix of institutions and at-home validators who want to participate will add great value to the project, feel free to get in touch and learn more on the next community call.
Get in Touch
Discord: Eth R&D Server, SSV Channel.
Upcoming Community Call: March 3, 2021.