Designing SSV: A Path to distributed staking infra for Ethereum

Ethereum is facing some major challenges with its POS protocol. MEV, censorship resistance and of course centralization, all increase the systemic risk on ethereum and its users.

When Serentiy (ethereum’s big POS spec) was first designed it was set out to be Multi-Party-Computation(MPC) friendly from the get go, setting the stage for distributed validators technology(DVT). SSV is the first open-source and permission-less DVT implementation. As SSV tech becomes more widespread it’s important to take a minute and discuss the design goals and decisions which lead current SSV development and the advantages it presents against other implementations.

Terminology

• DVT — Stands for distributed-validator-technology. A protocol that enables the distributed operations of an ethereum validator by independent and trustless operators.
• SSV — The first DVT implementation, derived from the emerging EF DVT spec
• Ethereum validator — a 32 ETH validator represented by a BLS key
• Key Share — a shard generated from an ethereum validors BLS key, used by SSV nodes to operate the validator together with others

Mission & Goals

SSV’s mission is straightforward:

“Be a permissionless and distributed infrastructural layer for ethereum on which developers chose to build their staking applications and protocols”

The amount of innovation happening around ETH staking is incredible, we expect it to grow like defi did with many projects/ services competing for ETH. There is a common thread which runs between them all, they all need to run their Ethereum validators somewhere (and somehow). Our mission is to be that somewhere by focusing on developers, small to large.

This mission is important, it has the goal of supporting ethereum’s future by creating a valuable infrastructural component for the greater ecosystem.

Design goals:

• Permissionless and distributed — SSV to be permissionless and distributed. Anyone can join the network, without a centralized authority enabling or intervening in the process.
• Reusable, no coordination and simple — SSV should be reusable infrastructure to the extent a developer can set up a working validator without coordination in a few minutes.
  This unlocks some powerful functionalities and capabilities which we believe are absolutely crucial.
• Public good — By enabling DVT (and making it mainstream) we can make ethereum more decentralized, reduce systemic risk and ultimately more robust

SSV Tech Overview

SSV is built as a distributed network of node operators, managing shares that when put together represent an ethereum validator.

The nodes communicate via a pub-sub protocol over a P2P network, exactly like the beacon chain.
A strong and robust networking layer is not only crucial for robustness but also for decentralization (by removing any centralized coordination like some competitors require).

SSV nodes use QBFT as their consensus layer to coordinate and agree on what duty data to sign every epoch. This makes SSV fault tolerant vs just doing a distributed key management.

SSV uses a set of smart contracts as its data availability layer, all validators are registered and maintained there alongside operator registrations. This results in a mesh-like network of operators that can be chosen by users freely and without coordination to run an Ethereum validator.

Key Differentiating Factors

Fault Tolerance and Distributed Keys

At its core, SSV is a decide-sign type of protocol in which nodes act in 2 steps.

Step 1 — Each node fetches duty data from its local beacon node that it wants others to sign. A round-robin leader is selected out of the nodes to start a BFT consensus round in which all nodes try to decide on what they should be signing.

Step 2 — Once all nodes decide on what they should sign (attestation data, block, etc.) they each use a shard of the validator key assigned to them to sign the data. They collect partial signatures, reconstruct the actual signature and broadcast the signed duty data to the beacon chain.

The magic behind those 2 seemingly simple steps is the use of a full BFT consensus protocol alongside threshold signatures to create a fault tolerant protocol that can be safe and lively up to ⅓ of the nodes being faulty (malicious, offline, bad connectivity, etc.).

For the consensus protocol we’ve chosen QBFT. It’s a well reviewed, simple and intuitive protocol with low network complexity (O(N²)) and latency (3 stages). We’ve been working with its designers and reviewers (Henrique and Roberto) to perfect the spec and implementation within SSV.

Contract based discovery, transparency and data availability

There are many ways to assign keys to node operators, a decision that also impacts the way the protocol is used and what features are unlocked.
A naive approach is using a hard coded config file, some DVT implementations went this route. Although it’s “simpler” it also limits significantly (requires manual coordination) how potential users can use the protocol, creating data availability and centralization issues in the process.
Adding/ Changing validators is a much trickier coordination problem when using config files, it requires tight manual coordination which leads to centralization and trusted setups.

