StaFi rETH’s solution to the Slash of ETH
Summary
ETH 2.0 has a harsh rule when it comes to Slash — a validator may face up to a Slash of 16 ETH from his balance. In extreme cases, the entire Staking principal of the validator may be confiscated. This situation poses a great challenge for the design of rETH from the validator’s perspective. If the validator does not pay the deposit, he/she may feel free to act in a dishonest manner, but if the deposit is too high, it will damage the willingness of participation in the rETH ecosystem.
In this article, the following issues will be discussed:
1) The Slash rules for ETH 2.0
2) The probability of Slash in ETH 2.0
3) The amount of Slash fines in most cases
4) How rETH deals with the ETH2.0 Slash problem
The Slash rules for ETH 2.0
As we know, there are two types of punishments in the ETH2.0 Staking mechanism. One is Penalty and the other is Slash:
1) Penalty happens when a node fails to validate a block due to disconnection. The fine is relatively small and will not be deducted from the user’s principal.
2) Slash happens when a node performs any of the three malicious behaviors — Double target vote, Double Proposal, and Surround Voting. The punishment is relatively heavy. When the validator is Slashed, assets will be withdrawn directly, and the minimum fine is 1 ETH (lowered when the beacon chain is live). In extreme cases, the 32 ETH principal deposited by a validator may be halved.
The design of ETH2.0’s Slash mechanism is to increase the security of the chain. StaFi must also take into consideration Slash when designing rETH product solutions. A reasonable mechanism that ensures the user’s principal is immune is of paramount importance. This is because the user’s funds are deposited into the fund pool through the StaFi contract, and then sent to the validator Pool contract by contract algorithm. During the whole process, the user delegates StaFi to select validators, which is different from the traditional Staker delegation mode.
Validator’s Deposit
In the rETH solution, every time an Original Validator of ETH2.0 starts running a node, a certain amount of deposit is required. This deposit will be staked in the ETH1.0 deposit contract along with the stakers’ funds. When the validator is Slashed, the deposit will be deducted, so as to ensure that the user’s funds will not be deducted for the misbehavior of the validator.
In the ETH2.0 world, the maximum amount of Slash from the principal is 16 ETH if there are no more than ⅓ validators getting slashed at the same time . Therefore, the theoretical validator deposit without further thinking required by the StaFi rETH solution will be 16 ETH under normal situations.
However, this will hugely discourage many small and medium-sized nodes from validating, and their participation is essential to the decentralization of rETH solution. Therefore, we need to further think about whether there is a way that can facilitate the entrance of validators while simultaneously guaranteeing security.
We must think of the following two issues first before we answer that question:
1) Probability of Slash
2) The maximum amount of Slash fine
If the probability of Slash occurrence is extremely low, and the fine is also low (say, in the range of 3 to 5 ETH), then can be reassured to lower the validator’s deposit.
Will discuss these two issues separately.
Probability of Slash
Since most validators are honest and without any intention to act maliciously, the probability of Double target vote, Double Proposal, and Surround Voting is extremely low theoretically.
Let us look at the real world of ETH2.0 nodes. ETH 2.0 has been accessible since December 1, 2020. As of 21:40 UTC+8 on December 9, the total number of validators has reached 38,933, and the number of validators in operation has reached 27,837.
According to the data from Etherscan, there are 14 validators that were Slashed, accounting for 0.04% of the total number of validators and 0.05% of the total number of active validators.
As shown in this table:
In conclusion, about 4 to 5 validators out of 10,000 validators will be Slashed. 10,000 validators deposit 320,000 ETH, and so the maximum amount of Slash fine is 64 to 80 ETH if we assume the maximum slash loss per validator balance is 16 ETH.
We must, of course, consider the time period of ETH2.0 operation. Since ETH2.0 has been running for only 9 days now, the probability of Slash has not been stable yet. So let’s take Tezos as another example, which has been running for more than 2 years. So far, the number of validators (or Bakers) is 478, and a total of 21 out of them have been Slashed during the 2 years+ running period. This accounts for 4.4% of the total number of validators.
Put aside the difference in consensus algorithm design between Tezos and ETH 2.0, the cumulative probability of Slash of Tezos is 4.4% for more than 2 years in total. This implies that 2.2% of the nodes will be Slashed every year, if we just do the simple math. But we know that the number of ETH2.0 validators is much higher than that of Tezos and ETH2.0 Slash rules are harsher. So, the probability of ETH 2.0 Slash should be lower than Tezos.
Therefore, it is unreasonable to require OVs to pay a deposit of 16 ETH for each node they run. The validators must pay 100% of the “theoretical” maximum economic cost for an event that actually occurred with a probability of 0.04% to 2.2%. Knowing this, the Slash’s design can protect the Stakers’ principal and the token flow pressure of validators.
However, we must not exempt the validator’s deposit for the low probability of Slash. The main reasons are as follows:
1) The number of validators that have been slashed is small because they have paid all the principal. Once the principal is not paid by them, the probability may increase.
2) Once a Slash occurs, the validator will be forced to withdraw, with a 36-day punishment period and withdrawal period. During this period, the validator’s balance will be deducted every day, and so the users’ principal may also be damaged.
The maximum amount of Slash fine
Now let’s look at the actual amount of Slash fines. From the same data source of the above, we realize that the balance of the slashed nodes is less than 32 ETH. Moreover, the №20075 node suffered the biggest fine of 0.31806 ETH from its principal among all the 14 slashed nodes. We can see that the fine is not as serious as we imagine, well below 16ETH.
Note:
1) The benchmark of Slash time is: December 9, 2020 21:40 PM UTC+8
2) The above data comes from Etherscan
We must admit that these Slashed validators have a 36-day Slashing period, during which they will be fined until they are withdrawn later. According to the Slash rule of ETH2.0, we can roughly calculate the amount of the Slashing penalties of the validator when the period ends.
The validator’s Slash amount is mainly composed of the three parts in the following figure, which are the penalty at the slashing processing, the penalty during each epoch, and the special penalty when they are withdrawn.
Source: ConsenSys Codefi Analysis
The penalty in the first part is happening at the slashing processing and is defined by the slashed validator effective balance, which is 32ETH in most cases of the node. So the initial penalty is usually 1ETH according to the ETH2.0 slashing mechanism paper.
In the second part, during 8192 Epochs, there will be a Slash in each Epoch (6.4 minutes), and the penalty is 3 times the base reward in each epoch. The base reward calculation formula is:
- BASE_REWARD_FACTOR is a constant of 64;
- BASE_REWARDS_PER_EPOCH is a constant of 4;
So, the biggest determinant of Base Rewards is the value of Active Balance in the network, and the value of Active Balance increases with the number of running nodes. The current number of Active Balance nodes is 27,837. Assuming that the effective balance of each node is 32ETH, the Base Reward will be 12,211.73 GWEI according to the data from Consensys.
Let’s assume that the number of Active nodes in the future will not increase (obviously impossible), and the total penalty for 36 days (8192Epoch) is approximately 8192*12211.73*3/10⁹=0.30ETH.
We know that the number of validators for ETH2.0 is very likely to increase, so the number of Base Reward will gradually decrease. Therefore, the above calculation is relatively overestimated.
The third part of the penalty, Special Penalty, can be calculated by the following formula:
The Special Penalty is determined by the total number of nodes slashed in the same period, and the total balance of the current network. It should be noted that:
1) If more than one-third of the nodes do act maliciously at the same time, then according to the calculation formula, the Special Penalty will be equal to the effective balance of the node, which means the entire principal of the node will be directly fined.
2) If the Slash rate is 0.04% to 0.05% as we calculated above, the Special Penalty is 0.12% to 0.15% of the effective balance of the node, which is 0.0384 to 0.048ETH.
In a nutshell:
1) The first part of the penalty is mostly 1 ETH which is lowered down in the actual running of ETH2.0.
2) The second part is approximately 0.3 ETH, if the number of Active nodes remains 27,837 (impossible as the number will grow bigger in the future).
3) The third part is about 0.0384~0.048ETH if the Slash rate is 0.04% to 0.05%.
Therefore, the slashing penalty for a node is between 1.3384 and 1.348 ETH currently.
Conclusion
Through our study, we found that it is unreasonable to require each node to pay a deposit of 16 ETH when the slash happening odds is around 0.04% and the loss is usually under 1.4 ETH . As for the proper deposit amount, we can calculate a following range:
1) Must be higher than 1.5ETH
2) Must be lower than 16ETH
Although in theory, it is reasonable for us to require each node to pay a 2ETH deposit, there are still the following uncertain factors which will cause a higher risk:
1) When a validator knows that only 2 ETH of 32 is paid by oneself, will it still try the best to avoid being Slashed?
2) When a validator wants to attack the ETH2.0 network, it can use this vulnerability to lower the overall hacking cost. At that time, the financial cost will be hugely reduced from 32ETH to 2ETH — a dramatic decrease of 93.75%.
The deposit needs a more reasonable interval, which can solve the above two potential problems. This is why StaFi sets the deposit range between 4ETH and 16ETH. As for whether it is possible for it to fall to between 4ETH and 8ETH, we think it is; but we also need to design a Slash insurance pool when the validator deposit is lowered down.
When the deposit is lowered, it will not be able to fully compensate for theoretical maximum loss of Slash. After all, when Slash appears, there is still a probability, even though it is extremely low, that the funds in a single node account will be fined up to 16 ETH. For example, when the number of malicious nodes is considerable but does not exceed 1/3 of all, but that probability may be less than 0.01%.
We think that this risk can be resolved by an insurance pool for Slash. If a validator joins in the insurance pool, once Slash occurs, the loss shall be borne by the deposit paid by the validator if it is lower than 8ETH, and if not, the insurance pool shall bear it.
The insurance pool is an important module in the product design of the rETH product. Its mission is to help validators resist Slash risks, thereby facilitating the adoption of rETH. We will disclose the details of the insurance pool for Slash in future articles.
About StaFi Protocol
StaFi is the first DeFi protocol unlocking liquidity of staked assets. Users can stake PoS tokens through StaFi and receive rTokens in return, which are available for trading, while still earning staking rewards. FIS is the native token on StaFi Chain. FIS is required to provide security to the network by staking, pay for transaction fees on the StaFi chain, and mint & redeem rTokens.
Website: www.stafi.io
Twitter:@Stafi_Protocol
Telegram Chat: https://t.me/stafi_protocol
Telegram Announcements: https://t.me/stafi_ann
Discord: https://discord.com/invite/jB77etn
Forum：https://commonwealth.im/stafi
