The Distributed Validator Protocol Roadmap

Distributed Validators (DVs) are the next critical infrastructure primitive for the Ethereum network to improve security, resiliency and decentralisation. With the initial adoption of squad staking deployments and the eventual release of multiple DV client implementations, there is a growing need to define a DV protocol that establishes a foundation for a credibly neutral, trust-minimised infrastructure layer for Ethereum. This blog post looks at what a DV protocol might consist of, what research has been developed towards this aim, and what our plans for a DV R&D roadmap look like.

Obol 2.0: the Distributed Validator Protocol

The DV Protocol, sometimes referred to as Obol V2, is a research and specification effort started by Obol and Nethermind Research for a middleware specification for Distributed Validators. Influenced by Obol's 1.0 design, which developed a middleware client implementation to favour modularity and trust-minimisation, the work for Obol 2.0 will enable editable clusters, and work towards multiple interoperable DV middlewares. The first DV implementation, Charon, is built by Obol Labs, while the second implementation we hope will be built by Nethermind Research. 

The end game for the DV Protocol is not only to spawn interoperable DV software implementations to run high-performant Ethereum Validators together, but it should also allow for node operators who do not know or trust one another to securely run a DV together. This requires publicly verifiable DKGs, being able to swap out node operators from a cluster, and improved balance around rewards and punishments within a cluster.

DV Protocol Research

To this end, research and development is ongoing in the areas of key generation and management, DV performance, fault attribution, block building, and supporting the broader Ethereum roadmap.

Work on the DV protocol began more formally in May 2023 (and realistically has been ongoing since 2019 when Eth2.0 adopted the BLS signature scheme). Since then, initial research phases have been completed and posted on the Obol Network Research Forum. Published research topics include: 

• Publicly Verifiable Secret Sharing-based Distributed Key Generation
• Key Refresh Scheme for DV operators
• BFT protocol that can mutate its operator set in a byzantine setting
• Using DV clusters for encrypted transaction mempools
• Attributable Consensus Solution for DV Clusters Part I, Part II, Part III, Appendix

(Summaries of each research post can be found at the bottom of this blog.)

The DV R&D Roadmap

The development of the DV Protocol brings a new phase of decentralisation in the project with more involvement, collaboration, and support from the ecosystem. Today, I’d like to share my view of what has been done, and what is still to-do on a R&D Roadmap for Distributed Validators:

Let me dive straight into the details.

The Keys: Improve the security and verifiability of Distributed Validator private key shares.
The absolute core of a proof of stake system lies in the private keys that make up the validator set. The physical security of these private keys is, in my view, the most underappreciated risk posed to Ethereum PoS today. Adopting Distributed Validators moves validators into a multi-sig paradigm. At the application layer, all high-security use cases make use of either smart contract-based or MPC-based multi-sigs, and this is also a must for the consensus layer. 

Today Distributed Validators run on shamir secret-shared private keys, and further, Obol has been the pioneer of Distributed Key Generation ceremonies for these keys. No single developer getting phished should result in your private keys being stolen and your validator getting ransomed under threat of slashing. 

Looking forward, there is plenty still to do on this front, the near term goal is to move from a Verifiable Secret Sharing scheme (VSS) (where one of the private key shares can assert that the DKG was completed honestly), to a Publicly Verifiable Secret Sharing scheme (PVSS) (where anyone can check a proof that the DKG was completed honestly). This increases the security guarantees for a party looking to delegate their Ether to a squad. However, being able to verify this PVSS proof on-chain is easier said than done. The Nethermind Research team have put together this piece evaluating PVSS schemes and their costs to verify on chain. 

Another major aspect of the DV private key roadmap relates to key resharing and refreshing. Ideally every key share could be rotated, while the group public key stays the same. This allows for operators to refresh their keys, either as a precaution or response to a key leak, without necessitating shutting down the cluster and validators. Better yet, if a protocol could be developed that allows operators to withhold information about the new polynomial from particular operators, this scheme could be used to remove malicious or underperforming operators from a cluster without having to exit and recreate the validators. Doing this securely, and handling complexities around liveness and forward secrecy are key challenges to making DVs with mutable operator sets a reality. 

Eventually, single use private key shares would provide the strongest guarantees against private key theft, but getting from here to production with them will be no easy feat.

The Crown: Make DVs as or more performant than standard validators.
One of my biggest fears when beginning Obol was that a Distributed Validator would earn markedly lower rewards than a standard validator. People love yield and tend to underprice risks, so convincing them that they should accept a lower yield for lower risk would have been a difficult battle (until we get obvious proof by way of a mass slashing event). Fortunately, the performance of DVs has massively exceeded my expectations to date. Early testing showed DVs can potentially exceed at least the average, if not the high performing validators, in part due to the fact that duties are being broadcasted from a DV into the network graph from many places at once, increasing its propagation and lowering its inclusion distance. 

However, the consensus protocol we selected for V1 may have been on the conservative end. Early DV prototypes were built on IBFT, while for Obol we selected QBFT. This was due its extension of IBFT to provide liveness guarantees, our access to the authors, and our familiarity with it being in production in Hyperledger Besu. The maturity of the BFT consensus algorithm space has grown at a rapid pace since 2020. Two of the most promising avenues for future DV performance research are the adoption of consensus mechanisms that work under asynchrony, and consensus protocols that are optimistically responsive (meaning they can move faster the slowest operator if enough nodes are ready to). Commendable research in the space include Chainlink’s efforts on verifying the security of two-round hotstuff consensus. One of the design benefits of Obol not being a homogenous network is that different clusters can adopt different protocol variants independently, allowing for R&D to happen in parallel across multiple clusters. I hope to see a future where a number of consensus mechanisms for DVs are production ready, and can be used depending on the trust model of the cluster and what they most want to optimise for, bandwidth, latency, or resilience. 

