Distributed Validator Technology (DVT)
Distributed Validator Technology (DVT) is an exciting new security technology in the restaking space. Essentially, it splits a single validator key into a set of pieces called key shards and hands them out to a group of node operators called a cluster. These node operators then create or attest to a block (like they normally would), submit their replies, and if >66% of them agree, put together their key shards to submit their final vote as one validator. In this way, a minority of node operators in a cluster are malicious or inactive, the validator still validates and earns fees.
The risk of slashing and inactivity penalties are what DVT was created to mitigate.
How does DVT make validators more secure?
It is in fact DVT technology that lets us set our node operator bond to be so low.
Firstly, DVT makes it very difficult for a node operator to be malicious. Clusters are created based on auction results and deliberately shuffled around. Thus, even if someone operates multiple nodes, it is highly unlikely that this person would ever provide more than the majority of nodes in a single DVT cluster.
Secondly, the vast majority of slashings that ETH has ever received were the result of accidental double-signing of a block. Thanks to DVT, this becomes impossible. The validator key is split into shards and can only be recreated from the agreement of a majority of node operators, meaning it would be impossible for any one node operator to double-sign a block - they don't have the key.
Finally, nodes check each other's work, meaning that false timestamps or block heights are unlikely to occur - the other nodes would quickly outvote the faulty node operator's result.
DVT & inactivity protection
Consequences of inactivity
An inactive validator brings two sad results:
A lack of capital efficiency - it doesn't make money and could miss a block proposal
Inactivity penalties
Inactivity penalties are a consequence of the current structure of the Ethereum blockchain. It is not possible to forcibly eject validators (unless slashed and consequently banned). The only way to remove an inactive validator is by slowly depleting their ETH balance until it falls below the minimum of 16ETH, after which the validator set ejects them automatically. Therefore, if a validator is inactive, it will start receiving penalties until that balance is reached and they are removed.
Maximum inactivity penalty
By consequence, an inactive validator can, in the worst case, lose up to 16ETH of their stake. That's a problem, and becomes even graver if the validator is operating with capital borrowed from a staking pool. For that reason, many staking pool protocols set their minimum node operator stake/bond to 16ETH in order to protect their stakers' assets.
This has been the most difficult barrier to overcome in reducing node operator bond. And fortunately, DVT is the answer.
How DVT avoids this
DVT, acting as a mini-consensus-layer, can not only continue operating if a minority of nodes go offline for short periods, but can also be designed so as to forcibly eject nodes that are inactive for too long, without having to slash them. In that way, DVT is also a massive benefit for node operators - any extended accidental inactivity is not punished financially.
Node operator inactivity limit
Byzantine Finance's DVT configuration ejects node operators from a DVT cluster if they are active less than 80% of the validator's time.
Currently, the protocol's minimum activity time limit in a DVT cluster is set at 80%.
Technical details
Key terms
| Term | Explanation |
|---|---|
Cluster | A group of node operators acting as a validator. |
Validator | A single validator, as perceived from the perspective of the ETH blockchain. |
Node operator | A computer. Can be big. Can be small. As long as it does the math right. |
DVT cluster size
Our smallest and most frequent DVT cluster size is 4.
A DVT cluster of size is always sized by applying:
where is a positive integer.
The reason for this is a 1982 paper about how to best invade Byzantium how to handle a system of nodes giving conflicting information. In summary, the paper proves that if a system of communicating nodes has faulty or dishonest ones, then honest nodes are required to identify the villains and reach agreement.
In practice, dishonest behaviour happens very rarely, whereas faulty behaviour (i.e. power cuts, internet outages, etc.) happen all the time.
Cluster sizes can be optimised for tolerance of faulty nodes or dishonest nodes. Here at Byzantine Finance, we choose to optimise for both, and the formula above does precisely that. If you're interested in a more detailed explanation, see this page.
Creation of new clusters
New clusters are created when a new batch of 32ETH enters the protocol vault, either through liquid stakers or through full stakers.
The cluster is filled with operators in the auction set that have remainign validation credits (VCs). If not enough such operators are found, an auction is launched to fill the remaining slots in the cluster.
Changes to existing clusters
It is possible for an operator to be removed from a DVT cluster, via:
Choice - if they choose to exit early and burn their remaining VCs
Time - if the operators VCs run out and they choose not to renew
Force - if the operator has acted malicioulsy or has been inactive for too long
In any of these cases, a new auction is launched to fill the empty slot.
Closure of clusters
Clusters can be closed by the staking pool or by the full staker in case they withdraw their ETH. In that case, all operators are returned to the auction set and the remainder of their VCs is returned to them.
Rewards distribution under DVT
In the unlikely case that a DVT cluster acting as a validator receives a minor penalty, rewards will continue to be paid out - the penalty is paid for by the 1ETH bond that each of the cluster members put up.
Rewards as well as penalties incurred by a cluster are split equally among node operators.
Thus, the return for a validator (accrued daily) is computed as:
Where is the number of operators in the DVT cluster.
Last updated
