SSV, just another DVT solution
Follow me on mirror.xyz, where you can Mint this story as NFT for free!
Special thanks to @Fod for feedback and corrections & @Dean for creating the sick poster!
Is ssv.network a DVT tech?
What if I told you SSV network is NOT a DVT.
Well what is it then?
Let’s explore 👀
As the name suggests it is a network, first and foremost. In it some run distributed Ethereum validators on their machines and others — people & contracts & DAOs can stake their ETH trustlessly.
DVT is an important part of the stack, but on its own it brings as many problems as it solves…
Overview
· The problems of DVT
∘ Going beyond DVT
· The Vision
· The Product
∘ The Cluster
∘ Static clusters
∘ Dynamic clusters
· Staker’s incentives
∘ Freeriders
∘ Systemic effects
· The Network
∘ Fault tolerance
∘ Attack dynamics & recovery
· The bottom line
The problems of DVT
First things first, WTF is DVT?
DVT or distributed validator technology as the name suggests, is a technology to distribute a single validator to be run by multiple parties (operators).
Ok now that we have multiple parties running one validator, how do they find each other and coordinate?
Also what happens if an operator is not responsive?
How will the rest of the operators even know that this is the case, since the validator is chugging along normally?
So now that operators organise into clusters, we are changing more large operators into less massive clusters. Does it really help decentralisation?
To collude one operator is definitely easier than to do so for the whole cluster, but the reward is so much sweeter…
These are the hard questions that any DVT protocol must face, let’s take a look how SSV network addresses them.
Going beyond DVT
Trustless & Decentralised staking for all
DVT basically addresses the issues operators’ infra setup, because classic redundancy solution of mirroring to a different machine is not viable.
Using basic DVT operators gain much more robust & decentralised infra, which if done correctly could be a nice value add.
But what about the stakers?
Can we somehow empower them to stake in a trustless & safe way while remaining onchain?
Helping operators with the infra is great, but what gets me excited is empowering stakers. Allow them to stake in a trustless, transparent & decentralised way.
Allow stakers & operators come together onchain. No need for intermediaries and middlemen, full transparency and no “trust-me-bro” finance.
The Vision
The vision as I see it is to decentralise the Etherum staking markets and empower both operators and stakers to come together in a trustless decentralised way.
Operators can be judged for the first time purely on their merits thanks to the public nature of the network and easy performance tracking.
Stakers can choose operators based on their geography, software, performance, or fees without any need for coordination.
Since every validator is run by multiple operators, even if some of their operators fail they can simply replace them with no effect on their validator’s performance.
The goal is to have a free open market for staking services. All performance is visible, all coordination and payments are onchain.
No centralization No bottlenecks.
The Product
SSV.network allows the staking industry to move away from centralised monolithic architecture with very few agents fulfilling all the roles into a highly specialised decentralised system.
What flashbot has done for MEV SSV is doing for staking.
Flashbots has allowed for a clear separation of block production into searchers, builders and proposers.
SSV is doing this same thing for staking, separating it into operators, staking applications and stakers(Eth providers).
We have clearly seen this same trend in traditional web development. Web development companies used to run their own servers, use their own storage and backup solutions.
Nowadays developers are focused only on what they do best — developing web applications. All other tasks such as running servers and taking care of data are outsourced.
This is a trend in most complex ecosystems. As they become more mature, the actors and roles become more specialised.
In the same spirit SSV is building a network that allows for this specialisation and separation of concerns in Ethereum staking.
It allows node operators to focus just on running highly efficient staking operations, and empowers crypto developers to focus on what they do best — building sick LSDs and staking apps.
The Cluster
“There is nothing so stable as change” Bob Dylan
Static clusters
Let’s talk DVT and it’s issues. Its naïve implementation may look something like this:
- Single operators form operator clusters
- Stakers choose clusters to stake with rather than individual operators
What are the effects of this?
Every validator will coordinate with others and join one, or small amount of clusters.
I, as a big shot operator I want all my cluster bros to have the biggest possible punching power and bring as much stake to our common pot as possible. It makes no sense for me to team up with some small indie operators with no capital to their name.
Theoretically there could be:
Where $$o$$ is number of operators and $$s_c$$ is a size of a cluster. Thus if we have 100 operators and a cluster has 4 operators this will amount to quite staggering 94,109,400 possible clusters.
In practice the incentives for operators to be a part of more than a few clusters are just not there.
Also Operators care about how much capital they have, not how many clusters they are a part of, in fact it is an added overhead for them.
Stakers care about lowering the risks thus if choosing more then one cluster, they would prefer them to be non-correlated, thus ideally not sharing any operators.
Operators will naturally promote the clusters they are a part of. This results in clusters to map to roughly the same (power law) distribution as operators follow today.
Small number of clusters will own the majority of the stake.
In summary, static cluster creation leads to an equilibrium where the large clusters control much more stake then large solo operators would, since the capital they control would be roughly the sum of the capital of all of its members.
To coerce the whole cluster is much harder than a single operator, but the honeypot awaiting is that much sweeter.
Dynamic clusters
In SSV stakers, not operators form clusters. They are created dynamically, on-the-fly only based on what operators a staker picks. This changes the game played on multiple fronts.
Stakers’ incentives
While there is no incentive for big shot operators to team up with their smaller bros, for stakers there is. Let’s examine what are stakers’ preference and what is the reality.
What are the guarantees of their performance? What is their reputation? What performance will they have in the future?
The wet dream of every staker:
High-performance, high reputation, low price, low TVL operator.
The realistic choice is between:
Professional operator — high-performance, high reputation, high price, high TVL operator
Home operator — high-performance, low reputation, low price, low TVL operator
From the point of an staker looking from outside it’s a hard choice:
Do I go with a large operator which already has a large TVL honeypot, probably good security practices, the trust of a majority paired with a large price tag?
or
Do I go with a small operator with a small TVL honeypot, unknown security practices, low reputation but paired with a very competitive price tag?
In real world large TVL usually is an effect (not cause) of higher trust of stakers in a given operator, hopefully this is well placed, unfortunately in practice large TVL and security practices are as often divorced as they are not. Think 3AC and SBF.
You may be wondering why a low TVL operator would be preferable?
Doesn’t more TVL indicate more trust and better security practices?
All other variables being equal, staker is always better off going with a lower TVL operator as this offers a smaller honeypot for potential attackers. Put simply, if you are an attacker you want to go for the jackpot, as this will most likely be a one time gig for you. So if you are a staker you would rather not be on the receiving end of this.
Stakers can and will choose both well known high quality operators, but also independent ones to help with risk mitigation. Both from the perspective of stakers’ incentives and from my anecdotal evidence working with them. Most of them are interested to use high quality blue chip operators and pair them with 1–2 well-performing community operators.
This gives the staker the advantage of lower overall fee and smaller risk of coercion attack.
It also contributes to a larger heterogeneity on the systemic level.
Freeriders
If stakers are choosing individual operators, not the whole clusters, there is no operator “freerider” effect, where some operators just go along for the ride, because stakers were forced to choose a whole cluster. Thus the much better aligns incentives, requiring operators to focus on their performance, not to get into the “right” clusters.
Systemic effects
There are important differences between choosing-clusters vs choosing-operators paradigm.
The highest TVL operators will have about the same amount of stake in both paradigms. However in the former, these operators will be the part of the same clusters, whereas in the second the clusters are much more heterogeneous. Thus per cluster TVL in the latter case will be lower.
So if the reward of cluster coercion in the latter is lower the risk of it happening will be as well.
There will still be a power law distribution of stake allocation on the operator level, but importantly much less so on the cluster level.
The Network
Res Publica, The beauty of public networks
Public nature of the network solves a couple of important issues. It allows operators to build up in-system reputation and for stakers not to rely on out-system reputation (other staking services, social media presence etc.).
This is a crucial point which both helps prevent entrenchment of the big players and allows small players to be judged on their merits, not TVL.
Fault tolerance
If you can create a cluster on the fly, why could you not change it also?
It is a good question because it turns out you can. The public network paired up with dynamic clusters allows for their complete fluidity.
Clusters can be created, updated or destroyed by a single transaction.
Systemic effects of this killer feature:
- Much lower barriers of entry for new operators
If stakers can change operators if they are not performing well, they could be less picky when choosing them. In practice, choosing operators for your cluster is always a balancing act between looking at low price, low TVL, high reputation, high performance. Since changing an operator is trivial, stakers will on aggregate choose cheaper operators with lower price + reputation as they otherwise would. This in return pushes the price equilibrium for all stakers. - No operator entrenchment
This also allows the system to stay dynamic and not entrench the dominant operators, since barriers of entry for new operators are low, barriers to changing operators are low as well and outside reputation is not crucial as talked about above. - De-risking operator selection
Similarly as in point above, both the fact that the staker sees the operator’s current performance and the ability to easily change them were his performance not satisfactory, makes this decision much less risky and consequential.
Attack dynamics & recovery
In general DVT solutions, without a public network the attack is hard to detect outside the cluster. If the coerced operator is part of more than one cluster they can attack one and the others have no knowledge of this even happening.
Also, even when the attack is detected the rest of the operators need to somehow coordinate together to find another operator and replace the byzantine one. This can quickly become a headache, not only since this is not easily doable within the system, but also because the communication channels used for coordination could be DDOSed.
DDOS
DDOS attacks on individual operators are a nuisance, but nothing more. The dynamic operator switching saves the day again here. The attacker could either attack individual operators or the synchronisation mechanism stakers & operators use. Individual operators can be targeted, but since in case of attack stakers can switch their non-responsive operators just with sending one tx, the attack hasn’t got much teeth. The attacker can of course try to prevent this coordination to take place, but good luck trying to censor Ethereum mainnet.
Operator Coercion
To coerce individual operators is also a non-issue, since one operator cannot do any damage on its own. This holds true for all DVT solutions. Where SSV has the upper hand is the recovery from this.
The public networking layer allows this attack to be clearly visible to all the network participants and the dynamic cluster creation allows the system to adapt without any special coordination efforts. Here stakers just need to be mindful of what is the cluster threshold, and not change more operators if they suspect they might be byzantine. You can find more on this here.
The worst attack is the coercion of the majority of the cluster. This would be really bad if it were to happen, no sugar coating around it and could result in slashing.
The silver lining here is that the dynamic cluster creation by stakers leads to a larger heterogeneity amongst them and smaller honeypots as explained in the previous section.
Even the Largest clusters will still be smaller in SSV as in DVT Systems with similar TVL with static ones.
The bottom line
The bottom line is that from a Risk perspective SSV network is both orders of magnitude less risky than Non-DVT solutions and also significantly safer than simple DVT implementation.
The users of staking products will tend to choose those with the lowest risk and the highest rewards, which will be built on the tech best suited for this.
This coincidentally might just be the right niche for SSV…
