Detailed Explanation of Proof of Validator: A Key Security Puzzle on the Road to Ethereum Expansion

Original author: Shenchao TechFlow

Today, a new concept was quietly born in the Ethereum Research Forum: Proof of Validator.

This protocol mechanism allows network nodes to prove that they are Ethereum validators without revealing their specific identities.

What does this have to do with us?

Under normal circumstances, the market is more likely to focus on the superficial narratives brought about by certain technological innovations on Ethereum, while rarely delving into the technology itself in advance. For example, the Shanghai upgrade, merger, switch from PoW to PoS and expansion of Ethereum, the market only remembers the narrative of LSD, LSDFi and re-hypothecation.

But don’t forget that performance and security are Ethereum’s top priorities. The former determines the upper limit, and the latter determines the bottom line.

It can be clearly seen that on the one hand, Ethereum has been actively promoting various expansion solutions to improve performance; but on the other hand, on the road to expansion, in addition to practicing internal skills, it is also necessary to guard against external attacks.

For example, if the verification node is attacked and the data is unavailable, then all narratives and expansion plans based on the Ethereum pledge logic may be affected by the whole body. Its just that this impact and risk is hidden behind the scenes, making it difficult for end users and speculators to detect, and sometimes even not care about.

The Proof of Validator that this article will talk about may be the key security puzzle on the way to Ethereum’s expansion.

Since capacity expansion is imperative, how to reduce the possible risks involved in the process of capacity expansion is an unavoidable security issue, and it is also closely related to every one of us in the circle.

Therefore, it is necessary to understand the full picture of the newly proposed Proof of Validator. However, because the full text in the technical forum is too fragmented and hard-core, and involves many expansion schemes and concepts, Shenchao Research Institute integrates the original posts and sorts out the necessary relevant information, and conducts an analysis of the background, necessity and possible impact of Proof of Validator. Understand the interpretation.

Data Availability Sampling: A breakthrough in capacity expansion

Don’t worry, before formally introducing Proof of Validator, it is necessary to understand the logic of Ethereum’s current expansion and the risks it may contain.

The Ethereum community is actively promoting multiple expansion plans. Among them, data availability sampling (DAS for short) is regarded as the most critical technology.

The principle is to divide the complete block data into several samples, and the nodes in the network only need to obtain a few samples related to themselves to verify the complete block.

This greatly reduces the amount of storage and computation per node. To give an easy-to-understand example, this is similar to our sample survey. By interviewing different people, we can summarize the overall situation of the entire population.

Specifically, the implementation of DAS is briefly described as follows:

• The block producer splits the block data into multiple samples.

• Each network node only gets a few samples it cares about, rather than the complete block data.

• Network nodes can randomly sample and verify whether the complete block data is available by obtaining different samples.

Through this kind of sampling, even if each node only processes a small amount of data, together it can completely verify the data availability of the entire blockchain. This can significantly increase the block size and achieve rapid expansion.

However, this sampling scheme has a key problem: where are the massive samples stored? This requires a complete set of decentralized networks to support it.

Distributed Hashed Table: Home of Samples

This gives the Distributed Hash Table (DHT) an opportunity to show its talents.

DHT can be regarded as a huge distributed database, which uses a hash function to map data into an address space, and different nodes are responsible for accessing data in different address segments. It can be used to quickly find and store samples in massive nodes.

Specifically, after DAS divides the block data into multiple samples, these samples need to be distributed to different nodes in the network for storage. DHT can provide a decentralized method to store and retrieve these samples. The basic idea is:

• Using a consistent hash function, the samples are mapped into a huge address space.

• Each node in the network is responsible for storing and providing data samples within an address range.

• When a certain sample is needed, the corresponding address can be found through the hash, and the node responsible for the address range can be found in the network to obtain the sample.

For example, according to certain rules, each sample can be hashed into an address, node A is responsible for the address of 0-1000, and node B is responsible for the address of 1001-2000.

Then the sample with address 599 will be stored in node A. When this sample is needed, look up the address 599 through the same hash, and then find the node A responsible for the address in the network, and get the sample from it.

