What is Mina Protocol?

This article will cover Mina protocol starting from a high level overview for general understanding purposes, moving on into Mina’s architecture on how it works, and some cryptography terminologies.

Mina protocol: In layman terms

Mina is a Layer-1 blockchain that is able to maintain minimal size no matter how large the transaction history or volume becomes. In order to make a blockchain (or anything else in general) as light as possible, the first intuition is to carry lesser things, or just the essentials are enough.

Let's use an example of a traveller. In other blockchains, to prove that the traveller has been to a place, a souvenir must be bought from the locals as verification. This means the traveller needs the effort and money to find a souvenir shop every time he visited a new place. The more places the traveller visits, the heavier the bag full of souvenirs will accumulate.

In Mina, the traveller simply needs to prove that he has been to a place by simply taking a photo of a landmark of the place. As long the traveller can prove that he has visited a place (like taking a photo with a landmark), he need not buy a physical souvenir. Knowing this, the traveller took the next step to take new photos with the previous photo holding in hand, making it consistently a single photo for proof.

An example of a picture would look like this:

Architecture of Mina

We have established that Mina is a blockchain that is able to maintain minimal size no matter how large the transaction history or volume becomes. To elaborate, Mina is able to compress a chain of transactions into one single dataset, a proof…within a proof…that is within a proof… making it consistently 22kb.

Let us break down the process of getting that sweet 22-kb size. To maintain a constant block size, we need to make sure that all proofs are Valid. Therefore, we would require a system where ONLY the proofs that are validated are ‘allowed’ to be stacked on a pending proof prior to being validated repeatedly, to achieve a “compressed” dataset.

Mina presents the recursive SNARK system, a system that allows one SNARK to verify other SNARKs, creating multiple proofs to be aggregated into one single block proof, only then to get submitted to the mainnet.

Aggregation- Multiple proofs can be aggregated into a single proof. The single proof will be valid if all constituent proofs are valid, and only then it will be added to the blockchain. As taxing as it seems, due to the blockchain's recursive architecture, proofs can be generated in parallel and since all SNARKS are independent, the overall proof time is being cut short.

How Mina Validate Transactions in the Blockchain

Here are 3 key points to tackle for Mina to maintain a minimal size:

1. An easily verified proof that takes up minimum space for each transaction

2. The efficient way to verify the succinct proof

3. Ensure the blockchain size remains the same. (How to prevent linear growth? Are old data discarded?)

For reference, here is a lifecycle infographic of Mina:

Let us see how that converts to a simple transaction using words:

Kim wants to send Chen a number of coins via Mina protocol:

Step 1: Kim creates a payment

• The payment relays a transaction to the blockchain. A Verifier ensures that the transaction is valid and is within the ledger. if valid, the transaction will enter the mempool.

Step 2: Kim’s transaction is added to a new block

• Block Producers (BP) cherrypick which transaction goes into the block. If the transaction is more profitable, the a higher chance it will get chosen first.

Step 3: For each transaction, a corresponding SNARK needs to be added by the BP

• This is a crucial part, before transactions are added to the new block, the block producer must add a corresponding snark.

Step 4: BP buys the SNARK from the ‘snarketplace’

• Snarkers compete to provide the ‘best deal’ of SNARK for BP. This creates a marketplace that incentivizes minimal fees.

Step 5: the corresponding SNARKs for each transaction are approved and added to the blockchain. The updated blockchain then maintains a constant size.

• Here's where the recursive ZK Snarks comes to play. To avoid SNARKs piling up the blockchain and resulting in linear growth, we group all the SNARKs down to a single SNARK.

The idea is that If all transactions are proofed and verified, we could create a ‘SNARK of all SNARKs’ that proves the entire history of the blockchain is valid while remaining the size of a single certificate.

Experiencing with Mina Protocol

The onboarding process for Mina doesn't seem quite complicated. First of all, the token withdrawal transition from Binance to Aura Wallet takes around 4 minutes, which is considered quite standard for a typical Blockchain.

For starters, you can track your transaction ID via MinaScan, a useful tool to navigate and track chain activities on MinaScan.

For Projects and ZK dApps onboarding, the firsthand experience seems to be quite empty, as expected due to the protocol being new. However, there are dApps that you can still try out, and one project named Berkeley Testnet WIP is quite interesting where you can create proof that you know the answer to a maths question.

Other than experimental dApps, it is clear that nothing much is happening on-chain. This could also contribute to the fact that DEXs and Lending protocols are not yet deployed on the mainnet, which those two have historically generated more momentum as seen in other blockchains.

It can be observed that the Mina Protocol is currently trying to onboard many projects as possible, as evidenced by the constant tooling updates and the advocation of new projects happening.

Where is Mina heading?

Let’s ask ourselves a question, what do we look at when interacting with a new blockchain

1. What is Mina Blockchain tackling?

2. Are there any good projects?

3. How scalable is the blockchain

4. Does it have the incentive to maintain?

5. Is the development positive?

Let us take a look at the roadmap and development:

So far, Mina has put special emphasis on buidlers experience and tooling. To elaborate, Mina has frequently conducted builder programs, provide up-to-date easy-to-access documentation and enhance the programming experience. At the moment, there are 28 experimental Dapps but most are still in the making progress.

Mina’s priority list (top-down):

1. Building an environment for builders to onboard and start building projects.

2. Breakthrough advocates for nodes/validators/block producers to maintain the project in a much more scalable way compared to other projects.

3. The least priority is placed on the efficiency and speed of the blockchain, maybe not be important at the moment. Another devil’s advocate is whether some information should be neglected. What happens when the blockchain goes wrong? What do we refer to?

   The Mina archive nodes solved the documentation issue, but what if the archive scan becomes more prominent and relevant than the zero-knowledge snark on the mainnet blockchain? Is the computing efforts of creating a concise blockchain too much of an overkill?

Here are some pointers to reflect and think about:

1. What is blockchain tackling?

   • A blockchain that maintains a constant size for better scalability and is easy to maintain.

2. Are there any notable projects?

   • Not at the moment, Dapps had some potential use cases, but most are still experimental. Probably due to not many people being exposed and knowing about ZK.

3. How scalable is the blockchain?

   • Might be notice at the moment but may be a problem when the network becomes busy. The excess time taken for the computational power of Snarks may be an unintended consequence that hinders scalability.

4. Does it have the incentive to maintain?

   • Nodes and verifiers are designed to be user-friendly as they do need not computers with high-end computational power and large amounts of space.

5. Is the development positive?

   • In the progress of getting traction for builders to work on the project at the moment.