Thanks to Joseph Schweitzer and Danny Ryan for their reviews.
Welcome back! We discussed the design philosophy of eth2. finally, today’s focus is on eth2’s incentives through the lens of that philosophy. More specifically, we look at the incentives that affect eth2 and how they are realized in the form of rewards, penalties, and slashing.
We will then look at how and why validators are incentivized to stay online. habit Slashed for reasons such as going offline. Let’s dig in.
When does slashing occur if not offline? ⚔️
Slashing has two purposes: The goal is to (1) make it prohibitively expensive to attack eth2, and (2) avoid laziness by ensuring that the verifier is actually doing its job. Removing a validator means destroying (part of) the stake if the validator does the following: maybe Destructive way. The two main ways validators can behave maliciously within eth2 phase 0 are double voting and surround voting (read original paper For more information about how Casper FFG works, see:
double voting This is when a validator votes on two different blocks during the same epoch. This signals support for two different versions of reality. The simplest example where this is prohibited is when a validator sends a transaction. within the block and within the block where and It uses the same ETH. This is a proof-of-stake version of classic. double spend attack.
slashing surround voting It also prevents two versions of the chain from being confirmed by punishing validators who generate votes that present multiple different versions of reality that they claim to be true at the same time. More specifically, a proof (voting on a block) is a surround vote in such a way that a validator proves one version of reality and later proves another version, but does not clearly indicate that it no longer believes the first version.
Double and surround voting are the only ways a validator can be cut in stage 0, but additional rules are added in later stages to ensure that validators can actually store and use the signed shard data. This prevents validators from being lazy or withholding information. ).
A validator that properly follows the protocol will never issue a truncable vote in its normal operation.. Unless it is an intentional malicious act, forming a slashable message only happens as a result of some bug or accident. To minimize the pain caused by these errors, the amount of stake destroyed is proportional to the number of other validators slashed at the same time. If a small number of validators commit some attacks, it is highly unlikely that they will attempt to attack eth2 since a successful attack requires many validators. Therefore, slashing that occurs in small numbers is considered an honest mistake and is punished lightly (minimum 1ETH). On the other hand, if many validators commit a crime over a similar period of time, it will be considered an attack on the network and a large amount of stakes will be burned (up to the entire balance).
Slashed validators can no longer participate in the protocol and are forced to quit. In case of an honest mistake, this prevents the offending validator from being cut again and causing further harm to himself. On the other hand, in the malicious case, the malicious validator is removed from the protocol.
So what happens to validators that are offline? 🚫👩💻
Validators who are offline when they should be participating in the protocol are penalized, but in general these validators are You simply lose what you could have gained in rewards if you had correctly participated in the protocol.. This means that validators who are online more than 50% of the time will still see their stake increase over time.
As a result of this mechanism, Validator clients that need to go offline for maintenance, etc. are usually best served by going offline for a short period of time rather than exiting and rejoining the protocol (both have associated delays)..
This means that validators do not need to go to extremes with backup clients or redundant Internet connections, as the impact of being offline is not that severe. In practice, a system where two entities can sign a message can be detrimental because the primary and backup clients can come online at the same time and issue truncable votes (via the double voting mechanism described earlier). First Cosmos Slashing.
This offline penalty system remains in place as long as the block is confirmed (2/3 of the validators (weighted by stake) are online and votes are being counted). This is the expected eth2 state during normal operation. If less than 2/3 of the nodes are online, something serious has gone wrong in the eth2 zone. The consensus protocol family to which Eth’s Casper belongs can no longer reach consensus under these conditions.
> What does eth2 do if 1/3 of the validators are offline? 💣
This is where the inert leaks mentioned at the beginning of the article come from. inert leak Over time, we will reduce the balances of offline nodes so that the ratio of online validators to all validators (weighted by stake) can once again exceed 2/3, allowing eth2 to continue making decisions as a protocol. Let’s do it.
Inactivity leaks are one of the ways eth2 was designed to survive a WW3 style event. If such an event causes more than a third of all validators to drop out, offline validators will find that their balances have been reduced to the point that their participation is no longer required for eth2 to continue as a chain.
Anti-correlation and diversification
Slashing mechanisms and inactivity leaks incentivize validators to make decisions that cause their nodes to fail in different ways than other nodes.. This means that to ensure the smallest possible slashing and prevent inactivity leaks, the verifier must try to make a client fail in a different way than other clients.
For example, validators that rely on the same source like Infura or use AWS to host their clients may be in a worse situation if something goes wrong, so this puts pressure on all validators to decentralize all aspects of their existence. It will.
Why would anyone want to become a validator when there are so many ways to get punished? 📈
As mentioned in the first article, “Validators are lazy, take bribes, and will try to attack the system unless they are otherwise incentivized.” The punishments discussed so far discourage bad behavior, but rewards are needed to encourage validators to perform actions that benefit eth2.
There are three major levels of rewards.
Whistleblower Rewards 🚓
Validators who raise the alarm among other validators by providing evidence that causes other validators to be deducted are rewarded for their efforts in cleaning up the eth2 streets.
Proposer Reward ⬜️⛓⬛️⛓⬜️
Validators are randomly assigned block generation duties. Selected validator proponent. Proposers are rewarded for their efforts in the following way:
- Includes evidence from a whistleblower who sacked a verifier
- Includes new proofs from other validators
These rewards incentivize validators to provide useful information to the chain when they are selected to produce blocks.
Prover Reward ✔
A proof is a vote indicating that the validator agrees with eth2’s decision. These types of messages form the basis of consensus and are rewarded in five ways:
- Get on-chain proof
- Agree with other validators on the history of the chain
- Agree with others about the head of the chain
- Get proof on chain quickly
- Points to the correct block in the assigned shard
Validator Revenue Expansion 💸
There are two common approaches to paying validators in PoS systems: fixed rewards and fixed inflation. In a fixed reward model, validators are paid a fixed amount for performing a task, with the inflation rate varying depending on the number of registered validators. This raises the question of how to set the reward rate correctly. If the reward rate is set too low, the number of validators participating will be too few, while if the reward rate is too high, it will encourage widespread validation beyond the required security and waste money.
The free model is one with a fixed inflation rate where a portion of the total rewards is divided among active validators. This model has the advantage that since validators individually decide whether to participate based on their current revenue, market forces can find the right amount to pay the validator. This model has its drawbacks. Validator revenue can be erratic, making it difficult to determine the profitability of individual validators. This model also makes the protocol vulnerable to: discouragement attack Validators attempt to prevent each other from participating in order to increase their own profits (even if this means temporary losses).
eth2 aims to have the best of both worlds by choosing a reward model where validator rewards are proportional to the square root of the total amount of ETH staked. This hybrid model suppresses inflation and fluctuations in validator yields while allowing the market to determine the exact amount to pay each validator for the security provided.
Hope for the best but expect the worst 🛡️
Each aspect of the eth2 incentive plan is a result of designing the protocol following the philosophy outlined in our last article. Examples of this include anti-correlation mechanisms that encourage decentralization and inert outflows that help eth2 survive World War III, but the main idea behind how incentives work is that “validators are lazy, take bribes, and “Don’t attack the system unless you are incentivized to do otherwise.” If someone attacks eth2 in one of the ways discussed here, you better be prepared to throw away a lot of ETH. Because you will lose all your ETH one way or another.