What is DVT and How Does It Improve Staking on Ethereum?

If you haven’t yet heard, Distributed Validator Technology, or DVT, is the next big thing on The Merge section of the Ethereum roadmap.

Wait… you may be asking…aren’t we already done with the Merge? Well yes, but it was just another milestone in developing Ethereum proof-of-stake. Now that the Beacon Chain has merged with the Execution Layer of Ethereum, there’s still a ton of work left to do to ensure that the consensus layer of Ethereum can meet the demands of becoming the next world computer.

What is Distributed Validator Technology (DVT)?

DVT is a technology primitive that allows an Ethereum PoS Validator to be run on more than one node or machine. This allows a cluster of nodes run by an individual, group, or community of operators to act together as a single validator on Ethereum. Running a validator as a cluster of nodes improves its resiliency while greatly reducing the slashing risk of honest validators, regardless of its size. This makes staking more robust and accessible for all validators.

• For larger validators, DVT ensures high availability and lowering infrastructure costs.
• For smaller validators, like community staking pools or at-home validators, DVT grants a comparable level of protection that a larger validator would have.

Ultimately, this improves validator participation, leading to greater stake decentralization.

Why does this matter?

Single-node validators create single points of failure in Ethereum’s consensus layer that lead to several problems and risks:

• It’s way too common for a validator to go offline: Machines fail. That’s just a fact for computer networks. Single-node validators have no protection for machine failures. If the node goes down, the validator goes down. That leads to missed rewards for stakers and less stability in Ethereum infrastructure overall. To combat this, larger validators who are capital-rich run active-passive setups to have a failover environment in case the primary one goes down. But this leads to the next problem.
• It’s possible for both nodes in an active-passive setup to be attesting, which leads to slashing: To run an active-passive setup effectively, there must be automated scripts that detect downtime and immediately spin up the passive environment. But misconfiguration, errors in scripts, or lack of monitoring can lead to the scenario where both nodes are actively attesting using the same validator key, which leads immediately to a slashing event. This is a risk that all validators with backup nodes must take, with only larger validators having the technology and support to be able to adequately mitigate that risk.
• Validators have hot keys that can be compromised: Since each validator node must manage its key and be connected to the internet, this is a potential attack vector for hackers to steal keys and cause validators to get slashed.
• 32 ETH still represents a high barrier for individual at-home validators: While the minimum requirements for ETH to start running a validator has gone down significantly since the early days of PoS development, 32 ETH still represents a 5-figure (or more) investment to become a validator (not to mention all the time and money needed to run the validator itself). This presents a natural deterrent for stakers to validate themselves, instead needing to trust a third-party custodian to stake ETH on their behalf.
• Stake and client centralization leads to correlation risk in the network: Since it takes people, money, and resources to properly maintain high availability and mitigate slashing or security risks in validators, there are increasing returns to scale that creates a natural stake centralization force in the network. This stake centralization can also lead to client centralization (since it’s easier for operators to support only one or two client configurations). There’s also the worst case scenario of a malicious node or pool operator, which combined with increased centralization can have a massive impact on the entire network.

We’ll discuss how DVT addresses each of these problems present in PoS Ethereum today, but first, let’s talk about how DVT works.

How does DVT work?

As mentioned in the definition above, DVT allows validators to be run as a cluster of nodes rather than a single node. A Distributed Validator (DV) cluster operates with each node holding a key share of a complete validator key (without the full validator key ever existing in one location at any point in time). When active, each node in a DV cluster attests using their key share to generate partial BLS attestations (a fancy cryptographic signature theme you can learn more about here), which is then combined using threshold BLS aggregation to attest as a full validator node. Without getting into the math of how it’s done, this means that as long as the threshold of active validator nodes is met (3 out of 4, 5 out of 7, 7 out of 10, etc.) the DV cluster will attest normally. Said differently, even if some of the nodes in a DV cluster go offline, it would not affect the overall performance of the cluster as long as enough nodes are live to meet the signing threshold.

An analogy that can be used here (with some key differences) is that multisig is to wallets as DVT is to validators.

Here are the steps to setup an (Obol V1) DV cluster:

• Form a trusted group of operators
• Generate a cluster definition file using the Obol DV Launchpad
• Run a Distributed Key Generation (DKG) ceremony to generate key shares
• Each operator configures and runs their node, forming a small P2P network.
• Activate the validators in the cluster by depositing a total of 32ETH for each validator (each cluster can run multiple full validator nodes).
• Once enough nodes are running to meet the threshold, the DV cluster will actively attest!

How does DVT improve staking on Ethereum?

In short, DVT allows validation to be performed together with clusters of nodes instead of only as single, standalone validator nodes. By removing single points of failure, DVT enables validators to operate with active redundancy while not increasing slashing risk. This benefits validators of all sizes:

• Large Validators: For larger validators, improved redundancy and lower slashing risk allows more nodes to be run on fewer machines, which lowers hardware cost. It also reduces the amount of slashing insurance necessary to protect themselves. Additionally, running multiple nodes per cluster allows for a higher distribution of client configurations and geographies, reducing the correlation risk of failure in any single location or client type.
• Liquid Staking Protocols: For liquid staking protocols, in addition to improving efficiency and reducing risk, DVT allows for higher operator participation. By providing redundancy in the network, LSPs remove the dependency on any one operator leading to downtime in the network. Operators can be organized into different clusters such that if one operator goes down, it does not affect any full validator node in the network as other active operators will meet the thresholds for attestation. Ultimately, this improves the performance of the protocol for stakers.
• Community & At-Home Validators: Most importantly, with DVT smaller validators can also run nodes more confidently, delivering on uptime and efficiency metrics comparable to larger validators. This can be achieved by at-home validators operating with others as a community validator that doesn’t rely solely on any single machine. DVT also lowers the ETH requirements for any individual who wants to run a node since you can now have multiple nodes make-up the requisite 32 ETH for validation. With this, DVT has the potential to exponentially improve at-home validator participation.

Regardless of what type of validator you are or what you ultimately believe the distribution of validators should be, DVT acts as a decentralizing force on the entire Ethereum network while adding resiliency and reducing risk. This is a technology primitive that will benefit everyone in the Ethereum ecosystem.

With that said, there are some considerations that should be taken into account.

What are the tradeoffs with DVT?

To achieve redundancy, DVT adds a middleware component to Ethereum consensus, and with it there are certain tradeoffs:

• Increased Complexity: As with any multi-node deployment, there are now more moving parts to running a validator as a whole. This requires limited coordination across the different operators in the cluster, and adds potential areas for things to go wrong.
• Latency: DVT introduces a few additional network hops by the consensus mechanism and message sharing across nodes in a cluster. This, however, is mitigated by designing DVT to use direct P2P connections across nodes in a cluster (rather than a singular gossip network).
• Operational Costs: As multiple nodes are required to participate instead of just a single node, there are increased operational and hardware costs. This can be offset by being able to run more validators on the same set of machines due to the improved resiliency of validators running DVT.

With the ossification of Ethereum, there will be an increased need for middleware components to provide necessary services on the Ethereum network without requiring protocol-level changes. The tradeoffs mentioned above are present with any middleware, and while design choices should be made to mitigate these as much as possible (we'll be publishing a blog shortly about how we’ve designed Obol to handle these tradeoffs), the benefits of middleware would outweigh any of these drawbacks.

Where does DVT go from here?

With the completion of The Merge, it is critical for the entire staking community to play a part in developing, testing, and adopting DVT to reduce potential network failures, improve decentralization, and continue to scale the network. It is important for the ecosystem to realize that validators should be run as communities and not as individual entities. Here at Obol Labs, we are committed to the effort of getting DVT to Mainnet, and we look forward to collaborating with everyone in this important effort.

Additional Resources

Looking for more details on DVT? Check out these other articles and talks from the community for deep dives into DVT-related topics.

• Sorting Out Distributed Validator Technology, by Isaac Villalobos and Albert Garreta from Nethermind
• A tour of Verifiable Secret Sharing schemes and Distributed Key Generation protocols, by Ignacio Manzur, Marc Graczyk and Albert Garreta from Nethermind
• How to Design DVT While Ensuring Non-Correlation, by Collin Myers and Oisin Kyne from Obol Labs, session at Devcon VI
• BLS Multi-Signatures With Public-Key Aggregation, by Dan Boneh, Manu Drijvers, and Gregory Neven from Stanford
• Proof of stake rewards and penalties, by Paul Wackerow from Ethereum Foundation