ssv.network - Path to Mainnet
As with every new year, it’s important to take the time and reflect back on the year that passed and the one to come.
The Year That’s Been
2021 was a particularly intense year for all of us, and an especially busy and challenging one for the team here at BloxStaking. We started with a ton of tasks as the beacon chain mainnet was just a month old (Dec 2020), concentrating on scale and stability. We had some issues at the beginning but we tried to move fast and iron them out.
During 2021 we saw great growth, we went from near zero validators to 2,150 as of today, this is roughly 73K ETH (at 34 ETH/ validator including rewards), around $300M!
We might still have a long road ahead of us but all of those validators are controlled by their owners, none by Blox, which is not something most staking services can say .
2022 will be dedicated to improving our infrastructure to support more beacon chain clients for diversity, and of course, building a bridge to SSV.
Ultimately we see BloxStaking becoming a meaningful operator on ssv.network.
We started working on the Secret-Shared-Validator(SSV) in 2020, mostly as a POC project. The idea was to feel comfortable with implementing a full SSV node and have a good vision of where we want to take it.
To achieve this we needed to develop a few main components and see how it all interacts. We implemented the QBFT protocol from scratch and attached it to a rudimentary P2P networking layer, a simple BN duty coordinator and a singer.
We had a simple private testnet setup and, later on, added another one, all to prove that it could work and performance was decent.
The next big challenge was to figure out what to do with the tech. We thought about doing an SSV-based staking pool, a DeFi protocol and played around with a few other ideas which all came short. SSV felt like an infrastructural component but we kept treating it as a service.
We finally figured out what to do with it. As it turns out, it doesn’t matter how sophisticated and innovative a staking service is, it still needs to run 32 ETH validators somewhere. That’s true for current and future services alike.
In early 2021, we drafted a mini paper describing SSV as a network of operators which form a decentralized infrastructure for ethereum staking. This was a revelation, a crucial component for the ethereum eco-system which can help solve a lot of the challenges we face in areas like: slashing protection, decentralization, client diversity and more.
Layer 0
In October 2021, Vitalik announced the rollup centric roadmap for ethereum, solidifying the idea that the ethereum ecosystem has layers in its technology stack.
Layer 1 is ethereum itself, the consensus and execution engines.
Layer 2 is a term used to describe different scale solutions like optimistic rollups, zk rollups and more. Layer 2 is an extension of layer 1, it uses it to capture the same security properties.
When thinking about ssv.network, a seemingly appropriate term cames to mind, ‘layer 0’. A new component that helps secure ethereum (it’s all about staking, after all) and a whole different layer of protocols which does not extend ethereum like L2s but rather helps make ethereum itself more secure and decentralized.
The ultimate vision of SSV.Network is to become a fundamental component in the ethereum ecosystem, one that makes sure control of the ethereum chain stays decentralized, stakers do not give away control of their ETH and more importantly, any future innovative staking service (pool, liquid staking, institutional and more) could make use of SSV.Network as a reusable infrastructure easily.
The above is especially true after the recent move Kraken made (purchasing staked), putting it ever closer to holding 1/3 of all stake.
That last bit, reusable infrastructure, is crucial.
ETH Staking <> DeFi
As I’m writing this post, there is roughly 8.7M ETH at stake. That is 7.3% of the circulating supply.
How much more ETH will be staked in 2022 is anyone’s guess but considering the merge will most likely happen and withdrawals might be enabled in 2022, a conservative estimation could easily put that number at 2X.
There is another big transition which is hardly ever talked about, the full immersion of defi locked ETH into staking.
In 2021, we saw 8–11M ETH locked in various defi protocols. Most of that ETH didn’t generate any returns (in and of itself) for its owners but was rather used as collateral or liquidity.
It is very probable that in 2022 we will see a huge migration of locked ETH in DeFi to some form of liquid staked ETH. It just makes sense.
This brings a ton of challenges and questions: will DeFi protocols just give their ETH to other liquid stake protocols? How will DeFi protocols tokenize their ETH for staking? Will DeFi protocols create their own tokenized stake?
Having SSV as a reusable infrastructure can help to navigate the above challenges. Communities and protocols could use the locked ETH to stake in a trustless and decentralized way and even tokenize it.
Think of a protocol like Uniswap or Aave where the ETH can receive protocol rewards + a base APR from staking. All the while staying true to decentralization and running zero infrastructure to allow their users to stake ETH.
Path to mainnet
The flow chart above tries to capture the major items needed to be completed before mainnet readiness. It takes inspiration from Vitalik’s chart for ethereum itself.
There are 4+1 categories: Contracts, Protocol, Testnet and R&D (and relevant DAO decisions).
Contracts
Although not the center of attention during the current testnet, there is major work being done towards the actual set of smart contracts that will be needed for a mainnet-ready SSV project (the current testnet set of contracts are placeholders ONLY).
The contracts can be thought of as the management layer for the SSV nodes where validators, operators and the SSV token come together.
The next major milestone will be V2 which includes the introduction of the entire operator fee management + fee accounts for users.
Draft spec can be found here, and the implementation here.
V2 will most likely require a new testnet as a lot of changes to the contracts will make it easier to just start from scratch.
Protocol
This includes pretty much everything inside the SSV node, from networking, consensus, and cryptography to integration with the smart contract.
Node versions V0.1.X will serve up until the anticipated new testnet with the introduction of V2 contracts, from which point V0.2.X will take over.
The next 1–2 months we will focus on 4 major development milestones:
- Refactoring message processing (V2) — The way the current SSV node manages network messages is sub optimal. It wastes a lot of CPU with memory spinning thousands of go-routines which is unnecessary. For the node to take on scale it needs to work more efficiently which means refactoring all together the way it processes network messages.
- Networking V2 Spec — A full networking spec for SSV was never done which is a necessary requirement for both mainnet, future interoperability and scale. Although in progress , you can follow the spec development here. When transitioning to this spec a hard fork will be required.
- QBFT spec alignment — SSV runs on a BFT protocol called QBFT, developed by Roberto Saltini. A few months ago a formal verification for QBFT in dafny was done with the formal spec. SSV’s implementation is very similar but not 100% aligned, which will be the next step with Robert’s help.
- Local network setup — As development progresses it becomes necessary to be able to run a full local SSV setup including: eth1, eth2 and SSV nodes. For that we’ve been working on a set of scripts which can automate it, making development easier (specifically testing).
Testnets
By the time we reach mainnet readiness, we will need to go through at least 2–3 testnets, each one closer to the final mainnet spec.
The reason to create a new testnet is usually some kind of upgrade which is not backwards compatible.
The current testnet (a.k.a A, if anyone has good naming suggestions, we welcome them!) has a primitive set of contracts (placeholders). Contracts V2 have too many changes to make them backwards compatible which will require creating a new testnet (For now called B).
Coordination here is tricky. Between the current testnet and testnet B, we plan the incentivized testnet to start, we will need to coordinate a way to transition between the two.
Current incentivized testnet spec.
The last testnet, C, will also be a release candidate for mainnet.
R&D + DAO Decisions
There are a few major R&D projects which are important for mainnet readiness.
- Incentivized testnet spec
- Verified operator framework — Similar to Avve’s risk assessment framework, SSV.Network will need some formal framework by which to evaluate operators that want to get verified. The works has not started yet, so if anyone is interested — please reach out (IMO the DAO should provide a grant to this important work)
- SSV Spec — A comprehensive unified spec for all things SSV (protocol, contracts)
- Long term testnet program — The testnet is not just used for development but also for devs wishing to integrate SSV in their product; to that end it’s important to have a long standing testnet which is similar and as close to a mainnet one. Polkadot did a good job of incentivizing their testnet as a fast and loose chain for developers, SSV.Network should consider adopting some similar incentive program to make the testnet long-standing.
The above R&D projects will need to go through the DAO voting process to get adopted.
The path to mainnet is challenging, one that will take development, DAO and community to new frontiers.
Along side the technical path to mainnet, there is much work to be done with partners, community and spreading the word.
If you’d want to learn more, give a helping hand or just ask some questions, please visit ssv.network.