The Soft Majority Fault Tolerance or SMFT consensus protocol increases blockchain security to the level where any attempted malicious attacks become meaningless. At the same time, high speed is achieved while retaining a sufficiently decentralized consensus.
The SMFT protocol is an original Everscale development, and it’s a truly great innovation in the blockchain space. The consensus raises the bar to 50% fault tolerance (compared to the 33% of Byzantine Fault Tolerance or BFT) which is the maximum security level by design in decentralized systems.
To put things simply, whereas the BFT consensus protocol enables only one chain in the data shard to be processed by design, the SMFT consensus allows for processing many chains (processing shards or threads) in one data shard (WorkChain).
SMFT allows all validators in each workchain to participate in network security, and adding more validators exponentially increases the security level. The total number of validators per workchain is up to 4,000.. Therefore, if we assume 50% fault tolerance, that would mean 2,000 validators would have to be malicious in Everscale in order to negatively affect the network. Of course, it is highly unlikely that such a large number would collude. By comparison, most other blockchains have just 10–20 validators in each data shard, as most of them have the same sharding design.
In BFT, if more than a third of the validators appear to be malicious, the network will stop, and if two-thirds of the network colludes, that majority will have enough power to manipulate transactions. Having just 10–20 validators in one data shard thus not only threatens decentralization, but is generally a deplorable situation for network security. Whether the validators are randomly rotated or not is unimportant — any attack on the network is simply a matter of chance. There is zero cost in organizing an attack on such networks.
The SMFT consensus allows all validators in all workchains (up to an infinite value) and all validators in each workchain (up to 4,000 validators) to secure the network, which is synchronized at the masterchain level. All validators in all workchains can see the global state (Merkle tree), but at the same time, each set of worchain validators is in full sync within its workchains.
The above means that all validators in all workchains (data shards) are able to participate in network security as one huge validator set, not to mention that there is no limit to the total amount of workchains (data shards) in the Everscale network — each workchain is launched on demand if there is a need to add more processing and computational power.
“Red flag” — any collusion or attack makes no sense
Everscale uses an innovative “red flag” mechanism to increase security and decentralize the consensus. Before blocks are completed or finalized, they are approved by a number of verifiers. Meanwhile, the verifiers are randomly selected from a common pool of validators — the important part is that no one except for the verifier in question can say whether they are a verifier or not. In other words, potential attackers cannot calculate who is going to be the next verifiers.
First, a block received from the flow validators is broadcasted to at least 51% of the workchain validators. A set of verifiers is randomly selected from these workchain validators. The verifiers may respond to a block from a processing shard (thread) with a red flag or verify a block as valid and transmit the hash to the masterchain.
However, if at least one verifier raises a red flag signaling malicious behavior to everyone, the masterchain initiates a full consensus procedure involving all workchain validators. The set of validators for the workchain has to come to a full 51% absolute majority consensus and resolve the conflict through slashing the stake of either the attacker or the verifier if they raised the flag incorrectly.
This means that if the verifier’s red flag is accepted by the full set of validators, and if the block is proved as wrong, the validator proposes that the block gets slashed and the attacker loses their whole stake (an estimated 600,000+ EVER tokens at the time of writing).
On the other hand, if all validators confirm that the block with regard to which the red flag was raised is indeed valid, the stake of the verifier who raised the red flag is slashed, as their behavior can be considered as malicious, trying to cheat the consensus. Otherwise, verifiers could raise red flags all the time and block production would be significantly slower.
Complete anonymity of verifiers pre-verification
The beauty of this approach is that the validators of each thread (processing shard) have no idea who the verifiers will be. This means that it is impossible for malicious nodes to coordinate an attack between validators and verifiers, and it makes absolutely no sense to pursue a conspiracy between validators because all the odds are against its success.
Even if a malicious collator is in cahoots with 50% minus one validator, there is no chance of identifying the verifier — there is simply no available information to do so, and therefore, in terms of probability, any attack is never successful.
Even if the attacker had the entire possible amount of EVER tokens to acquire at every attack attempt, the chances of success are still statistically extremely low, and the attacker would lose their whole stake every time after each unsuccessful attack.
For example, in order to have a chance in any way significant (approx. 1%) of affecting the network, the attacker would need to burn their whole stake 100 million times. There simply isn’t that amount of tokens in Everscale’s total supply.
The whole idea of an attacker burning their entire stake seems absurd. Moreover, the cost for each attack would increase, as the attacker would need to buy the whole stake on the open market, which would increase the price per token exponentially.
In short, there is no sense in malicious behavior, as all participants have skin in the game in the form of their tokens. As for attackers, each attack they might theoretically undertake would cost all of their tokens. This is not the case in other networks, where the cost of an attack equals almost zero, and validators just need to wait for the best moment to collude in one shard.
Broadcast Protection Protocol
There is one more thing that makes the picture complete. We need to be sure that a block has been transmitted to all validators and that it has been verified. In order to ensure this, there is the Broadcast Protection Protocol, which proves block propagation.
This protocol ensures that we can prove that a block has been transmitted to at least 51% of all the validators. After that, it is almost impossible to predict with a high enough chance who is the verifier among 51% of all validators (up to 4,000 validators in one workchain). If the verifier has proved the block as valid, all validators can find out post factum who the verifiers of the previous blocks were and check that they did their job; otherwise, the verifiers will have their stakes slashed. This means all validators know that verifiers will be selected randomly and all blocks should be verified, as it is in the verifiers’ economic interests to perform their part of the job.
Scalability, security, and economic feasibility
In a nutshell, this leads us to the fundamental point that all validators have to perform an economically efficient job and will earn rewards in exchange for providing computational resources and data processing, and the only way to do that is by following the SMFT consensus.
Moreover, the SMFT consensus makes any attack absurdly ineffective economically, considering the fact that any slashing, in other words burning the whole of a validator’s stake, would lead to a serious reputational impact.
It’s important to understand that all validators in the Everscale network participate in the SMFT consensus, meaning that network security rises exponentially when the network scales. Everscale’s unique architecture allows it to scale on demand as more dApps/users join the network.
Unlike other blockchains, Everscale can scale infinitely, increasing its overall computational resources, level of security, and decentralization by adding more workchains/validators/processing shards to the consensus. Of course, there should be enough economical incentives for validators to participate, and that’s why scaling should happen on demand.
You can see how SMFT works in this video and check out the relevant documentation.
