Contents:

Introduction
How does it work?
What can it do?
  Reducing challenges to maintaining a validator
  Safeguarding the network from attack
When might it come?

Introduction

Ethereum requires that every action performed by a validator including proposing and attesting to blocks must be signed by a singular immutable private-key. To operate a validator across multiple devices/users concurrently requires the sharing of the validator’s private-key. Such an environment is not only prone to clear security vulnerabilities but also leaves users vulnerable to slashing as each instance that proposes or attests to distinct blocks in the same slot will incur penalty (How can validators be slashed?). Users running validators or businesses offering products (i.e. staking pools) are confronted by the necessity to operate continuously without distributed services to avoid points of failure. However, Distributed Validator Technology (DVT) would allow for a validator’s private-key to be split in a manner that allows for multiple devices/users to run said validator concurrently without consequence. Derived from this deceptively simple change are benefits of immeasurable scale: improving liquid staking experiences, safeguarding the network from attack and reducing challenges associated with maintaining a validator.

How does it work?

As previously explained each validator requires their own private-key to operate (How do validators join the Ethereum network?). Currently these keys are constructed in such a manner that they cannot be shared without sharing the entire key - an aforementioned risk. In contrast DVT promises a method in which they can be split into separate distinct shares to be distributed across devices/users without risk. No single share would on its own reveal any information about or be able to perform the tasks that require the private-key. If a certain number of these were used in unison they would still be unable to reveal any information though they would be able to perform tasks including proposing and attesting to blocks. It can be thought of as similar to a council debating a bill; as long as a quorum of members are present the debate can continue regardless of which members are present, and, as long as a quorum (otherwise known as a threshold) of shares sign the proposal/attestation can be performed regardless of which shares are used.

DVT is no more and no less than this deceptively simple change but the opportunities provided are anything but deceptively simple. By distributing operations of a validator there is no need to mitigate the chances of a single malicious device/user being able to employ their authority to act detrimentally to others and the network as a whole. In addition, as long as the threshold required is set to more than half of the total shares it is not possible for the validator to be slashed as a consequence of accidental double proposal or attestation. To provide some context an example of DVT used in one of many possible applications can be demonstrated. Assuming a user is operating a validator from a central server and wishes for 4 backup servers for situations when the central server has downtime, they could employ this technology. When constructing the private-key for the validator it would be split into 5 shares distributed to each device (1 for the central server and 4 for the backups). From here the user could decide to set the necessary threshold of shares for proposing/attesting to blocks to 3, allowing for up to 2 devices to be offline without impacting the validator functionality. As can be seen this has the potential to change how users/businesses and validators interact.

What can it do?

Reducing challenges to maintaining a validator

Even though Ethereum has recently transitioned to a proof-of-stake model that doesn’t require an array of CPUs, GPUs and ASICs, computational requirements are still beyond the average user’s access. This does not represent the only financial costs either, as each validator is required to stake 32 ETH which is also beyond the average user’s access. Most individuals are thus currently inclined to participate in staking pools which allows them to invest what financial resources they have available without significant barrier. To this date it has served satisfactorily to allow for earnings but it has not supported those that wish to actively participate in the network and it leaves the network as a whole more vulnerable. If a staking pool encountered a bug or was the victim of an attack it would be possible for a large amount of the stake that secures Ethereum to become used maliciously against the will of those users. Allowing these users to instead be able to organise more flexibly how they participate in the network would remove many associated risks.

By using DVT to share a private-key among members of a group it is possible for each individual member to have greater control of a validator without requiring investment that they don’t have access to or having no option but to join a staking pool. Those that are able to run their own validator, but have also not been able to run a backup, can now avoid reduced possible earnings due to downtime if the main client or device that the validator operates from is compromised. Many businesses that require a functioning validator to provide services have also navigated needing to run backup validators despite the current and very present danger of accidental slashing. It would be possible instead through DVT to operate a validator across numerous backup devices, as an example was provided of above, to reach the uptimes expected of most modern network services.

Safeguarding the network from attack

One of the core requirements to the stability of any network, the cybersecurity of an information system, is the guarantee of continued availability. Blockchain was always intended to unify what has been achieved in most networks (confidentiality and integrity) with availability. Completion of the trifecta would herald many possible services to all users; and while completion may not necessarily be possible, getting close is an achievement. Ethereum like Bitcoin before it has been able to provide availability for payment networks, but has struggled to more agnostically provide this for all service types. Reducing points of failure through a distributed network such as the thousands of validators that propose and attest to blocks is the main tool available to achieving this.

As discussed previously, businesses providing services through the Ethereum network currently are often reliant on a single validator. Running backups risks accidental slashing and when the primary validator fails due to a bug or malicious action the entire service will also fail. It can perhaps be seen clearly here how the usage of DVT would severely decrease potential points of failure and come closer to the completion of availability. By allowing multiple backup validators, something more akin to a cloud service is possible with multiple devices distributed across geographic and network boundaries all working in unison to reduce the time a service may be down for. More than just backups though, DVT can also allow for advanced access control lists where businesses or communities of users are able to allow greater participation without sacrificing on security as in the case of liquid staking above.

When might it come?

There are currently numerous implementations of DVT being worked on by several organisations. They primarily intend to build this technology without changing the way Ethereum works from its underlying principles, meaning that these changes will be possible through soft forks (updates to the chain without needing to update validators). Of the organisations Obol and SSV Network are most progressed and have already begun building liquid staking platforms on testnets using DVT. Safe Stake and Diva Staking are also progressing but have not yet achieved similar targets. Beyond these observations it is difficult to conclude when DVT might come to Ethereum in full fashion, but keeping track of these projects will allow you to be ready for when likely changes will occur. In the meantime developers and businesses can also develop services and test applications on testnets.