This post is part of our roadmap series, diving deeper into the focus areas outlined in the o1Roadmap]. Each post explores how each Engineering team at o1Labs is pushing Mina forward by covering what we’ve delivered (recent milestones), what we’re building (current initiatives in progress), and what’s next (future priorities).
This is the first in the series and we’re thrilled to dive deeper into our plans for o1js and the zkApps platform. Over the next year, we’re focused on delivering a range of improvements, updates, and fixes to both o1js and the overall zkApps experience. These changes are designed to empower developers to build even more powerful and impactful applications on Mina.
Every item on our roadmap addresses a specific challenge or opportunity identified through your invaluable feedback. This blog reflects the voice of the Mina community and serves as a guide to what’s ahead. Let’s explore how these updates are shaping the future of zkApps and beyond.
What We’ve Delivered
o1js release v2
A few weeks ago, we unveiled o1js v2.0 - a major milestone in the evolution of our SDK. This release followed a comprehensive external audit and builds on the foundation established with v1.0 earlier this year, which was released alongside Mina's Berkeley hard fork. While v1.0 made zkApps production ready for mainnet, v2.0 takes it further, refining the SDK to be even more secure, reliable, and developer-friendly.
The focus of o1js v2.0 lies in enhancing the internal circuit structure, a core component of zkApps that transforms your application's logic into constraints - mathematical rules that underpin zero knowledge proofs. This release introduces changes to these circuits, addressing security and efficiency of some circuits. You can find more details about o1js v2.0 in one of our other blog posts!
What We’re Building
Dynamic Arrays and Runtime Tables
Runtime tables are a powerful tool for optimizing certain computations in zero knowledge circuits. Historically, working with arrays in o1js has been challenging - they required a static size, and developers often had to implement their own helper methods, making the process overwhelmingly tedious. Since arrays are a fundamental programming primitive, we decided to address this pain point by leveraging the existing runtime tables in Kimchi. By exposing this capability in o1js, we will introduce a dynamic array interface that is both intuitive and powerful. This improvement not only makes circuits more constraint-efficient but also significantly enhances the ergonomics of working with complex data structures in o1js. The result? A smoother, more enjoyable developer experience, coupled with increased functionality for zkApps. This is a big step forward for both usability and performance! Keep an eye out for a blog post that will go more in-depth.
Preconditions on Permissions
We’ll need to dive into some protocol changes in order to deliver Preconditions on Permissions. As the name suggests, this feature allows developers to set preconditions on the permissions of accounts.
With this update, developers can structure Account Updates more elegantly, make more precise statements about the accounts they interact with, and avoid issues like deadlocks in complex scenarios. While it may seem like a relatively small change, it’s a powerful enhancement and an important first step in a series of zkApp improvements.
This feature is designed for zkApp developers looking to build more complex applications while retaining full control over their logic and design. The implementation is nearly complete, and we plan to propose this improvement in an upcoming MIP.
zkProgram Improvements
zkProgram is one of our primary interfaces for working with zero knowledge circuits. By combining the strengths of Kimchi and Pickles, it empowers developers to create powerful recursive zero knowledge circuits. A new o1js smart contract API (explained below) will be built on top of this robust interface, ensuring that recursion can be leveraged to its fullest while providing the best possible developer experience.
To achieve this, we’ve been continuously improving zkProgram. Over the past few months, with invaluable contributions from the community, we’ve introduced a range of enhancements.
These include a cleaner and more intuitive API interface. And more powerful return types to handle complex logic, as well as the ability to witness proofs recursively, in-line, directly within another circuit. These updates not only simplify the developer experience but also lay the foundation for a more powerful and flexible API to interact with the zkApps platform. They represent another step forward in making zkApps easier to build and more capable than ever before.
EdDSA
In our ongoing effort to make o1js the most powerful and versatile zero knowledge DSL and SDK, we are constantly working to support a broader range of use cases. To do this, we need to integrate a wide variety of cryptographic primitives used in traditional cryptographic protocols, across other blockchains, and within the Web2 world. One of these important primitives is EdDSA. We already integrated EcDSA some time ago, thanks to the efficiency of our custom gates for foreign field arithmetic. To further expand our cryptographic capabilities and unlock more use cases, we've decided to update our existing implementation to also support EdDSA. This enhancement opens the door to a wealth of new and exciting use cases, integrations, and applications within both the o1js and Mina ecosystems, bringing even more power and flexibility to zkApps.
What’s Next
o1rs
Many of you have been eagerly awaiting this, and we’ve heard you! o1rs is the next product in our lineup, and we’re excited to be working on it right now. Much like o1js, o1rs will enable developers to write circuits and zkApps directly in Rust. Rust is a powerful, high-performance programming language widely used across the Web3 and blockchain space. With o1rs, you’ll soon be able to write your applications in Rust, bringing more flexibility and performance to your zkApp.
Native Prover
This is an exciting and much-requested feature! Currently, our entire backend is compiled to WASM. This has been incredibly handy, as WASM runs seamlessly in modern browsers and server environments like Node.js, and our stack - thanks to Kimchi being written in Rust - compiles nicely to it.
However, WASM comes with limitations. The most significant is its current memory cap of 4GB (though the Memory64 proposal is making good progress). This constraint makes it challenging to prove larger circuits in both browsers and server environments. Additionally, some of the arithmetic operations in o1js and Kimchi are less efficient when expressed in WASM, resulting in slightly slower performance compared to their native Rust equivalents. To address these issues, we’ve decided to enable native calls to the prover (Kimchi) on the server. This change will bring improved performance by leveraging native Rust implementations, new possibilities for circuit optimizations, such as chunking - which is already on our radar, as well as easier handling of larger computations and better support for developing complex circuits. We can’t wait to see how developers take advantage of it!
o1js new API
This update has been a hot topic at various workshops, including those in Istanbul and MinaCon a few months ago. The new API is designed to make interacting with the Mina Protocol easier while fully unlocking the potential of our zkApp platform. We realized some time ago that the current SmartContract API wasn’t the best abstraction for Mina’s Account Update model. This made it challenging for developers to grasp what it truly means to build a zkApp on Mina. Key concepts were overly abstracted, unclear, and didn’t showcase the full power of the Account Update transaction model. The new API changes that. Developers will now write zkApps in a more expressive and direct way, with complete control over all the involved Account Updates. This approach not only simplifies the process but also makes it much clearer how to fully leverage the Mina Protocol for its intended purpose. With the new API, zkApps will be easier to write, more powerful to use, and better aligned with Mina’s core vision of enabling the future of programmable cryptography and zkApps.
Preconditions on Permissions MIP
This update is a follow-up to the Preconditions on Permissions feature we discussed earlier in this blog post. Since Mina is a decentralized protocol governed by its community, implementing changes isn’t as simple as "just uploading a new release." Instead, we must propose these changes in a Mina Improvement Proposal (MIP) and allow the community to decide if they should be adopted on Mainnet. This involves drafting and presenting the proposal, gathering and integrating feedback from the community, initiating a vote, and, if approved, including the feature in the next hard fork release. This collaborative process ensures that every improvement aligns with the community’s vision while continuing to strengthen the protocol. We’re excited to start this journey and look forward to seeing how the community likes this feature!
Circuit Performance Improvements
Chunking - that’s the key here. We’ve discussed this many times in the past, but until now, increasing circuit sizes (the number of constraints in a zkApp) wasn’t feasible due to technical limitations. The primary obstacle has been the memory cap of 4GB imposed by WASM, which we use for our proving stack. As mentioned in the Native Prover section, introducing a native prover interface on the server now paves the way for us to finally release an initial version of chunking. Looking ahead, we plan to further address these limitations by rewriting chunking to be more memory efficient, which could eventually allow larger circuits to be compiled and proven directly within the browser. This breakthrough can unlock a wide range of new and exciting use cases, from complex zkML models and advanced cryptographic protocols to verifiers of other proof systems - all seamlessly integrated into o1js and Mina.
Historic Preconditions
Historic Preconditions will allow developers to set preconditions of the Mina chain’s historical state. This means that zkApps will finally be able to make statements about fast-moving parts of the protocol, from using VRFs (Verifiable Random Functions) to access chain randomness, to assertions about the full merkle tree even as transactions move it forwards. Similar to Preconditions on Permissions, this is another significant step toward making Mina Protocol the most powerful zkApp platform available. By enabling more complex applications and unlocking new use cases, this feature brings us closer to our vision of zkApps becoming the most powerful primitive in Web3. It’s a major milestone that will require additional planning, so stay tuned for a more detailed blog post diving deeper into this exciting development!
Last, but not least
While this roadmap highlights the major projects we’re focusing on, it’s important to note that o1js is continuously evolving. Alongside these larger initiatives, we’re actively working on numerous smaller improvements and changes to enhance the framework. These ongoing updates are just as crucial in ensuring a seamless and efficient experience for developers.
We’d love to hear your thoughts! Join us on Discord and share your feedback, ideas, or questions. Your input helps shape the future of o1js and the zkApp platform. Let’s build together!