Slash means a sharp reduction, and is a commonly used punishment mechanism for malicious validators in PoS consensus public chains. The slash rule of Ethereum 2.0 may be the most complicated of all PoS public chains. By studying the Ethereum 2.0 design specifications and source code, the slash rules are interpreted as follows.
Types of slash
Slash generally refers to punishment for serious malicious behavior, rather than punishment for ordinary offline nodes. The latter is generally called inactivity penalties. In general PoS public chains, generally only “double sign” behaviors will trigger slash, while in Ethereum 2.0, the following behaviors are specific:
Propose two conflicting blocks in the same slot;
Vote for two conflicting blocks in the same slot;
Voting conflicts with historical voting.
Behavior a, b will cause unnecessary forks on the blockchain, and behavior c is an attempt to tamper with history.
Validator status after slash
After slashing, the verifier will be forced to enter the verifier exit queue and then exit.
The validator will be deducted the effective balance/128 as a fine immediately. If the effective balance is 32ETH, it is 0.25ETH. (It should be noted that the original penalty amount is the effective balance/32, which is 1ETH, but it is temporarily reduced to a quarter of the original value during the beacon chain stage)
After 8192 epochs (about 36 days), the validator account is allowed to withdraw (after Ethereum 2.0 supports transaction functions).
Before allowing withdrawal, the slashed node will receive a penalty of 3 times the online reward at the beginning of each epoch.
The slashed verifier is not allowed to return to the verifier queue again, and can only rebuild a new verifier and re-stake.
Multi-node slash at the same time
In addition to the effective balance/128 penalty and the offline penalty for each epoch, there will be another additional penalty in the middle half of the epoch that is slashed and the epoch that allows withdrawal, that is, 4096 epochs after being slashed.
The penalty ratio is proportional to the ratio of the total balance of all slashed validators to the total balance of active validators on the entire network during this period.
The original proportional coefficient is 3, and the current beacon chain stage is temporarily reduced to one third of the original value, that is, the coefficient is 1. In other words, the extra penalty for multi-node slash will be 3 times the current one.
Therefore, a validator node will be punished three times after slashing:
The effective balance/128 will be deducted immediately (it will be adjusted to the effective balance/32 later)
Punishment at the beginning of each epoch (current data is about 0.009 ETH per day)
Additional penalty for simultaneous slash of multiple nodes
Report reward
The slash mechanism not only punishes the node that triggers slash, but also rewards the “reporter” who reports slash. Normally, the reward is divided into two parts, one is to reward the “reporter” who submits slash, the amount is larger (currently about 0.1 ETH), the other is to reward the block producer who packs the slash block, the amount is smaller (currently about 0.025 ETH). At present, in most cases, the two parts of the reward are directly transferred to the blocker.
The reason for triggering slash
Unless intentionally, most faulty slash occurs because the same validator key is run on two servers, that is, the two servers run the same node. “One use, one backup” is a common practice for traditional server redundancy to prevent downtime. Unfortunately, the problem of PoS public chain node operation with slash mechanism cannot be handled so simply.
Security is not equal to reliability in the blockchain field. In the traditional Internet, security and reliability are not contradictory, and security and reliability can be improved by increasing system redundancy. However, in the blockchain, if the block producing node is designed for redundancy, it is very likely that multiple nodes will produce blocks at the same time, resulting in double signatures; but if the node is not designed for redundancy, a single point of failure will occur . If this node goes offline, it will cause the entire system service to go down and affect the reliability of the system.
In addition, the client generally has a slash protection history record by default, which prevents slash by recording all historical attestation and proposal records. If the record is accidentally deleted during operation, it may also cause slash problems.
Staking and establishing a validator node is just the first and easiest step.
