Since Ethereum’s Shapella upgrade made withdrawals live for stakers, more than 4 million ETH has been deposited in staking contracts. This takes the total ETH currently staked to 23.4 million (20% of all ETH) on 731k validators. Lido leads the category by a distance, with Coinbase and Binance leading the centralised exchange liquid staking narrative. Rocket Pool has shown 2x growth compared to Lido but is still struggling to attract big ETH stakers due to a shortage of validator operators. Kiln, an institutional staking platform, has seen rapid growth as enterprise interest in ETH has taken off.
However, with the growing number of validators with each entity, as well as the risks associated with malicious behaviour and downtime, handling private keys for each validator is becoming a growing challenge. Lido manages 232k individual private keys and even if one of them is misplaced or revealed, the 32 ETH deposited to that validator comes at risk. Moreover, for individual validators, the risk of prolonged downtime can lead to slashing. Multiple research parties are working on mitigating validator operation risk using Distributed Validator Technology (DVT). Researchers at Ethereum Foundation are looking at changing the max staked ETH limit per validator (32 ETH) to reduce the network communication complexity and aggregate large operators into a smaller number of validators.
In this month’s newsletter, we deep dive into DVT and max balance proposal and briefly touch upon Decentralised Sequencing Technology (DST) which derives itself from DVT.
Distributed Validator Technology
DVT is a solution that enables multiple non-trusting parties to collectively operate a validator, resulting in fewer single points of validator failure. DVT was first conceptualised by Ethereum Foundation researchers in 2019. It is under development as a plug-and-play middleware solution – like Flashbot’s MEV-Boost – that sits between existing infrastructure components to enhance a validator’s operation. It uses secret sharing and multi-party computation to split a validator’s private key into “key shares” and distribute them across machines. Validators generate two public-private key pairs: validator keys for participating in consensus (stored on the system) and withdrawal keys for accessing funds (stored in cold storage).
The main goal for DVT is component redundancy to improve security for each validator. In an ideal world, implementing active-active (instant) redundancy minimises downtime and avoids the technical complications of switching between active-passive components, but so far, it has yet to be realised at the validator level. This is a key area that DVT is designed to address. DVT utilises the following to achieve better security –
- Shamir’s Secret Sharing – The splitting of a BLS private validator key (“secret”) into multiple key shares.
- Distributed Key Generation – It is a cryptographic process in which multiple parties contribute to the trustless calculation of a shared public and private key set.
- Multi-Party Computation – A technique used during the DKG ceremony and to construct distributed validator signatures. BLS signatures are additive. MPC is used in DVT to generate key shards independently for all actors without revealing them to one another.
- Thresholded Signature Scheme – A predetermined threshold of key shares is required to sign the same piece of data to create a distributed validator key signature.
- Byzantine Fault Tolerance Consensus Mechanism – The coordination process of the machines performing validator duties in a distributed validator “cluster.” One key share operator is selected to propose a duty, while the others agree if the duty is valid and should be signed by the other key shares.
Altogether, the key share signatures combine to create a validator key signature to propose or attest to an Ethereum block.
The various advantages of using DVT are listed below:
- Effectively eliminates the single point of failure risk for an individual validator. As long as a supermajority of the DV cluster is online and behaving honestly, the full validator node will continue to produce blocks.
- Adopting DVT promotes greater geographic diversity, reducing the network’s susceptibility to regulatory attacks and other systemic risks, such as power grid failures.
- It also allows each validator to run many consensus and execution clients, improving validator resilience through client diversity.
- Lastly, DVT lowers the financial barrier of entry by allowing participating sub-validators to collectively fund any minimum self-bond requirements.
Lido has provided grants to primary projects building DVT infrastructure, SSV Network, and Obol Network. Liquid staking solutions like Swell plan to build on top of these upcoming DVT networks, while Diva Labs is in the early planning phase of building its own.
Raising Max Staked ETH Per Validator
In the last few weeks, a proposal on Ethereum Research forums has made the headlines. The proposal aims to increase the MAX_EFFECTIVE_BALANCE (MaxEB) from 32 ETH to 2048 ETH – the current minimum and maximum balance is 32 ETH for an active validator node. While having many validators (731k+) signals decentralization, the MaxEB artificially inflates the validator set size by forcing large staking operations to run thousands of validators (like Lido, Coinbase, etc.).
The change in MaxEB would allow several benefits as it (i) unblocks future consensus layer upgrades on the roadmap, (ii) improves the performance of the current consensus mechanism and p2p layer, and (iii) enhances operational efficiency for both small and large-scale validators.
- Roadmap Perspective: Single-Slot Finality has long been researched and is a critical component of the end-game vision for Ethereum Proof-of-Stake. While there may be more improvements in the aggregation scheme and the hardware, this performance is prohibitively slow in the near term given a validator set of this size. By compressing the validator set, single-slot finality can become an achievable goal much faster.
- Consensus Layer Perspective: The reduced number of validator nodes will help with reducing bandwidth requirements within the peer-to-peer network. Moreover, any reduction of the validator set directly reduces the computational cost of processing the attestations over the duration of an epoch.
- Validator Perspective: An increase in the MaxEB would allow validators to compound their rewards more easily as the set of acceptable active validator values is v ∈ [32, 2048]. It would also allow staking entities to reduce operational overhead and key management challenges by aggregating ETH into fewer validators.
There are several risks as well:
- Changing the MaxEB value brings more complexity to the simple system of “32 ETH”. However, the authors have shared a minimum spec change document to address this challenge.
- The change in MaxEB can also affect the committees in the future roadmap of Ethereum. Given validators have differing stakes, partitioning them into committees may result in some validators having a much larger impact on the committee than others. Additionally, reducing the validator set size also decreases the safety margin of random sampling. The authors have written extensively about the security considerations here.
- The slashing penalties also aggregate with larger stakes, therefore, some companies may still prefer to distribute stakes based on an acceptable risk-reward tradeoff.
- Implementing the new MaxEB value also opens the protocol to new risks that may be hard to predict at the moment. Careful monitoring of the protocol will be required in the early days.
Because the proposal is still in the discussion phase, the reader is recommended to go through the documentation for a detailed understanding. Both DVT and change in MaxEB focus on improving the validator experience and performance/security of the Ethereum network.
Decentralised Sequencing Technology
Coming to layer-2s and sequencers, today’s rollups, like Optimism and Arbitrum, only maintain a single sequencer that is responsible for building and proposing blocks. While this centralised approach offers a simple solution to scale Ethereum in the short term, it is important to consider the implications of sequencer centralisation as transaction volume migrates away from Ethereum to L2s. The centralised sequencers perform both the role of block builder and block proposer and therefore have a lot of power over MEV and transaction ordering/censoring.
Progressive decentralisation using DVT, an existing primitive, can provide a more pragmatic solution to centralised sequencing. Therefore, any use of DVT for decentralising L2 sequencers is often referred to as Distributed Sequencer Technology (DST). Not all sequencers need to decentralise in the same manner as Ethereum’s validator set. Optimism might want decentralised sequencing for security. Gaming studios might want centralised sequencing for speed and flexibility. App-specific rollups might outsource sequencing to 3rd-parties (such as Astria). There is no one-size-fits-all.
There are multiple ways to run sequencers as highlighted below, with varying degrees of latency, implementation complexity, fault tolerance, and decentralisation.
DST improves sequencer liveness by allowing the redundant machines to take over control of sequencing and reduces geographic distribution risk for centralised sequencers as now independent machines can be spun up in different countries. DST also decentralises the rollups sooner while the teams work on creating a permissionless, decentralised, multi-sequencer model with proper incentives. DST however does resemble Proof-of-Authority because of a permissioned network and the power controls the individuals/entities running the DST will have.
Validator security and robustness have been important components of the Ethereum roadmap. Similarly, decentralised sequencers (practically validators for L2s) are important components for layer-2s and their roadmap. We expect a lot of focus and attention to go to these two narratives as we move forward to the second half of the year.
If you were forwarded this newsletter and would like to receive it directly in your inbox, sign up here.Questions? Feedback?
We’d love to hear from you! Simply reach out to us at contact@woodstockfund.com
