[Info] Ways/plans to achieve higher throughput on Mina

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

11 Likes

Thanks to @Trivo for comments on the post. @Brett @joseandro @evan @o1-jason @o1bijan @bkase please could you comment/add info, so that the community can be informed. Thanks a lot in advance.

3 Likes

Thanks @lamps I really like your organized thoughts here!

The cool thing with Mina is that we have a few levers to pull to improve TPS, like you mention, both: the L1 itself + a number of variations of rollups using snapps.

I’m personally really excited about getting snapps launched so we (both O1 and others in the community) can all explore the huge potential rollups offer. I would not be surprised if we see others in the community create really cool projects in this area, and am looking forward to it! Rollups seem like the ideal opportunity for Mina (given it’s built on zk-SNARKs) for potential exponential improvements in effective overall TPS.

Re: L1 TPS improvements. Although I’m not the best person to comment on L1 TPS improvements–since my role focuses on snapps currently–I confidently expect we’ll continue to see improvements in L1 TPS as Mina snarks become even more performant & other optimizations are implemented. I know O1’s crypto team is doing some really cool work, like Kimchi, and the larger snark community keeps doing amazing work too, so this will be exciting area as well.

3 Likes

Thanks for that post! I think this is a great discussion.

1-> IMO it makes sense to improve the consensus protocol of Mina at some point: it is the bottleneck for finality, and throughput still needs to be good even if you have L2 solutions. Even if you have good L2 solutions, you still need to move you funds there, or withdraw if you want to use other snapps. That being said, Mina is innovating on the zk side at the moment (and the space is moving rapidly), the competition around tps is quite crowded, does it make sense to invest effort now? I think a move to a BFT consensus protocol makes the most sense but it doesn’t strike me as the most urgent.

2 → per-account rollups sounds like it would mostly be helpful for exchanges right?

3 → I’m not versed in how dydx works, but if they provide better finality it sounds like a sidechain to me (similar to polygon). So essentially isn’t it the same as 4? I think starknet is an interesting solution to look at. IIUC it works like a normal network (albeit no consensus) and rollups are the proofs that execution went correctly. It gives more flexibility to snapps, and increases throughput due to untrusted centralization.

4 → I like the idea of having a tendermint-based as a sidechain (easy bridge to cosmos!), but I’m wondering what the benefits are compared to bridging mina with the cosmos hub (for example) using something like axelar. At this point the sidechain can be another crypto no?

1 Like

Thanks for your comments. My understanding is:

1.> I agree mostly with zk innovation and tps, but I think a move to a BFT consensus would massively improve UX.

2-> It will currently benefit block producers and exchanges, essentially accounts that have to make a lot of txns on the base layer; bear in mind all snapps will be accounts on the base layer too.

3-> DYDX is based on StarkEx, kind of like a DEX-specific version of StarkNet; it’s not a sidechain - the improved finality comes from DYDX taking risks on user’s funds, not from a further consensus.

4-> I would not call that a sidechain but it will depend on the actual implementation.

I think at this stage it is important to clearly seperate TPS and finality. I regularly see people (not in this thread, but rather the wider community) talk about the need for faster TPS (100 TPS, 400 TPS, 1000 TPS), while I think they are confusing what TPS actually means.

Mina is doing totally fine with 1 TPS currently, in fact, Mina is currently only hitting a maximum of ~7100 transactions per day realistically, according to Minaexplorer and I don’t think the network will come anywhere close to maxing out that 1 TPS soon, even with the launch of Snapps, and especially not with per-account rollups that should help decrease transactions for exchanges or payout transactions of larger staking pools.

What actually worries me is finality and the size of forks. I think instead of focusing the maximum throughput (which pretty much are TPS), the team should focus on finality and block time. Having large blocks that end up with 1000 TPS won’t help the network increase its performance if we still have slot times of 4min or a finality with 15 blocks - not to mention forks of the size of up to 8 blocks. Naturally, decreasing slot time or improving finality will also end up with a slight TPS increase. However, I think it is important to focus on finality instead of hitting that x-thound TPS that will not get filled anytime soon anyway

4 Likes

That makes sense to me, but you don’t know when tps will become a bottleneck for the users, and you want to prepare some buffer for working on transition to a solution. Also, a BFT protocol would provide instant finality, no forks, and better throughput all together so it’s a win win win :slight_smile:

1 Like

Maybe we can put forward an MIP to suggest that some resources should be directed to finality research and engineering? Just a thought - maybe after the hardfork?

2 Likes

I’ll do some more research about different options that should help increase finality and then I will open a a new thread where the community can disucss the importance and impact of (near)-instant finality more

4 Likes

wonderful! looking forward to it!

1 Like

I haven’t asked around to see if anyone has experimented with it, but the idea of using FPGAs or GPUs to improve snark work performance and finality has popped up a few times for me recently. I’m not sure the juice is worth the squeeze but hardware accelerated snark work is an intriguing idea. Matter Labs did some work and published this blog post on the topic: World’s first practical hardware for zero-knowledge proofs acceleration | by Alex Gluchowski | Matter Labs

there was a reasonably deep discussion on Discord a couple of months ago: Discord, but I don’t think that will help improve finality much.

1 Like