MIP9: Increase zkApp Account Update Limit

MIPS/mip-0009-increase-zkapp-account-update-limit.md

@@ -0,0 +1,110 @@
+---
+mip: MIP9
+title: Increase zkApp Account Update Limit
+description: This MIP triples the zkApp account update limit with a new simple rule (np + n2 + n1 ≤ 16), requiring a hard fork and enabling more complex, efficient zkApps.
+authors: Yihang Liu <corvo@o1labs.org>
+discussions-to: https://forums.minaprotocol.com/t/increase-zkapp-account-update-limit/6965
+status: Review
+type: Meta
+category: Core
+created: 2025-09-04
+---
+
+## Abstract
+
+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.
+
+## Motivation
+
+The Mina Protocol currently limits zkApp transactions to a maximum of 10 signature-based account updates or 5 proof-based account updates per transaction. While these limits were initially established to ensure low impact on performance, they have become increasingly restrictive as zkApp development progressed.
+
+This limitation creates the following problems:
+
+1. **Development Constraints**: Developers are forced to split complex logic across multiple transactions, increasing complexity and limiting capabilities
+2. **Technical Complexity on User Experience:** End users must approve multiple transactions to complete what is logically a single operation.
+3. **Increased Cost**: As a result of 2, end users must pay extra fee on transactions, as fee grows linearly with the number of transactions. 
+
+By increasing these limits, we can enable more sophisticated zkApps that better serve user needs while maintaining Mina’s commitment to succinct blockchain architecture. Examples of applications that this MIP will enable can be found in the Appendix.
+
+## Specification
+
+### Prerequisites
+
+- **[SNARK worker optimization](https://github.com/MinaProtocol/MIPs/blob/georgeee/mip-0006-slot-reduction-90s/MIPS/mip-0006-slot-reduction-90s.md#snark-worker-optimization) from the Slot reduction MIP**: The optimization for proof-level parallelization (instead of command-level) must be deployed and tested on CI, devnet and mainnet before the hardfork. This ensures SNARK workers can efficiently process individual proofs within a proof tree, enabling the expected latency improvements.
+
+### Modifications
+
+Below are the modifications needed to implement this change: 
+
+- **On Mina node’s end:**
+    - Currently, a zkApp command is considered valid if and only if: $10.26np + 10.08n2 + 9.14*n1 < 69.45$, where $np$ is the number of single proof updates, $n2$ is the number of pairs of signed/no-auth updates, and  $n1$ is the number of single signed/no-auth updates.
+    - In `Zkapp_command.zkapp_cost` , the old formula should be replaced with a new formula $np + n2 + n1 \le 16$. This formula in effect allows any balanced binary proof tree of height 4, and roughly triples the account update limits.
+- **On o1js’s end:**
+    - The exact cost limit formula is also tracked as a soft limit at o1js’s end. Mina node is not aware of o1js and would simply drop any zkApp transaction that exceeds the limit. That old formula should be replaced by the new one to reflect the new limit in o1js as well.
+
+## Rationale
+
+The reason to use a new formula, replacing the old formula and modifying the parameters, is that:
+
+- The old formula was generated based on benchmarking data with linear least squares (see this comment https://github.com/MinaProtocol/mina/blob/28a06cb80c857b0215026e752bd2c9797534af71/src/lib/node_config/unconfigurable_constants/node_config_unconfigurable_constants.ml#L3 in Github). These coefficients are approximately equal, effectively restricting commands to at most 7 segments. Furthermore, this old formula becomes especially restrictive when there are many proof segments, unfairly rejecting some zkApp command combinations that have similar processing times to allowed ones.
+- In the new SNARK worker architecture, latency is decided by the depth of proof trees. Hence, the previous latency estimation is rendered irrelevant. This is due to the fact that latency is decided by the cost of the most expensive path from proof tree root to any leaf, where cost is defined by summing up latency for each intermediate proof on each node encountered during this path.
+- The new formula is simpler, and gives us precise control of what the proof tree looks like.
+
+## Backwards Compatibility
+
+This MIP is not backward compatible. Blocks generated by nodes after implementing this MIP would be rejected by old nodes. Hence, a hard fork is needed. 
+
+
+## Test Cases
+
+Generate a list of zkApp commands having invalid zkApp account update size according to old formula, while being valid under the new formula, send them to the network, and see if these commands are accepted. For example, we may generate:
+
+- A transaction with 15 proof-based account updates and a fee payer update.
+- A transaction with 31 signed account updates, with a fee payer update.
+
+Additionally, run load testing network generating transactions with 31 signed account updates and ensure that the network can keep going for an extended period of time with blocks consistently containing `>100` transactions per block.
+
+## Reference Implementation
+
+Here are the constants to be modified: https://github.com/MinaProtocol/mina/blob/develop/src/lib/node_config/unconfigurable_constants/node_config_unconfigurable_constants.ml.
+
+For Mina, the implementation of this MIP can be found at https://github.com/MinaProtocol/mina/pull/17386.
+
+For o1js, the modification is similar and will be done in follow-up PRs.
+
+## Security Considerations
+
+Doubling the segment limit for zkApp commands has the following implications:
+
+- **Increased work:** The total effort required to prove a max-size zkApp command roughly triples. For proving, latency grows linearly with the tree height due to the new proof-parallelization architecture, hence it’s only a constant add.
+- **Greater sensitivity to network latency between SNARK coordinators and workers:** With the SNARK worker update, proof generation is divided into smaller jobs across more workers. As the number of segments increases, network latency may become a factor because more segment and merge jobs need to be coordinated. However, risk should be low as coordinators and workers are supposed to run in an intranet, or even on the same machine. So network latency should be negligible in most cases.
+
+## Appendix
+
+This section provides additional context relevant to the MIP.
+
+### zkApp Account Update Tree Structure
+
+A zkApp command's proving process follows a binary tree structure because Pickles can only merge two proofs at once. Leaf nodes contain independently provable segments, while intermediate nodes require merge proofs to validate their sub-trees. The merging process is associative, allowing reordering while preserving segment order. The final output is a single proof resulting from running the process on the whole tree structure.
+
+Each segment can be one of three kinds: a proof update, a single signed/no-auth update, or a pair of signed/no-auth updates. The structure of a zkApp command always requires a fee payer, which is a signed/no-auth update. With this MIP implemented, we can have at most 31 "real" signed/no-auth updates, forming 16 paired signed/no-auth segments in a max-cost zkApp command, where one pair is of a “real” signed/no-auth update and a fee payer update. Alternatively, we can have at most 15 proof updates, with the remaining slot occupied by a single or paired signed/no-auth update.
+
+### Application Examples
+
+This section provides examples of applications that would be enabled by the proposed changes.
+
+#### zkUSD integration with Fungible Token standard
+
+A design initially considered for integration of zkUSD with Mina's Fungible Token Standard was challenging due to account update limits that constrain the development of zkUSD’s domain logic. This update would allow zkApp transactions to interact with more accounts simultaneously, solving this issue.
+
+#### Academic Example: Array of Updates
+
+An application on Mina may process many updates of the same kind, e.g. user registrations or payments. Increased account update limits would proportionally increase the throughput of these types of apps. Imagine something like a liquid staked token contract that has a long queue of withdrawals to process. This MIP would enable them to increase the number of withdrawals processed per block from 5-10 to 15-30.
+
+#### Academic Example: Increased Contract Composition
+
+With the current limit of 5 proof-authorized account updates per transaction, developers are quite limited in how they compose different zkApp methods. For example, a reasonable pattern currently would be to check permissions with an admin contract as part of a transaction. With this upgrade, developers will be able to do far more. For instance, an oracle contract could reference the attestations of 10 different accounts and report the average. Reading the state of 10 different accounts in a single transaction currently would be impossible, so the MIP expands the possibilities of zkApp development on Mina.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).