The Official SSV Node Spec

The Secret Shared Validator (SSV) protocol was designed by the Ethereum Foundation (in collaboration with others) to build redundancy into the Eth2 Client architecture by removing any possible single points of failure. This necessitates that the fundamental SSV protocol design is free from any security vulnerability, ensuring that it functions as designed and does not open up attack vectors to Eth2 Clients operated by honest staking accounts.

To this end, the ssv.network team has spent the last 8 months in an intense R&D effort to finalize the SSV node technical specification(spec). Achieving this major milestone is an essential step in preparing for mainnet. And by ending the “theoretical” phase, SSV has completed a critical piece of the puzzle, enabling the team to align the implementation to the spec, giving us a clear vision of the last milestones before mainnet.

What is a Spec?

For those wondering, a spec is technical documentation used to describe a system, analyze its behavior, and support its design by verifying fundamental properties. In SSV’s case, it’s the blueprint that specifies the core logic of the SSV node. This blueprint helps standardize what an SSV node is and how it deterministically functions, serving as the one source of truth that documents all design decisions.

Developing a complex protocol like ssv.network without a spec is similar to navigating through rough terrain without any sort of map, or navigation. A spec allows us to define clear goals, test those goals, and later on graduate to an implementation phase which will safely lead us to those goals.

Why does SSV need a Spec?

Without a spec, its hard to test assumptions and externalize your decisions for other contributors to review and improve upon. Developing a groundbreaking protocol like SSV can be prone to mistakes since you’re in a break first think later development mode.

When SSV started, there was no specification for how an SSV node should function, so while working on the spec, the team simultaneously worked on the implementation of the ssv.network protocol. The implementation is essentially a wrapper for the spec, allowing us to build on top of the core logic. At this stage, the team is working hard on aligning the SSV node implementation to the spec.

Having a spec enables us to do a few essential things:

• Helps SSV align the implementation to the spec — Defines clear milestones for the final updates to the SSV implementation before mainnet.
• Test implementation (spec tests) — A spec isolates the core logic of the node, allowing developers to test and review against it. Because SSV works as a network of trustless nodes, the team will need to do considerable testing to create a robust and reliable system.
• Enables future development & Interoperability — Having a spec is the best practice when working on open source services, aligning everyone and allowing future teams to build their version based on the spec. Builders that want to develop their own ssv-based node implementation can do so easily by following the spec, helping to improve node diversity in the future.

SIPs

The intent behind adding SIPs(SSV Improvement Proposals) to the ssv.network is to create a mechanism for proposing new features, collecting community technical input on issues, and for documenting the design decisions that have gone into the ssv.network protocol. For SSV implementers, SIPs are a convenient way to track the progress of implementations.

If anything about the spec needs to change or shifts from the original design, a SIP(SSV Improvement Proposal) is required. The community can submit SIPs with their reasoning behind the proposal and how the SIP can be implemented. This is similar to Ethereum’s EIPs, where developers constantly work on further developing the protocol through an incremental and democratic process.

Step-by-step implementation of a SIP:

1. Proposing an idea via a SIP
2. Check SIP against the spec
3. Run spec test to test SIP
4. Implement SIP if it passes

The SSV Spec

We are currently in the process of alignment. This means we are aligning ssv.network node 0.2.6 with the spec. We’ll discuss each of these milestones once they’re closer to completion.

Milestones:

• Node aligned to V0.2.6
• Devnet
• Contracts V3
• Testnet V3
• Mainnet

With the spec finally completed, the way forward is crystal clear. We’ll be releasing a post about the mainnet roadmap soon, concerning the SSV ecosystem, protocol, and the road ahead. Join our Shifu testnet to see the latest in DVT tech in action.

Website | Network Hub | Discord | Dev Center | Documentation | GitHub