How the XinFin Network slashing mechanism makes Network decentralized.

[NadarSuresh]

I’m going to briefly remind the readers about XDPoS before diving into the problem slashing aims to solve. I will then explain the slashing mechanism with XDPoS proposed slashing followed by a discussion of other slashing mechanisms from Ethereum Casper.

XinFin XDPoS Consensus Background
At the heart of XinFin, XDPoS that enables it to be an EVM-compatible and scalable public blockchain. This means that every Ethereum smart contract can be run on XinFin XDPoS with almost instant transaction confirmation. XDPoS relies on the architecture of 108 masternodes.

In order to become a masternode candidate, a token-holder must deposit at least 10 million XDC to a smart contract. masternode candidate is shown on a decentralized governance application called XinFin Master-Node App.

Masternodes are selected to create blocks in a round-robin fashion. A maximum of 900 blocks are created within an epoch and there is a block created every two seconds. Masternodes are also responsible for verifying and signing blocks in order to finalize the blocks. And all the masternode on the network are KYC enable masternode.

To strengthen system security, XinFin XDPoS also proposes double validation and randomization techniques. In double validation, when a masternode creates a block, this block must be verified by another masternode. The verifier is randomly selected among the remaining set of masternodes.

Decentralize Network instability and performance problem
So, what is the problem here? Remember that XinFin XDPoS is a public blockchain that allows anyone to freely join and leave the network. Now let’s consider a situation where the network has some underperforming masternodes. By underperforming, I mean the masternode does not sign/verify any blocks during the entire epoch. Some reasons for this might be that the masternode does not have the correct XinFin XDPoS software or the masternode crashes due to the lack of e-maintenance and operation by the masternode owner.

Underperforming masternodes can dramatically decrease the performance of the whole network and cause network instability. In XDPoS's current implementation, when a masternode fails to create a block on his turn, the whole network has to wait for 10 seconds of time-out before the next masternode in the round-robin takes its turn to create the next block. This means the whole network wastes m*10 seconds (m is the number of turns the underperforming masternode is selected within an epoch to produce blocks).

To make the problem worse, if ¼ (or 27 masternodes) of the 108 masternodes are underperforming, the total wasted time is 27 * 6 * 10 = 2220 seconds! It’s longer than the duration of an epoch. That being said, if these 27 masternodes are not eliminated out of the network, the performance will be decreased by more than 50%! There is actually a worst-case in which more than ¼ of the masternodes are underperforming. In this case, no finality can be reached since there are not ¾ of the masternodes signing off blocks. This means all masternodes are just wasting resources but completing nothing.

Slashing mechanism
The objective of the slashing mechanism is not to blame the underperforming masternodes but to mitigate the aforementioned issue to keep the system stable and performing. The slashing mechanism is as follows:

If a masternode does not sign any block during an entire epoch, the masternode will be slashed from the masternode for the next 4 epochs.

If more than one masternode is underperforming, the masternodes list for next epoch are chosen as follows:

If a masternode was considered as underperforming within 4 previous epochs, it is considered as ‘kicked-out’ and does not have the right to create blocks. Therefore, the number of masternodes responsible for creating blocks in this epoch might be less than 108. However, the active masternodes will not have to wait 10 seconds for underperforming masternodes’ blocks.

Once kicked out of the masternode list, the underperforming masternode can still verify and sign off blocks. This mechanism is used for the underperforming masternode to notify others about its liveness. However, the underperforming masternode does not receive rewards for verifying and signing off blocks after being slashed out.

This slashing mechanism has two properties:
Accountability: an underperforming masternode is always detected if it is silent within an entire epoch. XDPoS consensus has a smart contract called block signer. Block signer stores all block signatures produced by masternodes. The laziness of a masternode is easily accounted for by reading the number of signatures it has sent to the block signer smart contract during the epoch.

Liveness: If a previously slashed masternode becomes live again after 4 epochs of slashing, This property is guaranteed by allowing the demoted masternode to verify and sign off blocks, which is a signal demonstrating its liveness, as previously described.

Discussion
Slashing has been considered in Ethereum Casper FFG designed by Vitalik Buterin to move Ethereum consensus from Proof-of-Work-based to Proof-of-Stake-based. The objective of Casper slashing is to prevent Ethereum from the nothing-at-stake problem — in which Casper validators would choose to validate and finalize all forks. Attackers can take advantage of the nothing-at-stake problem to double spend. Casper slashing states that if two forks can be both finalized (a fork in Casper is considered as finalized if ? Casper validators validate the fork), there will be at least? Casper validators trying to validate both forks. These validators then lose their entire deposit for violating the consensus rule stating that one validator has to attest to only one fork.

Casper slashing tries to prohibit intentional bad behavior from malicious validators that violate the consensus rule. This is why slashing is very strong as it is used to discourage validators from committing any malicious behavior. TomoChain’s slashing is quite different in its philosophy. Underperforming masternodes do not intend to attack the network and the reasons for not verifying any block during an entire epoch might be, for example, an electrical problem or a server crashing. Burning the staked tokens of underperforming masternodes creates fear among participants, thus discouraging people from participating in the system. There is no reason to take all deposited tokens from an underperforming masternode just because its electricity source turns off for 30 minutes.

Useful link for XinFin Masternode

Steps to Setup Masternode on XinFin MainNet

XinFin Mobile Wallet

XinFin Web Wallet

Steps to resign master node

Step by step guide to issue your own token on XinFin network

Step by step guide to swap token on XinFin network

Guide to setup node with one click installer

Watch the video to Setup XinFin Masternode with One-Click installer

Follow XinFin on:
Twitter: ( @ ) XinFin_Official

LinkedIn: https://www.linkedin.com/company/xinfin/

Telegram: https://t.me/xinfintalk