Explaining Distributed Validator Technology (DVT)
Introduction
After the Merge’s success, the Ethereum network transitioned from a Proof of Work (PoW) consensus model into a Proof of Stake (PoS) one, making it a less energy-intensive blockchain. However, amid the numerous positives that the merge appears to have yielded, a threat of centralization is beginning to rear its ugly head. Thankfully, the Distributed Validator technology can address most of the problems that are associated with this danger.
The task of validating the blockchain has fallen to staking clients instead of miners. Under PoS, the job of a crypto validator is to be responsible for verifying transactions and confirming or proposing to add new blocks to the blockchain network. If the validator's attestation or proposal is timely and accurate, they’ll earn rewards in ETH.
In theory, anyone can set up a validator node, stake the required amount of ETH, and participate in the network. Yet, several intending validators are instead going through staking services, with all their risks. But why?
In this article, we’ll look at the current issues (spoiler: centralization) for validators and stakers on Ethereum PoS and how those problems can be solved with Distributed Validator Technology (DVT).
Issues with the Ethereum PoS model
There are a range of risks for validators and stakers alike when it comes to the Ethereum PoS model. Let’s have a look at each of these issues.
Centralization
When it comes to retail users, especially those holding small amounts of ETH (Ethereum PoS requires 32 ETH to run a validator), it becomes a complicated procedure for them to set up a validator or maintain it. Hence, it’s very likely that these network participants are inclined towards staking their ETH via staking services.
Since most crypto users hold their funds on custodial platforms such as centralized exchanges, they’re likely to also use a custodial staking service to stake their ETH. Even though custodial staking services promise ease of use and convenience, there are several risks associated with using them, the chief of which is centralization. A central authority is not exactly good news in a global monetary network, and the idea of handing over your keys to an operator who is not immune to slashing penalties, errors, hacks, or even censorship can be devastating for the whole ecosystem.
Single points of failure
When a user runs a solo validator, the custody of the validator's private keys is a crucial matter. If a validator loses access to their private keys, they could lose access to their funds. This represents a difficult user experience and constitutes a single-point-of-failure risk. The Ethereum PoS protocol doesn’t make it easier either, as its rules prohibit redundancies of any kind. Thus, a validator can only sign messages or remain online via a single machine.
If an attacker breaks into a validator’s machine and gains access to the private key, their activities can cause the affected validator to suffer a slashing of their stake. When a stake is slashed, a portion of the validator’s locked funds is deducted by the protocol. Ultimately, this leads to a loss of funds, revealing the massive vulnerabilities of a single point of failure.
Validator liveness check
Suppose a validator client fails to sign messages for any reason, ranging from breaks in the network connection or cloud failures to software crashes or hardware issues. In that case, they suffer penalties due to inactivity. They will lose a portion of their staked balances.
Penalties due to double-signing can also arise, especially if a validator suddenly goes offline while signing a message. Thus, validator clients risk deposit slashing if they sign multiple instances with the same key, sign the same message twice, or go offline when others are offline. This favors professional validators and discourages the average user with the resources to become one from being a validator, therefore leading to a few validators retaining most of the power.
Private key custody
There’s a well-known saying in the crypto ecosystem, “Not your keys, not your coins.” If you don’t have custody of your private keys, you’re always at the mercy a of custodial service for the safety of your funds. Staking services offer a way out for participants who do not want to face the risks of dealing with a solo validator setup and maintenance directly, but there's a catch. Stakers using these services have to hand over their private keys to the service in a setting that requires them to trust the staking service operator fully. They must trust the operator for the security of their staking private key.
With staking services, key ownership can be a tricky topic. A sense of security comes with having control over your private keys as a solo validator. Using a staking service will require you to give up that sense of security, trusting someone else to do it for you. For systems where anything can go wrong and malicious actors lurk under the guise of honesty, it is not advisable to trust someone else with the custody of your keys.
Forking penalties
Under the PoS regime, validator clients connect to Beacon nodes. In the unlikely event that a Beacon node to which a validator is connected develops a fault, a fork will be created. If the validator client is affected by this anomaly, it will follow the forked chain and appear offline to the main PoS protocol, resulting in penalties.
—-------------------------------
Centralization is sufficient to defeat the purpose of a permissionless and transparent blockchain, but the threats to security and loss of deposits due to penalties are enough to discourage anyone from participating. These issues have created the need for the development of Distributed Validator Technology. Let’s understand what is Distributed Validator Technology (DVT) and how it aims to solve the issues mentioned above.
What is Distributed Validator Technology (DVT)?
Distributed Validator Technology (DVT) is a decentralized open-source protocol that allows the duties of a validator to be distributed among a cluster of nodes, as opposed to a single machine, leveraging threshold cryptography. DVT provides a decentralized staking layer on Ethereum, allowing anyone to create and share a validator over multiple fault-tolerant machines such that, if any one node is offline or faulty, the validator can continue to perform its duties. The fault-tolerance of a system simply refers to the system’s ability to continue operating despite failures or malfunctions.
In essence, DVT adds an additional layer of fault-tolerance for Ethereum validators removing the possibility of redundancies such as a single point of failure, centralization issues, etc.
Distributed Validator Technology is a blend of distributed key generation, multi-party computation, Shamir's secret sharing, and Byzantine fault-tolerant algorithms that permit validator duties to be split across several nodes without violating the staking rules of Ethereum. We’ll understand these algorithms and what role they play in DVT in the below sections.
In case you’re interested, here’s a video explainer of DVT by Aditya Asgankar from the Ethereum Foundation:
Distributed Validator Technology not only shares a single validator's duties across several machines but also “distributes” its private keys. Remember, Ethereum requires a validator to create or sign messages with its private keys on a single computer. By distributing shares of the private key among a cluster of nodes and utilizing a distributed key generation scheme, DVT eliminates the single point of failure, as we will see below.
DVT emerged as an idea proposed by the Ethereum Foundation in 2019 in preparation for Ethereum's transition to PoS. Ethereum validators operate with an Active-Passive setup in which backup nodes remain offline. When the active node goes offline, downtimes occur before the backup node can come online, as there are no automatic switches. With DVT, validators can now enjoy an Active-Active arrangement, operating like a multi-signature setup and eliminating single points of failure.
How does Distributed Validator Technology work?
As mentioned, Distributed Validator Technology combines distributed key generation, Shamir's secret sharing, multi-party computation, and Istanbul's Byzantine Fault Tolerance. You can look at DVT as a multi-signature scheme, but instead of confirming transactions, it is used to perform consensus-required validator duties on the blockchain.
The Distributed Validator Technology pillar: Distributed key generation
The first and one of the core components of DVT is a distributed key generation (DKG) scheme. DKGs involve multiple parties contributing to calculating and sharing a private key such that no single group member has full control over the secret key. The private key is encrypted and split among all participants.
Usually, these nodes qualify as non-trusting, meaning their operators do not need to know one another, creating sufficient room for fault tolerance. DKG makes way for the threshold signing scheme.
Shamir's secret sharing and threshold signing
Next, Shamir's secret sharing allows the private key to be split such that each participating validator client holds only a piece of the puzzle, and no individual key share is sufficient to sign messages. Instead of requiring every participant to be available to reform the secret or sign messages, Shamir's secret sharing employs a threshold. Typically predefined, this threshold gives room for the validator client to remain online, even in the presence of a faulty or malicious member.
For an example, say we have four operators contributing to a DVT setup, and the threshold for signing messages is 3 out of 4. If one computer goes offline or is not trustworthy, three nodes remain active and can sign messages. With the private key split among four nodes, there is no single point of failure.
Note that Ethereum PoS uses BLS signatures, which allow for aggregation, meaning that it recognizes multiple signatures with the same key and can combine these transactions into one. So, when all participants sign a transaction, the BLS signature system combines all signatures without requiring a complete reconstruction of the private key.
Multi-party computation
Secure multi-party computation plays a critical role in Distributed Validator Technology. Through MPC, contributing operators can use their secret shares in signing messages and performing computation without reconstructing the secret on any single device. With MPC, the threat of centralizing the private key during computation is eliminated, and the decentralized nature of the distributed validator setup remains intact.
Consensus
The final piece in the puzzle is a consensus algorithm among Beacon nodes that can achieve fault tolerance through threshold signing schemes. Consensus is achieved among the Beacon nodes to which ETH validators are connected. Beacon nodes are responsible for assigning duties to validator clients.
Using threshold cryptography, a private key is encrypted and split amongst Beacon operator nodes. A threshold number (3 out of 4, 5 out of 7, etc.) is required for any commands to be issued to a validator client. This way, no single Beacon node operator would have unfettered power over a validator.
To reach a consensus over a block in a DVT setup, the Istanbul Byzantine Fault Tolerance algorithm singles out one Beacon node in the DVT setup as the leader who will propose the block and share it with fellow Beacon nodes. If more than 66% of the Beacon nodes agree that the block is valid, it is added to the blockchain.
If the leader goes offline or is compromised in a DVT setting, the Istanbul Byzantine Fault Tolerance algorithm will reassign the role to another DVT Beacon node within twelve seconds.
Use cases of Distributed Validator Technology
Since its proposal in 2019, DVT has been successfully developed by two leading actors: Secret Shared Validator Technology and the Obol Network. While these are direct projects spun out with DVT as their core, here are the major possible applications of Distributed Validator Technology:
The use of Distributed Validator Technology on Decentralized staking pools
Most staking pools and liquid staking providers today are custodial. They have single points of failure, relying on a single validator node with a single key. Added to the threat of a single point of failure is the challenge of experiencing slashing and penalties across the board.
Using a distributed validator setup, staking pools and liquid staking providers can switch to a decentralized model. In this way, they diversify their offerings and reduce penalties and slashing by ensuring minimal downtimes.
Staking infrastructure providers
To understand how staking infrastructure providers can leverage DVT to offer more robust services, we first need to understand the difference between Active-Active and Active-Passive configurations.
When it comes to cloud infrastructure, there are essentially two options on how to configure connections – Active-Active & Active-Passive. In an Active-Active configuration, traffic is load-shared between interfaces based on flow. If one connection becomes unavailable, then all traffic is routed through the other connection. In an Active-Passive configuration, one connection handles traffic, while the other is on standby.
Companies that provide infrastructure to meet individual or institutional staking need solutions towards redundancies of cloud providers with Active-Passive configurations. With DVT setups, infrastructure providers can enable Active-Active cluster redundancies and encourage dynamism in deployments and configurations.
Solo validator setups
Solo validators that were previously discouraged by high barriers of entry and the risks associated with ETH staking can now participate using a DVT configuration.
With a distributed validator setup, in-house validators can distribute their signing power across multiple nodes. This is done in an Active-Active cluster redundancy arrangement, ensuring they can validate transactions more reliably. Thus, they minimize the risk of failure and penalties due to downtime, double-signing, etc.
In summary, Distributed Validator Technology can be a game-changer
Distributed Validator Technology addresses the many challenges of ETH staking and lowers the entry barrier for the average person while encouraging true decentralization on Ethereum. With DVT, institutional or retail validators can meet the protocol’s requirements of safety or liveness, or even both, increase resilience, enjoy Active-Active redundancy configurations, and diversify their operations based on several factors.
As Ethereum now operates fully as a proof-of-stake (PoS) blockchain, its validators will continue to lean towards more secure and practical configurations for their operations. DVT presents an opportunity for staking on Ethereum to become more decentralized, profitable, and efficient in validating transactions. even for retail participants. Currently, Obol Network is leading the charge in building an ecosystem for trust-minimized staking that enables people to create, test, run & coordinate distributed validators. Hopefully, in the coming months, we’ll see more development in this direction.
About Panther
Panther is a decentralized protocol that enables interoperable privacy in DeFi using zero-knowledge proofs.
Users can mint fully-collateralized, composable tokens called zAssets, which can be used to execute private, trusted DeFi transactions across multiple blockchains.
Panther helps investors protect their personal financial data and trading strategies, and provides financial institutions with a clear path to compliantly participate in DeFi.