Background
In a public chain, ownership of assets is sacred. They must not be manipulated by anyone other than the owner’s authority.
For this reason, the slash mechanism should be designed with extreme caution. Actually, in many chains that contain a slash mechanism slashed only by mechanically determinable logic (e.g. Polkadot/Ethereum2.0 PoS). (Strictly speaking, Polkadot will slash by the council. But that should be passed a rigorous logic check before it seen by the council.)
A system must not be that the user’s assets are slashed by obscure behaviors such as “governance”. This is because of a below reason.
Suppose, there is a proposal made to slash A’s assets. The proposal is decided by a majority vote of users. From a micro point of view, users want to slash A’s assets because it will reduce the supply and increase the scarcity value of their tokens. However, from a macroscopic point of view, tokens held in a chain where there is an incentive to slash a third party’s assets from a micro point of view will lose value. (A token whose balance is somehow reduced to zero by a majority vote of strangers is dangerous, isn’t it?) Therefore, the process of slashing or freezing must be a logical choice, not a vague one like “governance”.
However, the Good/Bad Voting for dApps rewards described in the current WP allows users to slash their assets by voting. This causes the same problem as described above. This means that users have an incentive to follow this rule and slash their staking assets in dApps rewards by voting Bad. If this were to happen on a regular basis, the reward system would fail.
This improvement solves the above problems.
Solution
Currently, the Good/Bad voting rule is as follows:
- If the number of Goods is 4 times more than the number of Bads and the contract has already been running over a certain period of time, the contract and its nominator can normally get rewards. (i.e Good ≥ Bad * 4)
- If the number of Goods is 4 times less than the number of Bads or the contract has not been running over a certain period of time, the contract and nominator can not get rewards. (i.e Good < Bad*4)
- If a contract receives voting that the number of Good is less than 2 times as the number of Bad, the tokens of staking to it are locked. (i.e Good < Bad * 2)
- If a contract receives voting that the number of Good is less than as the number of Bad, the tokens of staking to it are slashed. (i.e Good < Bad)
This rule has a problem that asset-damaging operations such as Slashed and Locked occur under a vague called “voting”. As mentioned in the Background, this mechanism expects belief that human nature is fundamentally good, which is not a good idea in the crypto world.
Thereby instead of Slash and Lock in these rules, we’ll consider weighting the rewards as follows:
- If the number of Goods is 4 times more than the number of Bads and the operator has already been running over a certain period of time, the contract can get rewards with weight times 4 . (i.e Good ≥ Bad * 4)
- If the number of Goods is 4 times less than the number of Bads or the operator has not been running over a certain period of time, the contracts can not get rewards with weight times 2. (i.e Good < Bad*4)
- If a contract receives voting that the number of Good is less than 2 times as the number of Bad, the contracts can get rewards with weight times 1. (i.e Good < Bad * 2)
- If a contract receives voting that the number of Good is less than the number of Bad, the contracts can get rewards with weight times 0. (this means the contracts can not get rewards.) (i.e Good < Bad)
This weighted value will be used in the calculation when distributing the rewards of each contract. The total amount of rewards distributed does not change. (In other words, users cannot directly manipulate the supply by voting.)
A simple way to hack dApps rewards is by self staking a contract that is defined to send “you” the PLM. This simply doubles the staking profit, but if the voting result is the condition “Good < Bad”, the effect is the same as simple staking, so there is no reason to this hacks.
Conclusion
This improvement removes the Slash mechanism that makes dApps rewards economically vulnerable. It also removes the incentive for malicious users to hack the system in any way.