Chain Consensus Algorithm
End of 2022, time for some thoughts on the Consensus Algorithm of the Morpher Data Chain.
The Morpher Data Chain is facing two challenges:
One is fast block mining time, 1s or, less if possible. This would mean that a smart contract requesting a price tick gets an answer within 1s or less. This is the chain consensus algorithm and needs to be carefully chosen. It doesn’t need to be PoW or PoS, since our requirements are slightly different than other public blockchains. It’s almost Proof of Speed (you need to have a node running in a datacenter), but then, its really not that. Below more…
The other challenge is to generate a valid tick out of potentially many data vendors for the same market. E.g. BTC-USD prices, these are traded across different brokers and also DEXs. Given, right now less brokers than beginning of 2022, but still, there are potentially many data sources and then there could be many data providers for each data source. Somehow, we need to arrive at a “true” price tick.
This article is about the first issue, the blockchain consensus algorithm.
If you have any questions, feel free to join our Telegram group!
Clique
The most simple and fast consensus algorithm is the Clique consensus. In Clique, validators take turns to create the next block in a round robin fashion. When a block is produced, the signer broadcasts it to its peers which validate it and add it to their chain.
The Problem
To make the chain resistant to malfunction, disconnection or malicious activities of one or more validators, the protocol allows a set of validators (the out-of-turn validators) to create the next block. The out-of-turn validators come in, if they don’t receive one from the current validator (the in-turn validator) after a certain time (the out-of-turn delay). Since this is a fallback mechanism, an in-turn block is always worth more to the protocol than an out-of-turn block. So, if the in-turn block gets delivered late, the chain re-organizes and makes that block the new chain head.
But what if two out-of-turn validators make a block?
Then they are valued with the same difficulty, and the whoever receives a mined block first, will just keep that first received block. The same is true for combinations like in-turn block followed by out-of-turn block versus out-of-turn block followed by in-turn block.
Different validators can end up with different chains and keep them indefinitely just due to different block receiving times.
This is the main reason why the Clique consensus is not recommended for production. If, for some reason, the communication between peers halt or slow down, massive irresolvable forks can destroy the network.
Our first Approach
On the Morpher Data Chain, where block time is extremely low, the risk is magnified, so the simple Clique consensus cannot be used safely. On the other hand, other consensus algorithms are potentially adding a lot of overhead or are not suitable and won’t allow the chain to be fast and sufficiently decentralized.
Our fist approach was a solution we called “APC” (Authorized Progressing Clique) consensus.
This modified version of the Clique behaves exactly like the base version under normal circumstances.
The difference is, whenever a peer does not receive a block from the in-turn validator, it signs an authorization for allowing the next validator in the validator chain to create the block. If the next validator does not mine the block in time either, the following validator is authorized and so on.
We tried to mathematically prove that this approach has guaranteed finality after N / 2 blocks, but we couldn’t. It turns out, its impossible to prove. There is always a chance that a part of a chain suddenly receives a block from the delayed in-turn validator after another part of the chain already gave authorization to an out-of-turn validator.
And that’s why we will go with IBFT2 instead.
IBFT2
IBFT2 is a consensus algorithm that is designed to be more robust than Clique. It is based on the same principle as Clique, but it adds a few extra steps to make sure that the network is more resilient to malicious activities and network outages.
The Good
First, IBFT2 requires that all validators agree on the order of the blocks. This is done by having the validators vote on the order of the blocks. If a validator does not agree with the order, it can challenge the order and the network will re-organize itself to make sure that the correct order is enforced.
Second, IBFT2 requires that all validators agree on the block contents, difficulty, timestamp and block rewards. This is done by having the validators sign the blocks before they are broadcasted. If a validator does not agree with the contents of the block, it can challenge the block and the network will re-organize itself to make sure that the correct contents are enforced.
These extra steps make IBFT2 a much more robust consensus algorithm than Clique. It is more resilient to malicious activities and network outages, and it ensures that all validators agree on the order, contents, difficulty, rewards and timestamps of the blocks. This makes it a much better solution for production networks.
Also, IBFT2 has instant finality.
The Problem
While IBFT2 has the solution to many of the shortcomings from Clique, it isn’t without its own set of challenges.
On the Morpher Data Chain we potentially need to transfer vast amounts of data to validators. Naturally, we try to decrease the network load as much as possible. Since the majority of validators need to agree to a block by sending a pending block to each other, it is not really scalable.
With a growing set of validators, the load on the network will grow as well. It will keep us busy for a while longer to test the number of validators the chain can support in different scenarios. We’re not all in the same data-center, potentially spread across the planet. It is something we need to test thoroughly.
Stay tuned for more updates. Early next year we have some interactive goodies for you to test.