TomoChain slashing mechanism for network stability and performance

Published in

TomoChain

7 min readOct 31, 2018

In this article, I’m going to describe the TomoChain slashing mechanism, which will be integrated into TomoChain’s Proof-of-Stake Voting consensus. The slashing mechanism aims to enhance TomoChain’s public blockchain stability and performance.

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

TomoChain PoSV consensus background

At the heart of TomoChain, the Proof-of-Stake Voting consensus enables it to be an EVM-compatible and scalable public blockchain. This means that every Ethereum smart contract can be run on TomoChain with an almost instant transaction confirmation. TomoChain relies on an architecture of 150 masternodes. This set of masternodes dynamically changes every epoch, depending on the votes of token-holders.

In order to become a masternode candidate, a token-holder must deposit at least 50K TOMO to a voting smart contract. To become a masternode in the ecosystem earning rewards, the masternode candidate must be in the list of top 150 voted candidates. Information on the performance (CPU, memory, the number of verified blocks, etc.) of a masternode candidate is shown on a decentralized governance application called TomoMaster to help token-holders make voting decisions.

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. Underperforming masternodes might be eliminated by the token-holders through un-voting. The incentives for token-holders to make voting and un-voting decisions are the rewards they can receive depending on the performance of their voted masternodes.

To strengthen the system security, TomoChain 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. The analysis of how security is strengthened by these techniques is not detailed in this article and readers are recommended to refer to TomoChain technical paper and this article for more information.

Network instability and performance problem

So, what is the problem here? Remember that TomoChain 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 within which it is elected. Some reasons for this might be that the masternode does not have the correct TomoChain 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 TomoChain’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 37 masternodes) of the 150 masternodes are underperforming, the total wasted time is 37 * 6 * 10 = 2220 seconds! It’s longer than the duration of an epoch. That being said, if these 37 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

As previously analyzed, underperforming masternodes would be eliminated out of the masternodes list because wise token-holders will choose the best performing masternodes to maximize their profits from voting. Unfortunately, this analysis comes from a very optimistic perspective! Even if the network is so dynamic that token-holders will quickly withdraw their previous votes for the underperforming masternodes, there are still two scenarios in which the underperforming masternodes still remain in their position:

There are less than 150 masternode candidates: the underperforming masternodes will not be kicked out regardless of what voting decisions the token-holders make.
The underperforming masternodes have deposited such a significant amount of TOMO that even in the event of massively withdrawing votes previously dedicated to them, their deposited amount of TOMO is still sufficient to maintain them as top staked candidates.

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 kicked out of the masternode list for the next 4 epochs. During the latter, the 151st candidate will be automatically promoted to replace his seat if the total staked tokens of the 151st candidate is more than the kicked masternode.
If more than one masternode is underperforming, the masternodes list for next epoch are chosen as follows:

(1) Sort the top 150 voted/staked candidates list in a decreasing order by tokens staked.

(2) 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 150. However, the active masternodes will not have to wait 10 seconds for underperforming masternodes’ blocks.

(3) For example, assume that in epoch 10, there are 3 underperforming masternodes m1, m2, and m3 with 60K, 62K, and 64K TOMO staked respectively, and these underperforming masternodes are at the bottom of the masternode list. Also assume that, at the end of epoch 10, there are 3 additional candidates m4, m5, and m6 with 59K, 61K, and 63K TOMO staked. In this scenario, for epoch 11, the sorted list is as follows: [147 most staked masternodes, m3, m6, m2]. Because m2 and m3 were previously considered as underperforming, they do not have the right to create blocks. Candidate m6 becomes a masternode for epoch 11 since it is in the list of top voted candidates.

If the number of masternodes is less than 150, the underperforming masternodes will also be kicked out but there will be no promotion (since there is no candidate).
In other words, a masternode can only have its block production right for the next epoch if and only if (1) it is still in the top 150 voted candidates and (2) it has not been considered as underperforming within 4 previous blocks.
At the 5th epoch after being slashed, the slashed masternode can go back to the candidate list to fight with the others by the total tokens staked for him (deposit + vote).
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 the others about its liveness. However, the underperforming masternode does not receive rewards for verifying and signing off blocks after being kicked out.

This slashing mechanism has two properties:

Accountability: A underperforming masternode is always detected if it is silent within an entire epoch. TomoChain PoSV 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 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, it will always be selected as a masternode again if its total staked tokens make it one of the top 150 most voted candidates. 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 behaviour 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 behaviour. 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 electricity 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 a underperforming masternode just because its electricity source turns off for 30 minutes.

Conclusion

Network instability and low performance of TomoChain have been seen with TomoChain’s public testnet without slashing. New versions of TomoChain’s public testnet have been continuously developed to integrate the slashing mechanism. So far, I have seen a significant improvement in the current public testnet, which gives TomoChain’s team confidence about our proposed slashing and our whole blockchain infrastructure.

TomoChain contact

For General support: TomoChain Chat

For Technical support: Gitter