I’m Yihang, an Engineer at o1Labs, and I’m happy to introduce a new o1Labs MIP for the Mesa Upgrade!
This MIP proposes to increase the current limit on the number of account updates that can be included in a zkApp transaction. The proposed change aims to enhance the expressiveness and utility of zkApps by allowing developers to create more complex applications that require a higher number of simultaneous account updates while maintaining the protocol’s performance guarantees.
You can read and comment on the full technical MIP on Github and we’ll be engaging here with any questions or comments you have about the proposal and the process.
What’s Changing?
Right now, Mina’s zkApps can only make a limited number of updates in one go (10 or fewer). This rule was set to keep things fast and lightweight.
This proposal would raise that limit to about 3X more updates per transaction.
Why Does This Matter?
More powerful apps: Developers can build zkApps that handle more complex operations in a single step instead of splitting them up.
Better user experience: Today, users often “have to approve” on several separate transactions to get one thing done. After this change, it could be just one approval.
Lower costs: Since you need fewer transactions, you pay fewer fees.
New possibilities: Features like handling many payments at once, or contracts that check numerous accounts in a single operation, become possible.
How YOU Can Get Involved:
We are eager to hear your thoughts, feedback, and suggestions on this MIP.
This will greatly improve the ability to bulk send payout transactions if done as account updates. Given would be able to fit 30 signed account updates into a tx and assuming the limit on zkApps per block is removed (so can fit 125 zkApp tx per block) is 30x125=3750 account updates per block. That means even the largest pools could complete payouts in a few blocks if all blocks were full.
Could you check on the rationale section in this MIP?
In short, we redesign the SNARK worker architecture, now all account update proofs are generated in parallel, so the latency of generating a SNARK is only proportional to the tree height. Given merging account update is associative, we are able to heuristically ensure that the tree structure to form a balanced binary tree. This implies that the tree height would be proportional to the log of number of account updates we have. Hence, tripling the limit means latency would be increased by a constant compared to new architecture with old limit.
The new architecture + new limit configuration would still be expected to out perform old architecture + old limit, BTW.
This MIP has been moved to Last Call stage. This means we have 2 more weeks to discuss or bring up concerns before it’s considered finalized and ready for on-chain voting.
As of Oct 29, this MIP has completed community discussion and is now in the Finalization stage. That means all feedback so far has been addressed, consensus is positive, and the proposal is ready for inclusion in the upcoming hard fork, pending the community’s on-chain vote.
However, further discussion is always welcome and encouraged. It just won’t influence readiness for the OCV process, unless something critical comes up.
This MIP has been moved to 
As of Oct 29, this MIP has completed community discussion and is now in the Finalization stage. That means all feedback so far has been addressed, consensus is positive, and the proposal is ready for inclusion in the upcoming hard fork, pending the community’s on-chain vote.