The DVT Landscape:
A solution provider comparison
An in-depth look at SafeStake, Obol Tech, and SSV.Network.
In the current ETH staking industry, ETH holders face some challenges when they decide to stake their funds and run a validator:
- The inability to withdraw their staked funds.
- The penalties and/or slashing for not having a secure, redundant connection that keeps their validator online 24/7.
Users or entities that want to earn staking rewards, whether by ‘solo staking’ or utilizing a Staking as a Service (SaaS) provider, must have adequate knowledge, resources, and a properly configured network, or the losses could be substantial.
The concept of DVT (Distributed Validator Technology) was developed as a solution to these problems, offering the ability to allow a validator to run on more than one node, increasing both security and fault tolerance. With DVT, only two-thirds of the operators managing a validator are needed to reach consensus without problems. This allows a node in the operator committee to be offline, disconnected, or compromised by a malicious actor, while greatly reducing the validator’s chances of incurring any penalties or slashing.
It is for the reasons above that Distributed Validator Technology (DVT) stands out as one of the new technologies that will have a massive impact on both solo staking and staking services (Staking as a Service/SaaS) in 2023.
Despite its relatively recent development, there are some projects that are leading the way in the industry by developing their own flavors of DVT for ETH staking: SafeStake, Obol Tech and SSV.Network.
In this post, we will look at a comparison of SafeStake to the others without the intention of competing or engaging in discussions about which solution is better. We consider all of the projects as contributors to the DVT space and not necessarily as competitors in the massive ETH staking market.
The fact is, SafeStake, like the others, is here to help decentralize Ethereum by expanding its validator base with the use of cutting-edge technology.
Architecture
As you would expect, the underlying architectures of the three projects differ substantially.
With SafeStake, two types of stakers are supported:
- Those with 32 ETH
- Those with less than 32 ETH but more than 0.1 ETH
To handle the first type, SafeStake offers a Stage 1 DVT staking solution that supports 32 ETH deposits. To address the second, we plan to introduce Liquid Staking at a later time (Stage 2)..
SafeStake will launch Stage 2, introducing the concept of ‘mini-pools’ and ‘initiators’ into the architecture. It will lower the staking threshold for operators running nodes on the network to an 8 ETH deposit. Operators that make an 8 ETH deposit are called ‘initiators’ and will activate mini-pools that will wait for the other 24 ETH to create a pooled validator.
The initiator will select three other operators (two of whom must come from the ParaState DAO for added security) to run the DKG (Distributed Key Generation) protocol that creates the private/public key pairs for the threshold signature scheme. SafeStake’s DKG is built-in and works at the protocol level without the need for a ‘trusted dealer/leader.’
Operators do not have to be initiators on the SafeStake network, allowing for regular operators who want to run nodes and the threshold signature scheme to earn fees (in $STATE, soon to be $KEY) from the validators they manage.
Similar to SSV.Network, SafeStake uses its native token, currently $STATE, for payment from validators to operators.
In contrast, Obol Tech does not currently have a native token for payments, and operators and stakers must deploy their own custom smart contracts to handle payments, or handle them off-chain. Additionally, Obol operators run validators in isolated clusters using their own middleware client combined with a regular validator client, while SafeStake runs on top of Lighthouse, an ETH2 consensus client, and acts as a trust-minimized middle layer.
SafeStake also has a unique approach and main focus, aiming to expand Ethereum’s validator base by lowering the staking threshold, first to 8 ETH, then to 0.1 ETH.
Networking
It is fair to say that SafeStake and SSV.Network have a similar networking approach, and that they differ significantly from Obol.
Obol uses isolated validation clusters that do not allow for communication with other clusters, decreasing the need for bandwidth. However, it also poses a significant drawback as a temporary disconnection between operators leaves their peers in the dark about the current status of the unsigned duties and unable to achieve consensus.
On the other hand, SafeStake and SSV.Network use a public network where everyone knows the current status of the operators, so that if one fails, the rest can perform the respective staking duties. However, to reduce bandwidth usage, SafeStake operators only need to know the IP addresses of their peers.
Additionally, both SafeStake and SSV.Network allow operators to be monitored and observed to avoid potential censorship and centralization by powerful entities acting to coerce, furthering centralization. If an operator is found to be acting maliciously or compromises the network, the validators it manages can be automatically switched to another operator without the need for coordination.
Client Software
When it comes to client software, Obol and SafeStake have something in common — they function as a middle layer that runs a standard validator client in parallel. In the case of SafeStake, this validator client is Lighthouse.
By running as a middle layer, the possibilities of slashing can be greatly reduced and the responsibility falls almost exclusively on the development team and not on the staker/user.
SafeStake and SSV.Network function similarly by dividing the validator key into parts, called ‘shares’ or ‘key shares,’ encrypting them using the public keys of the operators which allows for enhanced security. However, the similarity ends there.
To make the process as secure as possible and avoid potential points of failure, SafeStake implements true DKG (Distributed Key Generation) at the protocol level without the need for a ‘trusted dealer/leader.’ This means that no party ever has possession of the validator private key, even for a nanosecond, and that the actual validator key can never be recreated by anyone.
Much like the science of fingerprint matching, an exact replica isn’t necessary to successfully sign data, only an ‘equivalent’ signature on the part of the operators holding key shares coming together to achieve consensus.
Currently, Obol uses DKG in its clusters, while RockX has received a grant from SSV.Network to develop their DKG solution.
Consensus
In DVT environments, consensus is used to determine the message content of the threshold signature scheme, so multiple operator nodes holding key shares can come together to sign data on behalf of validators. Both Obol and SSV.Network use the iBFT/qBFT protocol, while SafeStake utilizes Hotstuff to govern the operator network.
Hotstuff is a leader-based Byzantine fault-tolerant replication protocol for the partially synchronous model, and SafeStake uses it via the ParaStateDAO to determine various validator parameters, like balance and slash.
Hotstuff is more robust than iBFT/qBFT and greatly reduces the risk of slashing for Ethereum validators on the network.
Key Management
Key management is a big part of DVT. Stakers large and small want peace of mind knowing their validator private key is secure and cannot be recreated by a malicious actor. SSV, Obol, and SafeStake allow validators to split their validator private key into multiple key shares, which are then distributed to different operator nodes.
However, to prevent anyone from gaining control of the private key and stealing the staking rewards, SafeStake uses built-in DKG (Distributed Key Generation) at the protocol level to generate the public/private key pairs for the threshold signature scheme.
This implementation of DKG is known as a threshold signature scheme without a trusted dealer, as no single entity ever holds the private key.
Currently, no other DVT staking service uses this particular method to secure the validator private key, and SafeStake is expected to be the first protocol to use both DVT and DKG for Ethereum staking duties.
Both Obol and SSV aim to separate the management of private keys from other parts of the stack. Obol does this by keeping the keys separate from their middleware, letting the validator client handle them instead, while SSV uses a specialized software enclave that handles signing duties, known as a ‘remote signer.’ SSV has also given RockX a grant to develop a true DKG solution for their protocol.
The ultimate goal for all three protocols is to reduce the possibility of attacks that could compromise staking rewards or deposits for users earning passive income by staking their ETH.
Slightly different from SSV, SafeStake also introduces an extra layer of security that prevents malicious actors from reconstructing the original validator private key through inactive operators holding private keys.
The SafeStake protocol achieves this additional security by running a threshold signature scheme without a trusted dealer and uses other proactive measures like secret sharing and periodic removal of key shares to ensure information gained by an attacker is useless after the secret shares are renewed.
It is worth noting here that to achieve proactive security, each share holder must delete the old share to prevent adversaries from gaining access to the old shares to learn the secret.
Tokenomics
As we mentioned earlier, Obol does not currently have a native token, while SSV.Network and SafeStake have internal economy models based on their own tokens. This is known as ‘tokenomics.’
In the SafeStake ecosystem, the STATE token ($STATE) is currently the native token and serves the following functions: registering operators on the SafeStake network, paying operator fees, governance, and economic incentives. Running a validator on SafeStake requires stakers to own $STATE so they can pay operators for their services.
Additionally, SafeStake validators, initiators and operators are required to maintain a minimum balance $STATE. Operators on the SafeStake network are required to maintain a minimum balance of X STATE tokens and monitor their Beacon Chain staking account to make sure it always meets the 32 ETH requirement.
Maintaining a minimum STATE token balance is essential to cover any slashing penalties that may occur during startup.
“It is important to note that the SafeStake team is currently proposing a rebranding of its STATE token, which will affect the number of new tokens issued to STATE holders by a ratio of 10:1.
The proposal is posted on the STATE DAO and the reasons for this change can be found by clicking on the following post:
https://daniejjimenez.medium.com/token-rebranding-governance-proposal-5b34ab8a0d01
Similarly, the SSV token serves three main functions on SSV.Network: payments from validators to operators, network fees, and governance.
Final thoughts
The race to lead decentralized, non-custodial DVT staking has begun. The implementation of this technology is one of the trends expected to have a major impact on the ETH industry in 2023.
With a QoQ growth of 8.8 million over 2022, the total amount of staked ETH is now at 15.8 million units. It is logical to think that there will be increased interest in the development of projects based on DeFi to offer ETH holders secure, reliable non-custodial ETH staking options.
Currently, both Obol and SafeStake are running their testnets with a significant number of users/entities who have shown interest in helping to decentralize Ethereum 2.0 by expanding the base of validators in this important ecosystem.
On the other hand, SSV continues to generate the necessary open-source infrastructure for Service as a Staking (SaaS) to become a reality in custodial-free services using DVT.
With the inherent concerns about centralization of staking in Ethereum and the potential censorship that can be applied to some blocks as recently happened on this blockchain network, the use of SafeStake or any other protocol that uses DVT may be a potential solution to achieve the desired decentralization in the new ETH 2.0.
About ParaState
Parastate is participating in ETH 2.0 PoS with a new tech stack called SafeStake, a trust-minimized middle layer that promotes decentralized ETH 2.0 staking. SafeStake is the first Ethereum liquid staking pool protocol written in Rust that implements distributed validator technology (DVT). It utilizes HotStuff consensus and BLS Threshold Signature architecture to provide robust security and reliability, so validators can maximize their ETH staking rewards.
