As staking volume increases in Ethereum, the centralisation risk increases, making the network less resilient to attacks or technical failures. Although current Liquid Staking providers such as Lido have made it easier for people to stake their ETH, there’s still a long way to go to decentralise the network.

That’s what protocols using Distributed Validator Technology (DVT) aim to do, and in this article, we will go over what makes DVT a crucial tool for the health of Ethereum.

The main issues for staking ETH

If you want to become a staking operator on Ethereum, helping to decentralise the network and earning staking rewards, you have to first be aware of the two significant risks: key theft and node failure. First of all, there are two private keys involved in the process of validating on the Ethereum network, which are the signing key and the withdrawal key, and they can be stolen if you don’t secure them correctly. Also, node failure can occur if you have a validator client software bug or a weak Internet connection that makes your validator node go offline, resulting in slashing penalties, i.e. a fraction of your staked eth is taken away.

Those two staking risks can discourage the average Ethereum user from running a validator node, but on top of this you also need to stake a minimum of 32 ETH to go for it, which is approximately $50k at today’s prices! These barriers to entry can explain the success of custodial staking solutions offered by many centralised exchanges that make it much easier to stake for regular Ethereum holders.

Still, this solution has a major downside, as the exchanges are in control of your assets, holding them with their own private keys and, as we like to say in crypto, “not your keys, not your coins”. That means you have to trust the custodian with your crypto, and the history of the blockchain space is littered with examples of this going wrong: exchanges can halt withdrawals or even go bankrupt. This staking solution is against the ethos which blockchain stands for and represents a considerable risk of centralisation.

Kraken, a centralised exchange jurisdiction in the U.S., has recently been forced to stop offering its centralised staking solution, after settling with the Securities Exchange Commission (SEC) and paying a $30million fine. That does not suggest a bright future for custodial staking solutions.

What is Distributed Validator Technology?

To simplify it, you can think of DVT as a multi-signature wallet for running a validator node. Its strengths are that it minimises the staking risks and lowers the financial threshold required to stake on the network significantly from 32 ETH to a much lower number.

Distributed Validator Technology is an open-source protocol that decentralises the duties of a validator by allowing a group of network validators to act as one single validator together. With DVT, we avoid having a single point of failure in the architecture that could result in slashing penalties. This magic trick is possible thanks to four key components: 

1. Distributed Key Generation
2. Multi-Party Computation
3. Shamir’s Secret Sharing
4. Istanbul Byzantine Fault-Tolerant algorithms

Some Liquid Staking providers are currently using this technology, including Diva Labs and Obol. 

Distributed Key Generation

For the DVT to work, we first need to split the private validator key into as many parts as they are participants in the consensus group, using the Distributed Key Generation. This cryptographic process allows many parties to hold only a portion of the private key so that no group member knows the complete private key. This prevents any malicious member from signing messages alone and taking control over the validator node.

Shamir’s Secret Sharing

Shamir’s Secret Sharing is the algorithm that allows the reconstruction of the private key without requiring the knowledge of every key share. As a result, if a node is offline or acting maliciously, the other nodes can still reconstruct the private key and sign messages, avoiding slashing penalties. Moreover, to take control of the validator node, an attacker would need to steal a specific number of key shares known as the threshold, making an attack much more complex than if the validator’s private key was stored on a single machine.

Multi-party Computation

This protocol plays a crucial role by combining Distributed Key Generation and Shamir’s Secret Sharing to enable the Distributed Validator Technology to function effectively. Multi-party Computation allows the cluster of operators to sign messages and perform computations without rebuilding the complete private key on a single device. This eliminates the risk of centralising the private key, thereby maintaining the decentralisation of the validator setup.

Istanbul Byzantine Fault Tolerance

The Istanbul Byzantine Fault Tolerance (IBFT) algorithm is utilised in a DVT set up to establish a consensus on a block by designating one Beacon node as the leader. The leader proposes the block to other Beacon nodes, and if over 66% of them approve it, the block is added to the blockchain.

If the designated leader goes offline or becomes compromised, IBFT will reassign the role to another DVT Beacon node within 12 seconds.

DVT can potentially improve the Ethereum network’s decentralisation by making staking more accessible and less risky.

The improved accessibility is accomplished by allowing individuals holding less than 32 ETH to participate in the validating process by pooling with other people without abandoning the custody of their funds and minimising the risks of a standalone validator node. However, using multiple hardware devices and increased architectural complexity to create a cluster of validator nodes comes with added costs.

Conclusion

In summary, DVT aims to minimise failures by integrating autonomous DVT nodes into a robust network in an active-active setup that surpasses individual ETH staking active-passive setups. It enhances ROI for stakers, promotes network decentralisation, and mitigates staking risks through superior security, robustness, performance, and validator uptime.