Another issue is just data availability, a node which is setup via config files can’t know what it doesn’t know. Namely outside changes have to be manually added. Loss/ damaged config files are another issue.

Manual configuration leads to synchronization issues.

In contrast to the manual approach, SSV utilizes smart contracts to distribute keys to operators.

Once a staker registers their shares (which are encrypted with the public keys of the chosen operators as a way to ensure that only managing operators could access them), the operators can simply look at events fired from these smart contracts, and immediately commence its operation with the rest of the operators in its cluster, in a trustless way that requires ZERO coordination.

This design is beneficial on many fronts:

• The contracts serve as the data availability layer of the network, and helps for the discovery of all network participants.
• Onboarding is accessible on-chain in a permissionless way, which is crucial for contract-to-contract integrations (e.g. staking pools and other staking applications).
• In cases an operator loses all his shares, they can be fully reconstructed from the on-chain data.

Pub-Sub based networking

SSV has implemented, from day one, its networking layer based on the legendary pub-sub protocol on top of its P2P network. Pub-sub works by creating “topics” within the network to which nodes can subscribe to. The idea behind pub-sub is to reduce the overload a P2P network might experience in cases where not all messages need to propagate to all nodes.

Pub-sub has been used in many projects, including the beacon-chain itself where attestation (and other duty data) propagation is separated into specific topics.
Visit spec to learn more

SSV’s pub-sub network enables nodes to find and talk with one another without coordination, using encrypted P2P communication and signed messages (each message is signed by the operator that created it, easily verifiable).
As messages propagate, they can be examined and analyzed by anyone running a node, creating transparency around operator performance, ethics and more. Based on such tools the SSV explorer was created.

SSV’s networking layer is a foundational component in making sure SSV is permissionless and decentralized.

Distributed Slashing protection data-base

In DVT, every node holds a slashing database for the validators it’s assigned to. In SSV we took it a step further.
As all nodes live within a mesh-like network, communicating using pub-sub, they all get a glimpse of all messages within that topic (and other topics they are registered to).

The QBFT implementation has a unique DECIDED message which contains a proof for all nodes deciding to sign a specific duty data for a specific epoch. Tracking those decided messages can give any observer the full history of all signed attestations, proposals, etc.

In SSV we’ve created a unique distributed slashing protection database across many network replicas (nodes) by saving those decided messages (on an individual node level) and being able to serve them to any other node.
This is useful when:

• A node comes back online and needs to sync it’s slashing database to not sign a slashable duty
• Data availability, the more nodes store this data the more available it is
• Network robustness (harder to attack)
• Extracting data for analytics

Zero Coordination DKG

Distributed-Key-Generation(DKG) is an exciting piece of technology, enabling the creation of a key in a distributed way (no single party holds the entire key).
Most DKG implementations require some manual coordination to set up the ceremony, other DVT implementations went that route which significantly limits the way future staking applications can use their DKG feature.
Utilizing SSV’s permission-less network we managed to come up with a way to implement a zero coordination DKG in which NO manual coordination is needed at all.

The above means that any SSV node comes “DKG” ready once it goes online, users can select DKG participants and perform the DKG ceremony by a simple node RPC call, that’s it.
This is a big advancement in usability as this process can be automated very simply, serving many use cases like staking pools and more.

The output of the DKG is visible and transparent, easily verifiable by anyone. Including contracts.

Read more here

Remote Signer design

SSV was designed to connect directly to consensus and execution clients. SSV itself adopted a remote-signer architecture in which sensitive keys can be managed and stored in a remote signer (which includes its own slashing database).

This approach is based on an emerging DVT spec by the ethereum foundation and Consensys.

This approach has several advantages:

• Aligned with the emerging EF specification
• No need to change existing client implementations (like other implementations do)
• Versatile configuration for basic to advance setups which enable any node operator to setup their own way of storing and managing sensitive keys

There are a number of signers available out there for use, including: web3Signer (supported by lighthouse, prysm and teku), KeyVault, dirk and others.

Summary

When building a project like SSV the technical decisions are often influenced by the purpose and usability of the protocol itself. I’m hoping this article sheds some light on the decisions we took, the reasons and managed to convey the immense value SSV will have as a public good in the Ethereum ecosystem.