Explain it to me like I’m 14… and I know how Bitcoin works

Neutro Yellow Paper — “Simplified Payment Verification nodes” chapter

This is part two of our short series and here we’ll try to explain in simple terms how can I, operating a lightweight node, verify the correctness of the chain/ compare the two or more seemingly valid chains given to me by my peers? Simplified Payment Verification is a term borrowed from Bitcoin. The meaning is the same, the method is different though.

In Bitcoin I can store on my device just block headers. It’s easy to calculate the PoW difficulty combined for all blocks as PoW itself is difficult and costly to perform, but easy and cheap to verify. Because in Neutro our focal point of consensus is relative Proof of Work combined for all blocks, and to know the relative Proof of Work we must know how many votes (or rather votes cast using how many validation tokens) are included in each block, we must verify a lot of votes for each block. That is a problem.

But what if in every block there was a simplified “list” of votes in the same order as they are included in the Merkle tree within that block? Let’s say I want to create a false chain. I include this list in every block of my chain and the proper Merkle tree with votes. In order to raise my blockchain’s relative Proof of Work, I must include some “artificial” (created by me in order to cheat the network) votes. I can try to cheat the SPV nodes by either:

a) including in my block’s “list” of votes false values that do not exist in the Merkle tree

b) including in the Merkle tree votes that are false or otherwise incorrect

As an SPV node I can use the following method of “random questions”. As I download a block, I see a list of votes. First thing I should do is to calculate if, assuming that list is not falsified, the relative Proof of Work for that block would result in a value that is declared within that block. If it wouldn’t — it’s an incorrect chain. If it would — I now ask for random votes from that list and check their correctness (value, signature, adherence to protocol’s rules). Let’s say there are 20 votes in the list. I ask for votes number 3,8,19,20. My peer “shows” me them by providing me with the correct Merkle path (as they are stored in the form of a Merkle tree).

What’s the motive behind that? The more someone wants to cheat the network, the more false votes he will include in his chain. The more false votes he includes in his chain, the more likely SPV nodes will detect his lie. This method allows an SPV node to ask for and verify only a small portion of data. But, because of the logic presented above, the probability of catching a liar is growing with the “size” of his lie. If an adversary produces just a small number of false votes within his chain, it won’t help him much. If he produces a lot of false votes, the probability of him cheating any SPV node is decreased with every false vote included in his chain. This probability, with proper parameters, is extremely low given even the few percents of false votes. So this is the method of easy verification of the main-chain.

Once I’ve verified the main-chain, it’s easy to verify if a given transaction was performed in a given block of a given shard-chain. I just need to follow the Merkle path from a given main-chain block to a given shard-chain block header, then starting from that shard-chain block header (or Merkle root included in it, to be precise) to data within that shard-chain block that I need.