Introduction to Mina

Let's take a look at how Mina describes itself:

Mina is the first cryptocurrency protocol with a succinct blockchain. Current cryptocurrencies like Bitcoin and Ethereum store hundreds of gigabytes of data, and as time goes on, their blockchains will only increase in size. With Mina however, no matter how much the usage grows, the blockchain always stays the same size - about 22kb (the size of a few tweets). This means participants can quickly sync and verify the network.

This breakthrough is made possible due to zk-SNARKs - a type of succinct cryptographic zero-knowledge proof . Each time a Mina node produces a new block, it also generates a SNARK proof verifying that the block is valid. All nodes can then store the small proof, as opposed to the entire chain. By not having to worry about block size, the Mina protocol enables a blockchain that is decentralised at scale.

We can sum up several key points from the above:

1. Constant blockchain size - 22kb only!
2. Only the latest block/proof is needed to verify the entire blockchain.

These really sound thrilling! It means anyone who wants to be a node to participate in the blockchain only takes a few seconds to sync, while nodes of other blockchains have to sync blocks since genesis to verify. More importantly, light clients for end users, like a wallet, can now confirm the block directly in a very lightweight manner instead of relying on a 3rd party server/node to tell them what's going on in the chain without validating measures.

This magic lies within the recursive zk-SNARKs technology. A simple figurative example is: You will visit a park for 7 days. How to prove it in one photo?

Day 1, you take a photo with a calendar showing the date.
Day 2, you hold the photo taken from Day 1 and a calendar showing the date.
Day 3, you hold the photo taken from Day 2 and a calendar showing the date.
Repeat the same procedure until Day 7. Now you have a recursive proof of your tour in one photo.

So, everything so far, from concept to technology, seems to make sense. But wait, something isn't right.

Fact check: The 22Kb constant size

This is the easy part to be disproved. Everyone who has common sense can figure it out.

Imagine you have a growing number of users. How is the size of your database fixed? In any system that needs to express states on a growing scale, the only thing that can be a constant is the state root, not the state itself.

But, where is the state stored? It can be anywhere, in a real full node or an archive node, but not your 22Kb one. Actually, the state of a system can be very large without any upper limit. So if your node gets a constant size blockchain, it's unable to verify specific detail. Instead, you're merely verifying the validity of the proof from some computations. What are those computations? You have no clue at all without additional info. Apparently, it's not enough in most cases.

In fact, every blockchain can be named a constant sized blockchain, if you only store its latest block header. It does sound hilarious LOL.

You might say, but block headers of other blockchains are not recursive to all previous blocks since genesis, so it still makes a difference. So yeah, if you do, it proves you learned well on this topic.

But, what if ...?

Fact check: Recursive to where?

Don't worry. We won't initiate a zero-knowledge or recursive snark course here. It's sufficient to fact check their claims with a thought experiment.

Let's start this part with a validator node's perspective: he wants to validate the blockchain because he's sceptical about:

1. The latest block is a fake one. In this case, he believes all other blocks are valid.
2. There are some blocks in the remote past that are invalid. For some unusual reason, those blocks remain there formally or virtually: the majority of validators of the network colluded(formal), or the node he connected to is lying about the history(virtual), etc.. Someone may call the first reason a hard fork, but that doesn't justify the case, because hard fork is a neutral term, which can also be secret and dirty - maybe only the colluders know it happened as there were few users or validators in the past. Anyway, he's going to find out.

Case 1

For case 1, it's easy to validate.

In the Mina blockchain, he can use VerifyBlock(S[i−1], B[i]) to verify, where S[i-1]is the previous blockchain summary and B[i] is the latest block.

In other blockchains, he can also use a similar technique: σ[t] ≡ StateTransition(σ[t-1], T), where σ[t-1] is the previous state and T is the transaction that caused the state change. Beware: here he only needs to download the previous state trie and the new transaction. Namely, he doesn't have to sync all data since genesis.

See? Neither Mina nor other blockchains have to sync data since genesis.

Note: The above description is just a simplification in theory. For blockchains like Ethereum, without a proper part of the state trie, there's no way to compute state transition.

Syncing doesn't have to start from the genesis point, but it also takes a significant amount of time to download the entire state trie in practice. If we consider there are up to 400 txs in a block, then we can find the relevant nodes of the state trie for those 400 txs and only sync the relevant ones in the trie, such that the state transition computation can be roughly in a short constant time. So for this particular task in our case, a customised client with small spacing download checkpoints(like Parity) and partial state trie syncing is preferred.

Case 2

In case 2, ofc, you have to sync from genesis for an ordinary blockchain. There's no way to tell whether an indefinite remote block is valid or not if not from genesis. According to StateTransition(σ[t-1], T) you have to validate block by block to justify the entire chain.

For Mina, can you really forget about the old blocks and only care about the latest one, due to recursive snarks directing a clear path to the very beginning?

In the Imaginary perfect Mina chain, a perfect ZKP path(blue line) leads to the genesis. Though you can't tell what happened along the path, it's unassailable that you can prove the path exists with recursive snarks proof.

But! Which path? Recursive to where?

Consider this: Someone runs a fork of the Mina chain. He copied Block 2' from the forked chain directly to Mina. How did he do that is irrelevant to our discussion here, as I just mentioned 2 possibilities in the above paragraphs. Anyway, it's just there. There is no cheating in Block 3, 4, 5, 6.

According to Mina's claim, our validator should only check Block 6 to justify the entire blockchain. When he validates the proof of Block 6, he will find nothing wrong because the ZKP path leads him to the genesis of the forked one! And he doesn't know what the true path/genesis should be. Actually in the above picture the 2 paths even share an identical genesis. It's computationally correct, sound and solid, and indistinguishable if you don't sync from the real genesis to get a right path.

Actually, case 1 is a subset of case 2. Thus it's inevitable to be fooled even only consider the latest block, if the same measure were applied.

You'll get a detailed understanding if you know the data structure of Mina blocks.

I think you may get the point now: The recursive ZKP used here can prove you did come from some origin. The origin exists. The path exists. The computations and state transitions along the path exist.

But what it misses are, who/where/what are those things. Just like when it's cloudy in the daytime, you can tell there exists a light source in the sky, but is that the Sun? The moon? Or a giant light bulb? You have to confirm it above the cloud.

If we use the photo example again, I can just give you another recursive photo taken elsewhere. You have no idea whether it was taken in the park unless you know the full view of the park. Namely, you sync from the genesis to get a full view.

Summary

Mina is an excellent brand new paradigm of blockchain design that utilises ZKP. It's innovative enough to have its position in the fame hall of the industry. But:

• 22Kb constant size blockchain is only about marketing.
• One block to verify the entire blockchain is incorrect.

Things are better when they remain true and plain.

Another Interesting POV

I give you 1998 boxes and claim that 1000 boxes among them can form a valid Mina chain. However, you only know the detail about Block Genesis and Latest 999, including the recursive ZKP proof in 999. Can you tell me, which other 998 boxes should be the correct blocks and their arrangement, i.e., show me the right path and history?

Ofc you can't. Or it just violates the information theory - your recursive ZKP is not an infinite compression algo. This is also true for the 22Kb constant size topic.