A Deep Dive into Mochimo — Part IV: Consensus, Split and Orphan — The States of the Chain
This is the fourth part of a series of articles about the Mochimo blockchain, a 100% original, no-ICO, no-presale crypto currency project.
Follow us on Twitter, Discord, Reddit
If you haven’t already, read our previous article A Deep Dive Into Mochimo — Part III: Syncing the blockchain — From Weeks to Minutes — The Tale of ChainCrunch
Consensus on distributed system
The blockchain is a distributed technology that can be sustained without the need for a centralized authority. That makes it a great tool against censorship but decentralization comes at a cost. In a centralized system, there is no need for a global consensus; all actors simply follow whatever the chief authority decides. But for a decentralized network, having a consensus across all actors is a vital part of the stability of the whole ecosystem.
The consensus of the chain is threatened when a group of nodes disagree on the current state of the ledger, resulting in multiple different chains. This state is referred to as a chain split.
Among the possible causes for a chain split:
- Several solutions for the same block are found and propagated across the network at the same time
- A miner who has not been receiving transactions or/block solves for some time mines a block and propagates it across he network
- A change (intentional or not) in the protocol renders some blocks or/and transactions invalid for a group of nodes
- Various attacks
Consensus in the Mochimo ecosystem — Random Network Model to the rescue
The Mochimo nodes are using a connection management system based on the Random Network Model. Rather than considering only recent, well-known, or geographically close peers, the node interact (exchanging information such as block solves, transactions, etc) with the entire fabric of the network. The Random Networks protocol is designed to propagate information quickly and asynchronously.
When a node is started on the Mochimo network, it is bootstrapped with a shortlist of peers. These peers only serves as an entry point to the network, meaning that there is no guarantee that they will be on the local peers list of the node once the initialization process is completed. Every node that is part of the network has an equal chance of ending up on the local peer list, whether or not they were among the bootstrap peers.
In order to build the local peer list, the node will send a GET_PEER request to each peer on the bootstrap list at first, then to randomly selected peers returned by the original GET_PEER requests. At the time of writing, the default configuration creates a local peer list with unique third-degree connections. This is enough to randomly connect up to 4096 nodes (a rotating and randomized network means that the degree of separation between any two nodes on the mesh is 16^D = N; 16³ = 4096). When our network grows beyond this level, we can easily update to four degrees of connections and randomly reach up to 65536 nodes.
Resolution of chain splits — Orphan chains must be left behind
In a Proof of Work blockchain, most of the chain splits are bound to be resolved when the chain with the highest weight (the chain that has spent the most computation power) eventually overtakes all the other chains. Those chains with lower weight become orphaned and after a period of time, will simply disappear.
In the Mochimo ecosystem, thanks to our random distribution of peers, chain splits are rare, short-lived (generally resolved in a matter of a few blocks), and orphan chains are definitively discarded after 54 blocks at most. This happens because of the various unique mechanisms such as ChainCrunch and Proof of Proof of Work (more on this in another article).
Ortis.
Edited by Kashmyr
About the author: I am a contributor to the Mochimo project and a founder of the mining pool illamanudi.
Twitter, GitHub
