ETH2 validators: How to determine the validity of "proof"

Source | Attestant

By Jim McDonald

Translator's note: How can Eth2.0 validators get higher rewards? It turns out that the earlier the proof is included in the blockchain, the higher the reward the validator gets. This article helps validators determine the validity of "single proof" and "aggregate proof" based on the key metric "inclusion distance".

prove

A proof is a vote initiated by a validator on the current state of the Eth2.0 blockchain. Each active validator initiates a proof every epoch (about 6.5 minutes), which consists of the following elements:

Figure 1: Components of a proof

One of the interesting processes is the chain head voting, which refers to the validator voting to prove the latest valid block, i.e. the chain head. The composition of the chain head voting is shown in the figure below:

Figure 2: Composition of chain head voting

Here, slot refers to the location of the current chain head where the validator votes, and the hash value identifies the location of the validator. The combination of these two uniquely identifies a point on the blockchain, and after obtaining enough votes, the network reaches a consensus on the state of the chain.

Although the data in each proof is relatively small, it can quickly become large as thousands of validators participate. Since this data will be stored forever on-chain, it is important to reduce the size of the stored data, which can be achieved through a process called aggregation.

Aggregation consists of multiple proofs, all voted on by the same committee, including the chain head vote and the finality vote, which are then merged into one aggregate proof:

Figure 3: Composition of aggregate proof

Aggregate proofs differ from simple proofs in two ways. First, there are multiple verifiers in an aggregate proof. Second, its signature is an aggregate signature, consisting of the signatures of the matching simple proofs. Aggregate proofs are very storage-friendly, but come with additional communication and computational burdens (more on this below).

If every validator is required to aggregate all proofs, this means that information about every proof must be passed to every validator, and the amount of communication will quickly overload the network. Similarly, if aggregation is optional, then validators will be reluctant to waste their resources. However, if we change the approach and let the network select a subset of validators to perform aggregation tasks, then they will be more willing to do their job, because the aggregated proof contains more validators and is more likely to be included in the chain, which means that the validator will be more likely to receive a reward.

Validators who perform this aggregation process are called aggregators.

Increased certification rewards

Eth2.0 uses the inclusion distance metric to calculate the rewards for validators' proofs. The inclusion distance of a slot refers to the difference between the slot where the proof is made and the slot that first included the proof into the block. For example, if the proof is made in slot ss and included in the block in slot s+1s+1, the inclusion distance is 11. If it is included in the block at s+5s+5, the inclusion distance is 55.

In Eth2.0, the value of a proof depends on its packaging distance, and the shorter the packaging distance, the better. This is because the sooner the information is presented on the network, the more useful it is.

In order to reflect the relative value of the proof, different rewards are given to the verifier responsible for the proof according to the size of the packaging distance. Specifically, the reward is multiplied by 1/d, where d is the packaging distance.

Figure 4: Relationship between proof reward and packaging distance

If the network is running well, the packing distance of all proofs will be 1. This means that the proof achieves maximum validity and accordingly receives the maximum reward. If the proof is delayed, the reward received by the validator will be reduced accordingly.

Packaging certification process

So how is the proof packaged into the Eth2.0 blockchain? The process is as follows:

1. Each proof verifier generates a proof based on data related to the chain state;

2. The proof is broadcast to the corresponding aggregators in the Eth2.0 network;

3. The aggregator that receives the proof combines it with other proofs voted on by the same committee;

4. The aggregate proof is broadcast to all nodes in the 0 network; and

5. If the aggregate proof has not yet been added to the chain, any validator proposing a block can include it in the block.

When the packing distance of the proof exceeds 1, we need to find out the reason. There are several influencing factors:

Attestation Generation Delay

Validators may experience delays in attestation generation. For example, information about the chain state may become outdated, or validators may be underpowered and take too long to generate and sign attestations. Regardless of the reason, delayed attestations have indirect effects on the rest of the process.

Attestation Propagation Delay

Once a validator generates a proof, it needs to be broadcast to the aggregators of the network. This process is designed to allow aggregators to receive the earliest proof information in a timely manner so that the proof can be aggregated before the proof information is broadcast to the entire network. Validators should try to connect to as many other validators as possible to ensure that the proof is broadcast quickly to the aggregators.

Aggregate Generation Delay

The attestation aggregation process may be delayed. The most common reason for this is that the nodes are overloaded with the attestations being generated. However, when there are a large number of validators that need to aggregate attestations, the speed of the aggregation algorithm can also cause noticeable delays in the aggregation process.

Aggregate Propagation Delay

Similar to proof broadcast delays, aggregate proofs also need to be broadcast to the network and may suffer from the same delays.

Block Production Failure

In order for a proof to become part of the on-chain data, it must be packaged into a block. However, block generation may fail. When a validator is offline or fails to successfully synchronize the data of the rest of the network, the generated invalid data will be rejected by the chain.

Failure to generate a block will cause another impact. Since the previous valid proofs were not packaged into the block, the next generated block needs to receive more proof data. If the proofs that can be packaged into the next block exceed the range that it can accommodate, then the validator will most likely choose those proofs with the shortest packaging distance because they can get more rewards. This makes the packaging rewards of the remaining proofs less and less, causing the proofs to miss the best block and subsequent blocks.

Since block generation is affected by the status of the validator, we define the earliest packaging slot, which is the first slot after the slot where the valid block is generated and proved. This definition takes into account that the proof cannot be packaged into a non-existent block and avoids being affected by the validity of the validator.

Evil behavior

Still, it is possible for a malicious validator to refuse to aggregate any given proof, or to refuse to include a proof in its block. The former is solved by assigning multiple aggregators to each proof group, while the latter is solved by penalizing the refusal to include an aggregated proof in a block. However, if the penalty for refusing to include a proof is financially compensated, or if the behavior is politically more valuable, then the validator in charge of the proof cannot do anything to force the validator in charge of producing the block to include the proof in the block.

Validity of computational proof

Taking into account the block production and packaging distance, the validity of a proof refers to the usefulness of a proof to the network. It is calculated as:

The calculation is expressed as a percentage. Here are some examples of effectiveness calculations:

If a proof fails to be packed because its packing distance is the maximum value of 32, then the validity of the proof is 0.

Aggregate Proof of Validity

Calculating proof validity for a single proof may be interesting, but the value itself is not very meaningful. Aggregate proof validity (covering a longer period of time and more validators) can give us a better understanding of the overall effectiveness of a group of validators. Aggregate proof validity is the average of the individual proof validity. For example, take the average of the validity of all validators in a given group over 7 days.

Summarize

After Eth2.0 launches, thousands of nodes will locate each other and start proposing and attesting blocks. As with all immature networks, there are many issues to be resolved in order for nodes to be as efficient as possible. As described in this article, a clear metric for recording node efficiency is proof effectiveness. If validators want to maximize their rewards, they can use proof effectiveness to judge their overall performance.

For more Ethereum news, please follow:

Official account: ETH Chinese website

Website: ethereum.cn

Statement: ECN's translation work aims to deliver high-quality information and learning resources to the Chinese Ethereum community. The copyright of the article belongs to the original author. Reprinting must indicate the original source and ethereum.cn. If you need to reprint for a long time, please contact [email protected] for authorization.