A Deep Dive into Mochimo — Part VI: Proof of Proof of Work — On the Edge of Sanity
This is the sixth 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 V: The Pseudo Block — A Block Unlike the Others
Don’t trust the messenger (specially not in crypto)
As mentioned in previous articles, implementing a distributed and decentralized system like a blockchain is hard; one of the biggest difficulties is being able to reach a consensus across all actors in order to ensure the stability of the whole ecosystem.
In a PoW blockchain, the criteria for consensus are based on the weight of the blocks in the chain (weight = spent computation power). When a node solves a block, it sends a message to its peers signaling the number, current hash, and previous hash. Upon receiving this message, the other nodes will download the new block, validate the cryptographic puzzle, validate each embedded transaction, and, finally, add the block to their local chain.
There is an obvious flaw in this design: it would be very easy to attack the network by continuously sending “block solved” message to the nodes, forcing them to download the block and validate its content. Of course, the block would not be valid, so all the time, bandwidth, and CPU/RAM resources spent in the process would be entirely wasted. This is a sort of Denial of Service attack (DoS).
Verify first
In order to defend against these kinds of attacks, the Mochimo network uses a feature called Proof of Proof of Work (or PoPoW).
Each “block solved” message contains the last 54 block trailers, including the trailer from the newly solved block. In a previous article, I explained that the information required to verify the Proof of Work is contained in the trailer. When a Mochimo node receives a “block solved” message, it verifies the PoW for each of the trailers embedded in the message, up to the trailer of the newly solved block. If they are all valid and consistent with each other (no mismatch between signatures), then the new block is downloaded.
With this system in place, it would be extremely costly for an attacker to run a DoS attack, as previously described, since it would require them to produce a valid block for each new message. Doing so would require more computation power than the rest of the network. On the other hand, the cost of verification for the node is very low: downloading 54 * 160 bytes (size of a block trailer) = 8.6KB and validating each trailer (a few milliseconds each).
PoPoW for stability of the network
Not only does the PoPoW prevent these attacks on the network, it also allows for very fast resolution of contention events. Contention happens when two or more miners solve the same block within a short timeframe, creating multiple different chains.
When a node receives a “block solved” message for which the block signature or/and number does not match its local blockchain, it can quickly identify the exact point where the chain split occurred by looking in the embedded trailers for a mismatch in signature, computing the weight of the remote chain, and comparing it against its local weight. If the remote chain is heavier, it only downloads the blocks mined after the point of split. If not, it simply discards the message.
In the rare case where a node receives a “block solved” message and cannot find a single match between its local chain and the embedded trailers, the message is discarded. This is what we call the “edge of sanity”: any message outside the 54 block window falls over the edge, the sender is declared “insane”, and the message is discarded.
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
