Slash Mechanism

Introduction to REI Network Slash Mechanism

The consensus algorithm of the rei-network is reimint. In order to finalize the next block, reimint will collect votes from the top 21 validators for each candidate block. When the voting power collected by a certain candidate block is greater than 2/3 of the total voting power of the top 21, the block is produced. It is conceivable that if a validator signs multiple candidate blocks at the same height, the final result may finalize multiple blocks. In the worst case, it means that the blockchain has forked, and at this time all transactions may be rolled back to the height at which the fork started, and the status of all transactions cannot be determined.

Assuming that if the current block height is 100, and the confirmation height of the exchange deposit is 10, the attacker initiates a recharge to the exchange at the height of 100, and is confirmed by the exchange at the height of 110, and then the attacker immediately sells ​​all the tokens into stablecoins on the exchange and withdraw them to other blockchains. If the attacker successfully launches a multi-signature attack at a height of 100 to roll back all subsequent transactions, the final result is that the tokens are still on the attacker's account, but the attacker managed to steal the equivalent of stablecoins from the exchange.

In order to prevent this from happening, multi-signature validators must be punished. All validators in the network (block-producing validators and non-block-producing validators) will continuously collect all votes, and once a validator is found to perform multi-signature, it will be packaged all repeated signatures to generate a proof, and then broadcast this proof to the whole network. When packing a block, the block-producing validator will pack the evidence it currently collects into the block header. When processing a block, the proof recorded multisig validators are slashed.

At present, the single slashing ratio set by the rei-network mainnet is 20%. This means that all users who voted for the slashed validator and the validator itself will lose 20% of the REIs.

Proof

The first proof on rei-network appeared at the block height of 9185063. After decoding the extraData, the following two repeated votes can be obtained (for the convenience of observation, it has been converted to JSON format)

Vote 1:

{
  "chainId": 47805,
  "type": 1,
  "height": 9185061,
  "round": 0,
  "hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "index": 16,
  "signature": "0xa82def5f576359ebf9e84472df4e5e549b87127e4e0c8ddd40766da8354c44114ccfd2cc7a2d512f6da41f314431960a0c1ebac0bd8cabc26f857c7a17bb335000"
}

Vote 2:

{
  "chainId": 47805,
  "type": 1,
  "height": 9185061,
  "round": 0,
  "hash": "0x5a44cc5c7221c84499329e3cf383114d96d2f155d3de5a45bbe8917861d9fcdf",
  "index": 16,
  "signature": "0xe90523621aeab80466cadde79acc5b9ab1e35540b862071de77c83f69a7f507846b345bba46b66a4fab94f619f5cf422cd289525af279b78a4bd613cc107622701"
}

The meaning of each field:

Name	Meaning
chainId	Chain ID
type	Vote type, 1 means prevote type vote
height	Candidate block height
round	Number of rounds, if no consensus is reached in this round, it will enter the next round of voting, and the number of rounds will be increased by 1
hash	Candidate Block Hash
index	The position of the signing validator among the top 21 validators
signature	secp256k1 signature, according to this signature and other fields, the address of the signing validator can be recovered

FAQ

Q: Why is the height of the block different from the height of the signature, one is 9185063 and the other is 9185061?

A: Because it takes time from the emergence of multi-signatures to the proof being packaged

Q: Why is the hash of one of the votes is 0x00....0000?

A: Because in reimint, if the validator votes for 0x00....0000, it means that the validator wants to enter the next round of voting. For many reasons, such as the validator doesn't receive this round of proposed blocks in time

Possible reasons for a Validator to be slashed

• Run two validators with the same address at the same time

• The validator's private key leaked

• Malicious tampering validator program