Consensus isn’t the only aspect of DVs that impact performance, but it is a large piece of the equation. Other things like wire protocol, and intelligent handling of head slot re-orgs will also make impacts on DVs performance as they mature. 

The Blocks: Support the future of block building and block proposal on Ethereum
You can’t have a blockchain without blocks. To reach V1, Obol needed to support full block proposals and MEV-extracting blinded blocks. The long term roadmap for block building can be broken into three tracks: 

• First, censorship resistance. These are Ethereum L1 roadmap items designed to make it more difficult to compromise the chain: Single Secret Leader Election (SSLE) is a change to make the future proposers a secret to everyone but the proposer themselves. Meanwhile, inclusion lists are forcing mechanisms to guarantee a set of transactions be included for a block to be valid. Finally, Enshrined Proposer-Builder Separation is a replacement for the out of band MEV-boost setup validators often run today. 
• Mitigating MEV is a research stream around how to mitigate the extraction of value that proposing provides. Promising designs in the space are shutterised beacon chains, (driven by Shutter.network,  Nethermind Research and Gnosis Chain) and parallel proposers, which move proposing to a race rather than a monopoly, changing the game theory around delaying blocks to extract more value. The Nethermind Research team has already done some analysis into various MEV mitigating strategies that DVs may enable, but there is a long road ahead to reach something that works for the entire chain, not just DVs. 
• Lastly, ‘selling better block space’ is the idea that DVs should lean into their extra powers when it comes to proposals. Designs like “Proposer Enforced Protocol Commitments”, “Proposer Promised Pre-Confs”, “Based Preconfirmations” and others attempt to leverage the 32 Ether of skin in the game that a proposer has, in order to provide guarantees about things like ordering,  inclusion, and validity. Generally these designs assume an Eigenlayer-like mechanism to slash a proposer that opts-into the mechanism but fails to fulfil its requirements. One drawback of these designs is that some use cases need more than 32 ETH of security. (e.g. sequencing a sandwich attack for 100s of Ether, defection might be profitable in this case). This is where the idea of BFT pre-confs, or PEPC-DVT can add incremental security on top of proposer commitments.

The long-term goal for Ethereum is to achieve single slot finality. Until then, applications needing low latency L1 inclusion confirmation can get a reasonable amount of security by leveraging both proposers’ skin in the game, and the ‘honest majority’ assumptions that BFT systems provide.

The Blame: Enable fault attribution to penalise lazy or malicious DV operators
The end goal of DVs is being able to run them with counterparties you don’t know or trust, while having high confidence that the validator will be safe and performant. Since the very first public presentation on DVT in 2019, it was acknowledged that if you provide fault tolerance, some operators could take advantage of that and free-load on the effort of the others in the cluster. The problem is, it is extremely difficult to identify free-loading, without perverting incentives, relying on a trusted third party, or massively dragging on rewards. The Nethermind Research team produced a mammoth, four-part research piece on attributable consensus within DVs (Part I, Part II, Part III, Appendix), but I don’t think the current design is simple enough for production just yet. I believe that it will be more feasible to design something complete and uncompromisable, as fraud-proof implementations, and zkVMs mature, and zkState Channels come into existence.

The Base: Make DVs the base for LSPs, staking, and L2s’ integration into the L1 validator stack
If DVs are to be as impactful as I hope, they need to go further than isolated validator deployments. Thankfully, because we built Charon as an infrastructure-agnostic, middleware implementation, existing staking products can be converted to be run on DVs while allowing them to keep their own choices on other parts of their architecture – i.e. network, token-design, etc. It’s great to see Lido’s SimpleDVT come to mainnet, and we hope to work together with LSPs and LRTs to see more of these deployments in the future.

The Lab: Prepare DVs for the wider Ethereum roadmap
Although the roadmap for DVs is huge, it’s just one box on Ethereum’s broader roadmap. DVs need to keep up with all of the broader goals of Ethereum, and not become a laggard or hindrance to designs the L1 wants to adopt. Fortunately, validators being MPC-compatible has been a stated design goal for proof of stake Ethereum since 2019 or earlier, so I am optimistic that the core devs and researchers appreciate and want to keep multi-party validators as a feature of Ethereum’s proof of stake. Some of the goals that impact DVs (for the better!) include: EIP-7251 Max effective balance (increases the risks of validators by upping their size), EIP-6800 Verkle state trees (makes syncing a node fast and reduces disk space requirements), and Execution tickets (separates the concerns of building and proposing from attesting).  

Conclusion

Our goal is to evangelise squad staking in all forms: this means bringing down the barriers to entry to allow for more home stakers to contribute to Ethereum’s security, further improving the security and diversity of professionally operated nodes, and enabling more decentralised multi-operator setups that strengthen the network as a whole.

While we have (in my eyes) a stellar, V1 client, people understandably want mutable DV clusters and un-gameable rewards and penalties; so we will deliver them when they are secure and performant and ready for the high-stakes of Ethereum validation. Stay tuned for a phase-based rollout of the DV protocol, a spec, and some more unannounced news over the coming months. :)