This method breaks the limitations of centralized storage and greatly improves fault tolerance and scalability. This is exactly the network infrastructure needed for DAS sample storage.

Compared with centralized storage and retrieval, DHT can improve fault tolerance, avoid single point of failure, and enhance network scalability. In addition, DHT can also help defend against attacks such as sample hiding mentioned in DAS.

Pain Points of DHT: Sybil Attack

However, DHT also has an Achilles heel, which is the threat of Sybil attacks. Attackers can create a large number of fake nodes in the network, and the surrounding real nodes will be overwhelmed by these fake nodes.

For example, if an honest vendor is surrounded by rows of counterfeit goods, it will be difficult for users to find the genuine ones. This allows the attacker to control the DHT network, rendering the sample unusable.

For example, to get a sample at address 1000, one needs to find the node responsible for this address. However, after being surrounded by thousands of fake nodes created by attackers, requests will be continuously directed to fake nodes and cannot reach the node actually responsible for the address. The result is that the sample cannot be obtained, and storage and verification fail.

In order to solve this problem, it is necessary to establish a high-trust network layer on DHT, which is only participated by verifier nodes. But the DHT network itself cannot identify whether a node is a validator.

This seriously hinders the expansion of DAS and Ethereum. Is there any way to resist this threat and ensure the trustworthiness of the network?

Proof of Validator: A ZK solution to guard the security of expansion

Now, let’s get back to the main point of this article: Proof of Validator.

In the Ethereum Tech Forum, todayGeorge Kadianakis , Mary Maller, Andrija Novakovic , Suphanat Chunhapanya 4 people jointly proposed this proposal.

Its general idea is that if we can figure out a way to allow only honest verifiers to join the DHT in the DHT expansion plan in the previous section, then the malicious person who wants to launch a Sybil attack must also pledge a large amount of ETH. Significantly increase the cost of doing evil economically.

In other words, this idea is more familiar to us: I want to know that you are a good person and can identify bad people without knowing your identity.

In this proof scenario with limited information, zero-knowledge proof can obviously come in handy.

Therefore, Proof of Validator (hereinafter referred to as PoV) can be used to establish a highly credible DHT network composed only of honest verification nodes, effectively resisting witch attacks.

The basic idea is to let each verification node register a public key on the blockchain, and then use zero-knowledge proof technology to prove that it knows the private key corresponding to the public key. This is equivalent to showing your identity to prove that you are a verification node.

In addition, to resist DoS (Denial of Service) attacks on validating nodes, PoV also aims to hide the identity of the validator on the network layer. That is, the protocol does not expect an attacker to be able to tell which DHT node corresponds to which validator node.

So how to do it? The original post uses a lot of mathematical formulas and derivation, so I won’t go into details here. We give a simplified version:

For specific implementation, Merkle tree or Lookup table is used. For example, use the Merkle tree to prove that the registered public key exists in the Merkle tree of the public key list, and then prove that the network communication public key derived from this public key matches. The entire process is implemented using zero-knowledge proof, and the actual identity will not be revealed.

Skipping these technical details, the final effect of PoV is:

Only nodes that have passed authentication can join the DHT network, which greatly increases its security and can effectively resist Sybil attacks and prevent samples from being deliberately hidden or modified. PoV provides a reliable basic network for DAS, which indirectly helps Ethereum achieve rapid expansion.

However, the current PoV is still in the theoretical research stage, and there is still uncertainty whether it can be implemented.

However, several researchers in this post have conducted experiments on a small scale, and the results show that the efficiency of PoV in proposing ZK proofs and the efficiency of validators receiving proofs are not bad. It is worth mentioning that their experimental equipment was just a laptop, which contained only an Intel i7 processor from 5 years ago.

Finally, the current PoV is still in the theoretical research stage, and there is still uncertainty whether it can be implemented. But regardless, it represents an important step toward higher scalability for blockchain. As a key component in the Ethereum expansion roadmap, it deserves continued attention from the entire industry.

PoV original post address:Link