REP-38: Demotion and Slashing Mechanism

RSS3 Evolution Proposal
1

In this proposal, GIs will get a new component, the Enforcer, to manage demotion and slashing.

Demotion Mechanism:

  1. Nodes are required to send regular heartbeats to GIs. If no heartbeat is received by GIs within a 5-minute rolling interval, the Node is marked as offline until a new heartbeat is received. The Node’s demotion counter increases by 1.

  2. GI routes requests to a selected number of Nodes (a minimal of 3).

    • If a Node fails to respond normally after a predetermined number of retries (default to 3), the Node’s demotion counter increases by 1.
    • If a Node’s successful response fails to pass cross-validation with other Nodes:
      • If a Node’s response differs from the majority, the Node’s demotion counter increases by 1.
      • If no majority is reached, all responses are deemed invalid, but no one is demoted.

  3. Each demotion reduces the Node’s reliability score, diminishing its chances of receiving requests.

    • The demotion counter and reliability score are reset at the end of each Epoch.

Slashing Mechanism:

  1. If a Node’s demotion counter hits the threshold (currently set to 3), it is slashed.

  2. Slashed Nodes have a reliability score of 0, no requests will be routed to them.

    • The reliability score is reset at the end of each Epoch.

  3. Slashed Nodes will be marked as offline, until the Node Operator manually confirms that the Node is ready to enter online state.

  4. A slash temporarily freezes 1% of the Node’s Operation Pool AND 0.5% of its Staking Pool.

    • Slashed tokens are stored in the Slashing Pool.
    • A slash may be challenged by the Operator within a 3-Epoch challenge window.
      • A successful challenge revokes the corresponding slash and unfreezes the tokens.
      • A successful challenge does not distribute Network Rewards retrospectively.
    • After 3 Epochs, the slash is committed and finalized on-chain.
    • Failing to revoke a slash within the challenge window means that the slash will be committed permanently. The slashed tokens will be:
      • Burn: 50% of the slashed tokens will be burnt.
      • Reward and Reimbursement: 20% of the slashed tokens will be awarded to reporters. When the slash is automatically triggered without a reporter, 20% of the slashed tokens will be reimbursed to all developers who paid request fees during the Epoch in which the slashing occurred.
      • Donation: The remaining tokens will be donated to the Treasury and used for Public Good initiatives and clauses.

Here is a figure showing what happens during an Epoch. The figure might be helpful for illustrating the Enforcer’s logic regarding slashing.

RSS3 Mainnet Diagrams (1)
RSS3 Mainnet Diagrams (1)1920×3147 150 KB

And here is a figure to assist in the understanding of cross-validation. -1 leads to a demotion.

3 responses r1,r2,r3
3 responses r1,r2,r31700×1842 230 KB

This proposal is preliminary based on discussions with some core devs, and will require edits to the Whitepaper. Please share your thoughts below.

Affected pages:

  1. https://docs.rss3.io/guide/concepts/slashing
  2. https://docs.rss3.io/guide/concepts/slashing-pool
  3. https://docs.rss3.io/guide/concepts/demotion
4 Likes
2

Great, I think this is an important mechanism.

3

that’s a lot of changes to the whitepaper :rofl: (in a good way)

my thoughts:

1% of the Node’s Operation Pool AND 0.5% of its Staking Pool

Will this be too much?

I imagine the implementation will take very looooong.

4

Maybe we can reduce penalties for staking pool to protect innocent stakers :thinking:

1% of the Operation Pool AND 0.2% of the Staking Pool

2 Likes
5

Slashed Nodes will be marked as offline, until the Node Operator manually confirms that the Node is ready to enter online state.

nodes are well protected from multiple slashes :thinking:
if the percentage is too low, I think it does not serve as a good deterrent? @joshua @albert

1 Like
6

I think 0.5% of the Staking Pool is good.
The current staking apy is about 30%, so 0.5% of the Staking Pool is equivalent to about 6 days staking rewards.

1 Like
7

@polebug What is the initial value of reliability score at the beginning of each epoch ?

1 Like
8

The initial value of the reliability score at the beginning of each epoch is not a fixed value. It is calculated based on multiple variables such as the type of node, the amount of stake, and the duration of operation. Additionally, this score is updated every 10 minutes.

2 Likes