🤖Verification Mechanism

Distributed Validator Technology (DVT) is a decentralized, open-source protocol that allows validator duties to be distributed across a cluster of nodes rather than relying on a single machine using threshold cryptography. Essentially, DVT adds an extra layer of fault tolerance to Ethereum validators, eliminating single points of failure and centralization issues. DVT combines distributed key generation, Shamir's secret sharing, multi-party computation, and Istanbul Byzantine fault tolerance.

Why DVT

The goal of Distributed Validator Technology (DVT) is to address centralization and validation efficiency issues in traditional blockchain systems, thereby enhancing the overall security, decentralization, and performance of the system. Below is a more detailed exploration of some implementation methods, challenges, and practical application scenarios of DVT:

Implementation Methods

Validator Sharding

Validator sharding is a common method for implementing DVT. In this approach, the entire network is divided into multiple shards, each handled by a group of validators. This not only allows for parallel processing of multiple transactions and operations but also reduces the load on individual nodes.

Multi-Signature and Threshold Signature

In DVT, multi-signature or threshold signature techniques can be used to achieve distributed validation. This means that the validity of a transaction or block requires signatures from multiple validators to be confirmed. This increases resistance to malicious behavior, as attackers would need to control multiple validation nodes simultaneously.

Cross-Chain Collaboration

DVT can also be applied to cross-chain technology, allowing validators from different blockchains to collaborate, enhancing interoperability and security between different blockchain platforms.

Enhancing User Control and Reducing Trust in Oracles

Staking keys do not belong to the oracle's staking keys but are P + Q, where Q is the key held by the oracle, and P is the key held by the DLK holder. Due to the arithmetic properties of BLS signatures, the oracle can sign using Q, and the DLK holder can use P to sign their own, and the two signatures can be added together to create a verifiable signature of P + Q.

Constants Defined by DecentraLink

DecentraLink defines three constants:

• N: The total number of oracles in the oracle system.

• k1: The number of oracles that can sign messages together with the DLK holder (e.g., k1 ~= 0.2 * N).

• k2: The number of oracles that can jointly sign messages without the DLK holder (e.g., k2 ~= 0.8 * N).

We require oracles to maintain two secret shared keys:

• Q1, in a k1-of-N secret share.

• P + Q2, in a k2-of-N secret share (each DLK holder has a copy of the latter).

Through Q1, oracles can sign together with the DLK holder, and through Q2, they can sign independently.

With k1 + k2 = N (e.g., k1 = N/5 and k2 = 4N/5), this ensures no slashing or inactivity leaks occur in both cases:

• More than just k2 oracles are honest (as they can sign messages independently, and a malicious DLK holder cannot achieve a quorum for k1 co-signing).

• At least k1 oracles are honest, and the DLK holder is also honest (as the two groups together can sign messages, while the remaining oracles cannot sign nor block them).

This style is similar to the first-stage helper wheels used for rollups, creating a linear blend between two security models as a way to partially trust both but not over-trust either.

Note that this design can be seen as a generalization of ideas 1 and 2 (or even the "DLK holder can sign alone" strawman proposal): k1 and k2 can be adjusted as needed to explore the entire trade-off space of who and what to trust.