Due to limitations and time constraints related to zk snarks computations, currently the Mina blockchain has relatively low throughtput with ~0.5 TPS, and ~1hr finality time. There have been a lot of questions in the community about improving the throughputs. This post is a simple summary of scaling options that I’m aware of, and hopefully it can inform the community too. Of course, any corrections/additions/suggestions are most welcome, and please comment directly below.
[1]. Increase TPS and achieve instant finality at the protocol level.
Evan mentioned in his keynote at the Chainsafe Conference in Dec 2021, that:
1). TPS could be increased at the protocol level by reducing block times and increasing the number of transactions that could be included to each block (ie block size). The required work to achieve these is mostly on engineering side, to improve snarks proving/verification and networking efficiencies, and boosters are coming in both aspects: Kimchi Snarks are supposed to be 2x more efficient to prove and 4x to verify, and Mina’s development of adapting bitswap as the networking layer is well on its way. Short term goal is to reduce block time from 3mins to 2mins, but could be even better.
2). Instant finality could be achieved by choosing a commitee to witness the block for consensus in a BFT configuration, instead of using just one block producer and relying on Nakatomo consensus on chain to reach probabilitic finality. The required change will be more substantial and will need protocol and consensus mechnism change.
Timeline: should be short term for TPS improvement, but TBD for finality.
[2]. Rollup at each account.
Thanks to Mina’s unique design where zk-snark proving and verification plays a key role, it is relatively easy, once Snapps are out, to roll up multiple transactions of an account (~200 lines of TypeScript codes can do the trick, see this example), so that these transactions are batched up and only the aggregated results are submitted onchain to be included in blocks. This should be able to 50x or 100x TPS, but it has no effect on finality. Note that this roll-up is different from the L2 rollup happening on Ethereum, since here it is happening on L1 locally at each account.
Timeline: Q1 2022, as soon as Snapps are released on Mainnet. Example codes are already available.
[3]. L2 scaling: DYDX model
L2 scaling is a vast design space, and again, due to Mina’s unique structure already involving zk-snarks, zk L2s can be easily constructed on top of it. As an example, to achieve high-performance DEX, the design philosophy of DYDX/StarkEx can be used: on the L2 DEX level, the finality is instant (caveat: not onchain yet), and the TPS can be in the thousands; however, the proof of the L2 computations are only submitted to L1 sporadically, and the onchain finality takes almost ~ 1hr - on par with Mina’s finality time. As a compromise, the DYDX protocol takes some risks about uncertainties of the user’s funds before finality. For more details, refer to Hasu’s podcast.
Timeline: can already be done with Mina’s current design, as soon as Snapps launch.
[4]. Fork Solana/Cosmos and use them as L2
This was brought up by the blog post 10 Snapps Use Cases on Mina Protocol as one of Snapp use cases. This approach could easily achieve a general-purpose L2, and obliterate the throughput discussions. Not sure whether this could already be done realistically, once a bi-directional Mina-Solana trustless bridge teased in Evan’s chat with Nil Foundation goes live?
Timeline: TBD
