ChainCrunch! — Mochimo’s solution to network scalability
There are SO many innovations that Mochimo is making in the space occupied by blockchain technologies. But one of the most promising is what we are doing to solve the problem of network scalability.
The Problem:
It is a comparatively easy thing to scale up a technology controlled by a centralized authority. Make it bigger — make it faster! Since changes only have to be verified by one (or a relatively few) Central Authority, making it bigger and faster is not difficult. But in a distributed ledger system (basically what blockchain is…) all changes are verified by a much larger number of systems. This inherent strength becomes quite a problem when attempting to scale. It is a much harder problem to figure out how to make all required nodes for a blockchain “faster.” And due to the ever-increasing size of most blockchains, this problem is compounded daily!
Other cryptos have said they are relying on Moore’s Law to help them out of their current difficulties. (Moore’s Law states that processor speeds, or overall processing power for computers will double every two years.) The problem with that claim is that their blockchain size is growing at a faster rate than Moore’s Law. This problem of scalability absolutely has to be solved, or mass adoption of blockchain will never occur.
Mochimo, however, has already solved the issue of large and runaway blockchain growth using an innovative block-chain processing algorithm called ChainCrunch. ChainCrunch is a proprietary Mochimo tech that allows a user to operate a full node, but maintain only a small percentage of the historical blockchain data. ChainCrunch is secured by HASH256, and is quantum proof. Because of this innovation the size of the Mochimo blockchain will not grow. Instead it will remain exquisitely and reliably small no matter how many years the network is operating, or how many transactions we process.
Mochimo’ s Solution — ChainCrunch
ChainCrunch is basically a proprietary technology that reduces the total size of the blockchain ensuring its ability to scale and process large numbers of transactions (scaling from existing 1K TPS to 20K TPS within 6.75 years).
ChainCrunch allows the network to maintain a complete picture of the ledger, validate blocks with perfect fidelity, and rebuild the local database of a new or existing peer in a few short minutes instead of weeks. Additionally, ChainCrunch allows for extremely rapid lookup for transaction validation, and for a blockchain size and storage requirement that is a small fraction of what is required for all other cryptocurrency networks.
A Mochimo “aeon” is 256 blocks, with block solve times spaced at 337.5 seconds apart, resulting in an average Aeon lifetime of 86,400 seconds, or one day. Each Mochimo server maintains a local database on disk that is a sorted list, indexed by address, of every address with a balance in the network. To put this in context, the system makes additions and deltas to that database based on blocks 1 through 255, by processing valid transactions and sorting the changes with each successful transaction. Having arrived at Block 255, the system writes the database to the disk as block 256, hashes it and appends a trailer, and continues forward by attempting to solve block 257.
From the moment, this neogenesis block is written to the disk, all historical data from the Blockchain is no longer needed for the system to function.
When a new system comes online or restarts as a result of failing a contention check, the system will use the random networks model to find a quorum of peers that are on the master chain. From that point, the Mochimo server issues a request to one random member of that quorum and pulls down the first previous neo-genesis block.
The untrusted neogenesis block that the server downloads contains a raw ledger file, listing the balances of every address with a balance in the Mochimo network. The Mochimo server imports this ledger in an untrusted state and uses it to validate the ensuing 256 blocks on the chain, pulling them from the Quorum swarm one at a time, and validating them against the ledger, making adjustments as necessary, and building on the local Trailer File.
On arriving at the 256th block, the server generates its own neogenesis block, which exists in a provisionally trusted state, and begins to validate all existing blocks in the current Aeon, until it arrives at the same Current Block as the Quorum, validating the block hash against theirs. From that point, the server waits for a new block to be solved by a non-swarm member, and if that block can be validated against the Server’s local state, the Server is said to be “Synchronized”, and local state information is now trusted.
The server now moves into the “Online” state and sends and receives transactions, attempts to solve blocks, etc. as usual.
This entire process, from beginning to end, will typically take a few minutes depending on how long it takes for the next block to be solved.