Ethereum 2.0 reward and punishment mechanism analysis, one article teaches you how to make good nodes

Written in front: This article comes from the Ethereum blog, introducing the eth2 incentive mechanism and the punishment mechanism for verifiers.

The focus of this article is to understand its incentive mechanism through the design concept of eth2. More specifically, we examined the incentive mechanisms that affect eth2 and how they are implemented in the form of rewards, penalties, and slashing.

We will also introduce how to encourage validators to be online and why, why not be slashed because of being offline, etc. Next we will start to delve deeper.

• How does Ethereum 2.0 achieve "swipe-level" speed?
• The era of personal crypto bonds: NBA players, Ethereum, and personal bonds
• Latest report: Lightning Network's privacy and scalability advantages are lower than expected

If not offline, under what circumstances will slashing occur?

Slashing serves two purposes: (1) making the cost of attacking eth2 scary; and (2) preventing them from becoming lazy by checking if the verifier has actually performed their task. Slashing a validator refers to the destruction of its (partial) pledged funds, provided that the validator's destructive behavior is demonstrated and the behavior can be proved. In eth2 stage 0, the two main ways that validators can be slashed are double voting and surrounding voting:

Duplicate voting means that validators vote for two different blocks at the same time, which means they express support for two different versions of the fact. Why is it prohibited? The simplest example is that the verifier sends the transaction $ a $ in the block $ A $ and the transaction $ b $ in the block $ B $. Two transactions cost the same ETH. This is a typical double-spend attack on the PoS version.

Slashing around the poll also prevented two versions of a chain from appearing, which punished verifiers who voted on the facts of different versions and claimed that both versions were true at the same time. More specifically, when a verifier verifies one version of the fact and then verifies another, but shows in an ambiguous way that they no longer believe the first version, Block voting) is around voting.

Repeated and orbital voting is the only possibility for the verifier to be slashed in stage 0, but additional rules will be added in subsequent stages to ensure that verifiers do store and provide their signed shard data (this prevents the verifiers Lazy or hidden information).

In normal operation, validators who follow the protocol correctly will not issue slashing votes. If it is not intentional malicious behavior, the slashing message may only be caused by an error or accident. In order to minimize the impact of these errors, the stakes that are destroyed are proportional to the number of other validators that are slashing at the same time. If a few validators make some low-level mistakes, they are unlikely to try to attack eth2, because a successful attack requires a large number of validators. As a result, slashing that occurs with a small number of validators is considered an honest mistake and the punishment is light (minimum 1 ETH). On the other hand, if many validators make a mistake in a similar period of time, the amount of stake they are destroyed will be large (which can be the entire balance) because this is considered as an attack on the network.

Slashing validators will be barred from further participation in the agreement and will be forced to withdraw. In the case of honesty and error, this prevents the offending verifier from causing further harm to himself due to being slashed again; in the case of real evil, this allows the protocol to delete the malicious verifier.

What to do if the validator is offline?

Verifiers who are offline should be punished when they should have participated in the agreement, but under normal circumstances, if they participate correctly in the agreement, these verifiers will only lose the rewards they should have received. This means that more than 50% of validators are online and their stakes will still increase over time.

As a result of this mechanism, validator clients that need offline maintenance are usually better off offline for a short period of time, rather than exiting and rejoining the protocol (both have associated delays).

This means that the validator does not need to spend too much time on backup clients or redundant network connections, because the impact of offline is less severe. In fact, a system that allows both entities to sign messages is harmful because the primary and backup clients may be online at the same time and issue slashing votes (the repeated voting mechanism described above).

This offline penalty mechanism applies to the finalised block (two-thirds of the validators (measured by the number of take) are online and their votes are counted). This is the expected state of eth2 during normal operation. If there are less than two-thirds of the online nodes, a catastrophic error will occur in eth2. In this case, the consensus protocol family in which Eth's Casper participates will not be able to reach consensus.

What would eth2 do if one third of the validators were offline?

This is where the inactivity leak comes from. Inactive vulnerabilities will slowly reduce the balance of offline nodes, so the ratio of online validators to total number of validators (measured by the number of takes) can again exceed 2/3, so eth2 can continue to make decisions as a protocol.

The inactivity vulnerability is one of the ways that eth2 survived events like World War III. If such an event affects more than a third of validators, then offline validators will find that their balance is reduced to no longer require their participation so that eth2 can continue to operate as a chain.

Anti-correlation and decentralization

Both the slashing mechanism and inactive vulnerabilities encourage validators to make decisions that cause their nodes to fail in a different way than other nodes. That said, to ensure as little slashing as possible and prevent inactive vulnerabilities, validators may try to fail their clients in a different way than others.

This puts pressure on all validators, requiring them to decentralize all aspects of validators. For example, validators who rely on the same information source like Infura or validators who use AWS to host their clients. Oops.

With so many punishment mechanisms, why is anyone still a validator?

Validators may be lazy and take bribes, and unless there is other incentive, they will try to attack the system. The penalties discussed so far have prevented bad behavior, but rewards are needed to encourage validators to perform behaviors in favor of eth2.

Here are three main ways to reward:

Whistleblower reward

One validator alerts another validator to provide evidence of being slashed, which is a reward for their efforts to clean up the eth2 system.

Applicant rewards

Validators are randomly assigned to the task of producing blocks; selected validators are called applicants. The applicant's efforts will be rewarded with:

• Includes a slashing proof from the slashing verifier
• Include new evidence from other validators

These rewards encourage validators to provide useful information to the blockchain when choosing a production block.

Certifier reward

Attestations are signals that the verifier agrees with a decision in eth2. These types of information form the basis of consensus and are rewarded in 5 different ways:

• Let your evidence be chained
• Agree with other verifiers' recognition of chain history
• Agree with others' recognition of the beginning of the chain
• Get your evidence online quickly
• Point to the correct block in the allocated shard

Expansion of validators

There are two common ways to pay validators in PoS systems: fixed rewards and fixed inflation. In the fixed reward model, the job rewards of validators are fixed, and the inflation rate depends on how many validators are registered. This raises the question of how to set the reward rate correctly. If the reward rate is set too low, there will be too few validators involved, while an excessively high reward rate will encourage extensive verification beyond the necessary security and will waste money.

This complementary model has a fixed inflation rate and rewards are distributed to active validators. The advantage of this model is that it allows the market to regulate the appropriate amount to be paid to validators, who will decide whether to participate based on the current revenue. This model also has shortcomings. The benefits of validators may be unstable, making it difficult for individual validators to make profit decisions. This model also makes the protocol vulnerable to a discouragement attack, in which validators try to prevent each other's participation to increase their profits (even if they may cause themselves to lose funds in a short period of time).

The goal of eth2 is to choose a reward model in which the reward of the validator is proportional to the square root of the total amount of ETH pledged. This complementary model attempts to suppress changes in inflation and the rate of return of validators, while still allowing the market to pay each validator a proper reward if it is safe.

Hope for the best and plan for the worst

This article mentioned content including anti-correlation mechanisms, encouraging decentralization and inactivity loopholes to help eth2 run smoothly, but the basic premise of the operation of the incentive mechanism is to assume that "validators will be lazy, accept bribes, and attempt to attack the system, unless there is an incentive mechanism to tell They don't do this. " If anyone attacks eth2 with the methods mentioned in this article, they are better prepared to lose a lot of ETH.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!