Reflecting on 2024 - The Mopro Retrospective
It has been a remarkable year for the Mopro project. We’ve successfully transitioned from a proof of concept to a ready-to-use solution, attracting significant interest from various projects.
Here are the milestones we’ve achieved this year, along with key reflections on our journey.
Optimizing Developer Workflow
We streamlined the development process through significant codebase refactoring. By merging mopro-core and mopro-ffi into a single mopro-ffi folder and consolidating the iOS, Android, and web apps into a test-e2e folder, we reduced folder depth, making it easier for contributors to locate functions.
Additionally, we removed the circuits compilation and trusted setup processes, along with unused toolchain targets. These optimizations have drastically improved our CI workflow, reducing the peak runtime from around 1 hour to just 10 minutes (10 times faster)!
We also enhanced the Mopro CLI, significantly reducing the time required for setup and usage. As mentioned earlier, users no longer need to install unnecessary toolchains or download unused circuits from the Mopro repository.
Looking ahead to 2025, we plan to make the CLI even more accessible by providing precompiled binaries for download, eliminating the need for git clone during installation.
Users can now quickly clone the repository and build an iOS or Android project in just three commands—mopro init, mopro build, and mopro create—all within 3 minutes! For detailed instructions, check out the Getting Started section.
Enabling Multi-Platform Support
In addition to Swift for iOS and Kotlin for Android, we’ve now created templates for cross-platform frameworks like React Native and Flutter. The CLI has been updated to support these platforms, and the documentation has been refreshed to reflect these enhancements.
Please refer to the following resources:
Additionally, Mopro now supports WASM for web browsers. We provide wasm-bindgen for the Halo2 prover, enabling developers to use the Mopro CLI to generate website templates with bindings. This significantly reduces the time spent navigating the outdated Halo2 tutorial available at Using halo2 in WASM (It was authored in 2022).
Please refer to the following resources to learn how to use Mopro for building WASM applications for web browsers:
Expanding Compatibility with General Rust Functions
We realized that generating and verifying proofs alone isn’t sufficient for application developers. To address this, we made the Mopro template compatible with any Rust crate or function, allowing developer to extend the FFI interface directly through Rust code.
For instance, if a developer needs a Poseidon hash function but neither Swift nor Kotlin provides a Poseidon hash library, they can integrate a Rust Poseidon crate. First, they define the function API in Rust, such as:
#[uniffi::export]
pub fn poseidon(input: Vec<u8>) -> Vec<u8>{
// Poseidon hash implementation
}
By annotating your function with #[uniffi::export], UniFFI automatically declares the appropriate FFI type and generates the necessary bindings for Swift, Kotlin.
Once processed, the generated foreign language bindings expose your custom functions seamlessly. You can then call the Poseidon function in your Swift or Kotlin code as if it were a native API, enabling straightforward cross-language integration.
For more details on how UniFFI processes your Rust code to generate these bindings, please refer to the Uniffi - Procedural Macros.
By running mopro build again, the developer can generate Swift and/or Kotlin bindings for the Poseidon hash function. They can then easily call the function in Swift or Kotlin like this:
let hash = poseidon(input: input)
or in kotlin
val hash = poseidon(input)
Additionally, this approach is compatible with WASM for browsers. You can define a function in Rust as follows:
use serde_wasm_bindgen::to_value;
use wasm_bindgen::prelude::*;
#[wasm_bindgen]
pub fn poseidon(input: JsValue) -> Result<JsValue, JsValue> {
// Poseidon function implementation
to_value(...)
}
Then, by running mopro build again with the web target, you can generate the necessary bindings for the web. Once built, you can call the poseidon function directly in JavaScript, making it seamlessly accessible in browser-based applications.
The Rise of New ZK Mobile Apps
This year, we’ve seen a growing number of ZK mobile apps being developed. Some notable examples include:
These apps benefit significantly from mobile-native proving compared to using tools like snarkjs. For instance, Anon Aadhaar achieves up to 8x faster performance with rapidsnark compared to snarkjs.
For more details on the benchmarks, please refer to the benchmark section.
While we’ve provided the Mopro stack with rust-witness and ark-works, most applications are leveraging the witnesscalc and rapidsnark stack for faster proving, particularly with RSA circuits.
Given the adoption trends and benchmark results, we've recognized the need to prioritize improving rapidsnark integration and further enhancing the developer experience. This will be a key focus in Q1 of 2025.
We’re excited to see even more ZK mobile-native apps emerge in the near future, delivering improved performance and enhanced user experiences.
Final Thoughts and Looking Ahead
The Mopro tool has become more robust, now supporting multiple platforms. However, our vision extends further—we aim to develop a mobile-native ecosystem as comprehensive and developer-friendly as the JavaScript/TypeScript ecosystem, empowering developers to seamlessly build innovative apps.
As we look to the future, we encourage developers to explore the opportunities in building ZK mobile applications. By leveraging mobile-native proving, you can create apps that are not only faster but also more accessible to users worldwide. Let’s work together to shape the next wave of ZK technology and bring its benefits to mobile platforms!