A Deep Dive into Mochimo — Part III: Syncing the Blockchain — From Weeks to Minutes — The Tale of ChainCrunch
This is the third 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 II: Dissecting the Blockchain
Scalability of distributed systems
Implementing a distributed system like a blockchain is hard, even more so when that system must handle hundreds of transactions per seconds, as is the case crypto currencies. Today, one of the biggest issues with crypto currency blockchains is their scalability, meaning that their ecosystems cannot scale to handle a multitude of users. As a result, the requirements to be part of their network are getting ridiculously high and time consuming, pushing them out of reach for the average user:
- Hundreds of Gigabytes (sometimes even Terabytes !) to run a node
- Weeks to synchronize the blockchain
- Lots of RAM and CPU to run
The consequences of this failure to scale are not to be taken lightly. In periods of stress, we have seen transactions pending for days and transaction fees skyrocket to mind-blowing levels.
Having such a high barrier to entry has led to a situation that has been surprisingly overlooked so far: when the amount of effort and time required to run a node is too high for the average human being, they will rely on an external provider to control their funds and/or process transactions. More specifically, how many people will actually start a full node to verify their transactions when the cost in effort and time to do so is measured in days ? None. They will, (as I am sure we all do, myself included) use one the myriad of “block explorer”. In other words, we are relying on a centralized authority to verify transactions on a decentralized system…
In order to have real decentralization, running a node must be fast (within minutes), almost costless, completely trustless, and must be doable on an average consumer grade computer.
Some projects choose to use pruned nodes. Pruned node are nodes that don’t bootstrap their internal ledger from the Genesis block, instead using a past snapshot of the ledger to which they apply all blocks mined between the time of the snapshot and now. This is not a viable solution, since it fails the third requirement as they are not trustless. A pruned node needs to trust whoever shared the original snapshot of the ledger.
Mochimo ChainCrunch ™
In order to keep synchronization fast, costless, and, more importantly trustless, the Mochimo development team created the ChainCrunch mechanism. This technology allows Mochimo to keep the total amount of data required to sync a node to a minimum. At the time of writing, the blockchain is 15 months old and has mined over 100K blocks. Yet the total amount of data after synchronization is less than 100Mb and the total time to synchronize is just a few minutes:
The node starts by downloading the tfile for the first few seconds. Then the blocks are downloaded. Finally, the ledger is built and each block is validated. The total time for synchronization is 3 minutes 24 seconds. The node is hosted on a VPS 2 CPU 4GB RAM, although only 750 Mb are actually used. In fact, the node can easily be run on a Raspberry Pi.
One might think that those values are low only because Mochimo is still a young blockchain. Well, good news everyone! The amount of data and the time required to synchronization will stay low even when we reach the peak utilization of Bitcoin.
Let’s look at some numbers.
In order to synchronize the blockchain, the ChainCrunch technology requires 255 to 510 blocks, the trailer of all blocks ever mined, and a snapshot of the ledger (called a Neo Genesis block in the Mochimo ecosystem). A Neo Genesis block is minted in the blockchain in place of a regular block once every 256 blocks. These blocks don’t hold any transactions and don’t need to be propagated on the network since a given Neo Genesis block is identical across every node of the chain.
The total number of unique addresses on the Bitcoin blockchain peaked at 1.1M on December 2017 and the total number of transactions per day peaked at 500K in the same period. At that time, the number of blocks on the Bitcoin blockchain was about 500K.
As mentioned in the previous article, the size of a transaction in a Mochimo block is 8824 bytes, the size of block header is 2220 bytes, 160 bytes for the block trailer, and the block time is 337.5sec (255 block a day plus 1 Neo Genesis block). This would yields an average block size of 1960 transactions * 8824 + 2220 + 160 = 17.3 Mb. The Neo Genesis block would be [2208 bytes (size of the WOTS address) + 8 bytes (balance of the account)] * 1.1M = 2.43Gb. The size of the tfile would be 160 bytes (block trailer) * 500K = 80Mb.
So, in a scenario where the Mochimo ecosystem might need to handle the same conditions Bitcoin faced in December 2017, syncing a full Mochimo node for the first time in a trustless way would require (255 to 510) * 17.3 Mb + 2.43Gb + 80Mb = 6.9 to 11.3Gb.
Let’s check the estimated download time for 6.9GB:
And for 11.3GB:
Note that these calculations do not account for any compression data or the fact that one can download several blocks from different peers at the same time which will even further reduce the time needed to synchronize.
How does ChainCrunch works ?
Upon starting up, a Mochimo node will ask different peers about the weight of the chain they are currently mining and will select the highest weight since that is the chain which has spent the most computation power up to this point in time. Once the node as selected a chain, it will first download the block trailer file (tfile). Remember that the trailer of a block contains all of the information required to verify the Proof of Work, so the node can easily compute the weight from the tfile and verify that it matches the value advertised by its peers. If not, the node discards the chain and its peers and repeats the search process.
Once the heaviest chain has been found, the node downloads the penultimate Neo Genesis block (not the previous one, but the one before that). After the download is complete, a hash of the Neo Genesis block is calculated and checked against the hash of the same block in the tfile to ensure the integrity of the block. From this point, the node downloads all blocks up to the current state of the chain and check the hash of each of them against the tfile. When the last Neo Genesis block is reached, instead of being downloaded, it is built from the current state of the ledger and the hash is checked against the tfile. This is a second layer of security to ensure the validity of the ledger.
And voila, you have made a trustless synchronization of your node with the blockchain in only a few minutes.
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
