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.