-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slashing rules #90
Comments
Every node should ensure that it has a round following its previous round within 12 hours, otherwise the node will be slashed for the cost of 100XIN. |
The node should agree on a checkpoint transaction every 10 minutes, similar to the mint rules, at a checkpoint time, a designated node should propose a checkpoint transaction, then all other nodes are required to make a transaction to agree on this checkpoint before next checkpoint is available. Failed to obey those checkpoint rules will reduce the mint reward drastically, whenever a mint is being distributed, the distributor will calculate the rewards as before. Then count how many checkpoints a node agreed on, if it lacks more than 3 of them, the mint reward will decrease 1/3, and 9 checkpoints lack will make the rewards 0. |
To ensure the security of the network, slashing is required, but we need to ensure the network would still work whenever some bugs caused most nodes stop working. It has happened before, that most nodes can't produce a valid snapshot for more than 12 hours. We only slash at most 1 node per day, and the slash should only happen during the normal node remove period. Every node will have a state of all the nodes longest round gap window, the consensus engine will just save the gap window when each new round started. When the node remove window opens, the node will also calculate the window opening time to the last round time of each node, count it as a gap window. Assume we have N nodes, and slashing period is T=8 hours. The engine should choose the max gap window for each node, and get a list of max gap windows, then sort them from smallest to longest, and choose the time Tn at order 2/3N, then check Tn against T/3, if Tn > T/3, then no slashing should be made because it means at least N/3 of all nodes have experienced some kind of faulty. If Tn < T/3, then check if the last node time larger than T, if so, slash it. The first node in the list is responsible to send out the slash transaction and snapshot. |
This can be combined with the normal node removal and light node voted slashing procedure. The light node voted slashing should only be marked in the consensus state, and will happen at the normal node removal time.
|
No special checkpoint transaction required, just use the same snapshot or round gap window technique for the slashing detection. The node just use the already maintained round gap window list, when the mint happens, for each node, calculate the number Gn of gaps larger than 10 minutes. Then make a list of Gn, and use the same threshold check strategy used for Tn and T when slashing, decide whether should the node do checkpoint punishment. If the punishment is feasible, then if Gn>=3, the mint reward will be 0, Gn=2, reward is 2/3, Gn=1, reward is 1/3. The punishment will be shared to all other nodes equally, even the others are also punished. If we decide to share punishment equally to the others, we can make the whole procedure easier, no need to care about the threshold check strategy. Just order all nodes by their punishable round interval total duration, from the largest to the smallest, punish it and share its reward to all the others. And the punishment grade is not measured by gaps count, it's by the total punishable round interval. Say the node has intervals 13m, 11m, and 27m, it's grade is not 3, but (13+11+27)/10 = 5 |
The transaction references feature introduced in v0.15.0 make it pretty easy to finalize the node tail transaction, i.e. the node removal transaction. |
Since the system is carefully designed to prevent serious incidents like double spending, it's still possible for some nodes to behave incorrectly. The most important one is the node may delay broadcast of a finalized snapshot, thus cause other nodes to make incorrect false claims. So we need some rules to slash this bad node.
The text was updated successfully, but these errors were encountered: