Skip to content
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

Open
cedricfung opened this issue Aug 22, 2021 · 6 comments
Open

Slashing rules #90

cedricfung opened this issue Aug 22, 2021 · 6 comments
Assignees

Comments

@cedricfung
Copy link
Contributor

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.

@cedricfung
Copy link
Contributor Author

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.

@cedricfung cedricfung added this to the Stubborn Mayflies milestone Sep 23, 2021
@cedricfung
Copy link
Contributor Author

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.

@cedricfung
Copy link
Contributor Author

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.

@cedricfung
Copy link
Contributor Author

cedricfung commented Sep 21, 2022

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.

  1. The first node in the round gap window is responsible to send out node removal transaction.
  2. The node should never send the removal transaction for itself.
  3. If there is a node to be slashed, then remove it, otherwise remove the first accepted node.
  4. If Tn>T/3, no slash, no removal, even normal removal should not happen.
  5. At most one node can be removed per day.
  6. If there is a node pledging, should wait for the node to be accepted, so no removal that day.
  7. The node pledging should be accepted within two days, otherwise, this pledging node should be marked for removal.
  8. If there is already node marked for slashing, then no new pledging should be allowed.
  9. If a node is marked for slashing, then all other nodes will ignore all its messages silently.

@cedricfung
Copy link
Contributor Author

cedricfung commented Sep 21, 2022

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.

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

@cedricfung
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants