Mina Whiteboard Session TL;DR

TL;DR of the TL;DR

Mina is unique in the blockchain space. It is the only blockchain built using recursive zero knowledge proofs from top to bottom. This means that rather than replaying the entire history of the chain, we just have to check the proofs of the different parts of the blockchain instead. And thanks to recursion, it’s not ‘proofs’; it’s a singular ‘proof.’ Mina’s ‘Proof of Everything’ combines all previous proofs together, attesting to everything that has ever happened on the chain, including block production, consensus, transactions, and zkApps, in a single proof. This unique architecture means anyone on any device can verify the chain. 

Read on to find out how Mina is infinitely scalable without decentralization tradeoffs. This blog dives into the technical details that allow Mina to distribute data and parallelize proving, all while never growing resource requirements for network validation. This is a new paradigm.

Recursive Zero Knowledge Proofs

Zero knowledge proofs (ZKPs) are a way to prove that something (any computation) is valid without revealing any details about it. Now, on the face of it, they don’t sound super interesting, but what they can enable sort of blows my mind!

Blockchains can be broken down into components, essentially computations, including block production, consensus, transactions, and everything else! Since they are all just computations, each element can be proven using a ZKP. 

To understand how significant this is in the context of the blockchain architecture landscape, we can compare it with Ethereum. All of the blockchain data must be copied on Ethereum, as new nodes on the network require the chain’s history to verify the network. With Mina, rather than requiring the history of the entire chain (which causes HUGE scalability and centralization issues), people only need to check the zero knowledge proof. 

Mina takes this one step further and uses recursion to combine these ZKPs to prove the different parts of the blockchain into a single proof, Mina’s ‘Proof of Everything.’ In a sense, Mina is just one big rollup. Transactions on Mina are rolled up into Mina’s state transition machine (STM) proofs, which are then rolled up into the final blockchain proof. 

Once everything has been rolled up into a final blockchain proof, we need to use recursion to merge the old blockchain proof with the new one. How does this recursion work? Rather than revalidating the entire sequence of blocks every time a new block is created, Mina tweaks the proof statement slightly. Instead, we prove that there was a valid proof for the previous sequence of blocks and that there is a new extra one that is also valid. In other words, whenever a new block is created and broadcast throughout the network, we extend the proof to support this additional block.

ZKPs make blockchains more efficient by proving that computations were computed correctly so others don’t have to redo the work. This is a substantial improvement on how most blockchains operate. Watch this video from Co-Founder Evan speaking about ZKPs if you would like to learn more. 

Proving all at the same time!

Now that we have some basics down, we will dive a little deeper into how Mina’s architecture allows it to be so efficient and why it is built to be infinitely scalable. Above, we have simply said that all transactions are rolled up into the STM, which is then rolled up into the blockchain proof. But how does this work?

On Mina, because we use zero knowledge proofs, we must first prove transactions before they can be rolled up. Proving so many transactions can take time, and we want consensus to be as lightweight as possible. We also want to ensure consensus does not wait for the transactions. How do we get around this? Mina uses parallelization. 

In simple terms, parallelization involves completing all the proving all at once. However, there is a problem with this. Remember that the goal is to end up with one transaction proof to roll into the STM proof.

Imagine we have four transactions needing proofs (see diagram above). We can take these transactions and create proof for each one without issues. Next, however, we need to take those four proofs and combine them. We start with the first two, combine them, and create a new proof that attests to transactions 1 and 2. We then take the other two transactions and create a proof that attests to transactions 3 and 4. Finally, we then take these two transactions and combine them as well, so we are left with a proof that attests to all four transaction proofs in the tree. 

The problem with the above model is that there are four transactions to prove at the bottom, two at the middle, and only one at the top. If the network operated like this, there would be inconsistent work for the network nodes. To get around this, we parallelize the work by having the entire network working on many trees at once. All the layers are merged together to form a fixed queue of work to keep the maximum amount of parallel work, saturating the network constantly over time.  

How can all of these layers work at the same time? We use a slight delay in the network to help deal with this issue and introduce two ledgers. 

How do we use the two ledgers? The first ledger is where the block producers sequence and commit transactions (this would represent transactions from block A, for instance), and the second is where the transactions are proven a few blocks later (and so this would represent transactions from block C). 

Thanks to Mina’s unique design proving takes minutes, not hours  (and soon seconds) and so parallelization allows us to create a super efficient network without all the tradeoffs Vitalik mentioned in his infamous zkEVM blog. 

The World’s First Decentralized Proving Marketplace – The Snarketplace

There is one more thing we should touch on regarding the points above: who proves all of this computation on the network?

In the ZK space, people often talk about Decentralized Proving Marketplaces as a challenge because of the complexities around ZKPs and the tradeoffs other platforms make around scalability and decentralization. But for Mina, this problem has already been solved. o1Labs created the World’s First Decentralized Proving Marketplace, and it’s been running since Mina’s Mainnet launch in 2021! 

It’s exactly what it sounds like a marketplace for people to create ZKPs for a set of transactions using recursion. There is an economic incentive for people to provide this service to the network as block producers get paid 720MINA per block, and they MUST include these zkSNARK proofs in each block. Therefore, block producers will pay for this work or will sometimes run their own SNARK workers to ensure they have a valid ZKP for block production. 

Watch this <<video on the snarketplace>> from o1Labs CEO Brandon Kase.

The Infinitely Scalable Blockchain

Before discussing why Mina is INFINITELY scalable, you should understand Big O Notation but don’t worry—it’s easier to understand than it sounds. 

Big O Notation

Big O notation describes how operations scale. For instance, O(n) means the cost/time scales linearly with the amount of data, while O(1) means the cost/time remains constant regardless of data size.

Scaling Ethereum vs Mina

Now that we know big O notation let’s look at how Mina scales compared to Ethereum.

As you can see above, the only thing that scales with usage on Mina is the account size; everything else is constant. 

Mina is the only blockchain in the world that scales like this. It is infinitely scalable without any decentralization tradeoffs. 

The only thing that scales related to usage is accounts on Mina. This is by far the most favorable way to scale. Blocks and transactions grow at a far faster rate. To give you an idea of what this means, even if Mina had tens of millions of accounts (Mina has over 300,000 accounts today), the total ledger would only be a few gigabytes for full nodes. Everyone else can still verify the network using just a 22kb proof! Mina is future-proof like no other cryptocurrency on the market today. Ethereum would like to become more like Mina on its 10-year roadmap (image below). Mina was built like this from day one and has never compromised on the design. We believe in Mina’s principles and have stuck by them.

Proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs of proofs on a zkVM pic.twitter.com/4ryeyyHmxo

— Joe / Osprey (@0x_Osprey) July 22, 2023

Strongest Chain + Some More

Next up, let’s dive into Mina’s consensus mechanism. Mina Protocol uses the Ouroboros consensus mechanism from Cardano, which is a Nakamoto-based proof of stake (PoS) consensus mechanism. Traditionally, Nakamoto-based consensus was used predominantly in proof of work (PoW) systems as creating the longest chain in the PoW setting is hugely computationally expensive–which meant the economics of attempting such an attack simply don’t make it worthwhile. 

PoS systems, on the other hand, have traditionally used Byzantine fault tolerance (BFT) systems using stake-slashing to incentivize people to operate as honest actors on the network. However, BFT is unsuitable when using ZKPs as you cannot prove a negative. In other words, proving dishonest network behavior using ZKPs is impossible. 

So, how does Ouroboros work? Ouroboros works by inheriting properties from the Nakamoto consensus, predominantly the longest chain rule, and then adding density metrics to help further identify the strongest chain. Strongest chain, not longest chain. 

Mina took this one step further and adopted it for the succinct setting. We call this Ouroboros Samisika. The engineering team at o1Labs added minimum window density, which uses a binary selection rule. It’s basically a clever math trick that lets you quickly see which block is stronger based on the minimum window density; there is no ambiguity. Everyone can easily select the strongest chain. 

Plus, new full consensus nodes joining the network asking for the best block don’t require 51% of the network to act honestly. They only need one actor to act honestly as people can quickly identify that that is the best one compared with the others.

How Do zkApps Work?

So, we’ve discussed Mina’s inner workings. Now, we will discuss how zkApps fit into the Mina architecture. 

We know from the previous sections that transaction proofs are rolled up into the STM proofs, which are then rolled up into the block proofs. zkApps add another layer to this: zkApp proofs are rolled up into transaction proofs. In other words, zkApps are an extension of Mina’s rolled-up state.

But How Does this Work Off-Chain?

Enabling zkApps to run off-chain presents a considerable challenge; suddenly, you run into significant concurrency issues. Imagine a bunch of people editing the same word-processing document separately offline, and then they all try to send those offline changes back to a server (e.g. Google Docs) at the same time. Some of the changes different people make will conflict, so you can’t apply all of them. This is the same with blockchains; we want off-chain execution to scale the chain, but we must ensure we don’t have concurrency issues.

Other blockchains run computations on a chain where all network nodes must have access to all the data like Ethereum, enabling execution and sequencing to happen in the same step, but as a result, run into significant issues with scalability, fees, and accessibility concerns.  

With Mina, the engineering team at o1Labs has designed a much more efficient way of creating zkApps using actions and reducers. This makes Mina’s zkApps private, super scalable, and decentralized, all without gas or storage costs. People can use their sensitive or personal data privately on their devices.

Dealing with Concurrency

Actions and reducers are patterns used in your zkApp to interact with the decentralized sequencing provided by Mina. By using the action and reducer pattern, you can reinstate sequencing in your off-chain data.  

They allow your zkApp to add transactions to a list to get sequenced and processed later. By allowing the Mina blockchain to sequence actions into a list before reducing, you don’t get the same concurrency issues you would if you just let people submit their transactions in the hope the state they were relying on doesn’t change before their transaction is added to a new block. 

Another interesting property of actions and reducers is native censorship resistance, as actions are posted directly to the L1. Other chains can get this, too, but it’s not out of the box like it is on Mina. 

One Mina ecosystem project: zkNoid has recently written a blog on actions and reducers if you would like to dive further into how they work.

Mina–In a World of its Own!

Mina is in a class of its own as the only permissionless and distributed system on the planet.

Let us explain. 

First up, let’s compare the permissioned space. 

Permissioned Replicated

Examples: MySQL and web pages

MySQL is a fully permissioned database. You are granted permission by a central entity to access the database. 

Traditional MySQL clusters (ones not using sharding) are replicated; all of the servers in the MySQL cluster hold a copy of the entire database. Requiring all servers to keep all the data makes scaling the network more difficult and expensive. 

For example, if a MySQL database has 10,000 terabytes of data, then each server running in a non-sharded MySQL cluster will also need to have that same 10,000 terabytes of data.

Permissioned Distributed

Examples: BigTable and Web Servers

Web servers are a great example of permissioned distributed systems. They are still permissioned; however, instead of requiring each server to hold a copy of all the data, each server only has a fragment. For the user, this means that you will often be querying different servers for different parts of the data. For the data providers, the system can scale much more efficiently because the storage requirements are much lower, as they only store part of the data, and the data is distributed. 

For example, if BigTable has 10,000 terabytes of data, then each server can hold just a proportion of the data (e.g.10 terabytes). This gives you more flexibility and efficiency when scaling a system. 

Next, let’s look at the permissionless space. Enter blockchain!

Permissionless Replicated

Example: Ethereum (and most blockchains)

As we know, Ethereum is permissionless. It is a decentralized protocol that anyone can join, but Ethereum uses replicated data. The network operates by replicating all of the data (keeping it all available on the network) so that nodes can check to ensure the computation has been performed correctly. Keeping all of this historical data is what helps to secure the network. 

The problem with this model is that it makes it very difficult to scale. In trying to scale Ethereum, the Ethereum Foundation has had to relax the permissionless model slightly. Scaling methods such as sharding make Ethereum slightly less permissionless. In a sense, Ethereum moves towards the permissioned axis rather than the permissionless axis while it scales the blockchain. 

Permissionless Distributed

Mina Protocol is the only fully permissioned and decentralized system. 

While Ethereum struggles to scale with its replicated data model, Mina was built to be infinitely scalable and super decentralized from day one. Mina has used the full benefits of ZKPs to create a succinct blockchain that enables privately distributed data and computation that is accessible and decentralized. Mina is so accessible that anyone on any device can join the chain and verify the Mina state in minutes. To do the same on Ethereum would take days with a very powerful (and expensive!) computer.  

Importantly, Mina is also future-proofed in this model; Mina’s state will always be easily verifiable. Mina was built using the early lessons from crypto to ensure that scalability and decentralization were not compromised at any cost. 

What about other off-chain ZK projects?

Can other ZK projects achieve the distribution of data using off-chain computation? This is only part of the story. Take Aleo, another ZK L1: while distributing computation via off-chain computation, they must replicate all of their proofs. 

Aleo does not use recursion to prove all of their proofs down to a single proof. Therefore, they have to keep all of their proofs around for people to recheck, just like Ethereum. So, while they are halfway there to having distributed data, we believe they are missing out on the true power of ZK.

What Does All of This Mean?

Mina’s ENTIRE architecture has been painstakingly designed to provide absolute scalability and decentralization. No trust assumptions have been relaxed to achieve these goals. 

There is still work to be done to prove that Mina is truly scalable, and o1Labs is working on this in the form of performance improvements (such as shortening block time down from 4 minutes) and primitives like folding. Still, all the foundational work is in place to ensure Mina can scale without compromising decentralization. 

In addition to performance improvements, the Mina Foundation is finishing work on the web node to ensure anyone can run a Mina node on their phone or in the browser, further increasing Mina Protocol’s decentralized nature. On the infrastructure side, MF is also ensuring Protokit is ready to unlock easy development for all Solidity developers. 

Plus, work is progressing quickly on the o1Labs’ side with SDK improvements to ensure that o1js is as performant as possible and enables developers to build easily and at scale. 

Mina’s vision is to create a truly decentralized and distributed world computer that is accessible to all and allows people to work privately off-chain and collaboratively in a secure manner. 

The cogs are moving, the groundwork is in place, and Mina will provide the perfect infrastructure for the verifiable internet. Httpz is the vision, and we are closer than you might think.

Resources 

So what to do next? You might be ready for the full whiteboard session video or learn more about:

• ZK Proofs Explained
• Consensus Mechanisms
  • Ouroboros Samisika
• Actions and Reducers
• Mina’s Snarketplace
• The Verified Internet (Httpz)
• zkApps
• Mina Docs

If you find this helpful, tell and tweet @MinaProtocol. 

Disclaimer: This blog is based on a transcript from a whiteboard session organized by o1 Labs.