# Mopro planning at Devconnect 2023

**Let's accelerate and make more proofs client-side**.

This document: last few months, vision, ideal UX for app devs, next 6m, questions.

## mopro last few months

tldr: proving on mobile works, it is fast and useful enough for building zk apps (like pocket-aadhaar). experience is still hacky, it can be faster and we can do more to meet users where they are.

See Oskar's talk at ProgCrypto for more context, slides [here](https://docs.google.com/presentation/d/1afIEgm8oYRvteWxUd04CcMOxChAiHaD55d5AKd0RkvY/edit?usp=sharing).

## mopro vision

I want us to create the Foundry for client side proving.

> Foundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust. ([Github](https://github.com/foundry-rs/foundry))

**Mopro is a fast, portable and modular toolkit for ZK app development written in Rust.** Was: Morpo is a toolkit for making proving on mobile simple (and fast).

What does this mean? Mopro stands for **mo**bile **pro**ving, but it also stands for **mo**re **pro**ofs.

Developers want to use a variety of proof systems/tooling (Circom, Halo 2, Nova/Folding Schemes, Noir, etc) and to allow users to create and verify proofs on a variety of platforms (iOS, Android, Web, PWA, Desktop).

It should be portable (work anywhere), modular (use whatever part of the stack you care about) and fast (use best native performance where we have access to it).

(It should also be easy to integrate into your existing project).

## Towards a great UX for app developers

To me a great CLI for mopro, similar to what exists in Foundry, would be the ideal UX for developers. We already have an ad hoc one today that is a bit all over the place with cargo commands, shell scripts to update bindings etc. I'm imagining you can take actions such as:

# Initialize a project with support for multiple platforms
# Optional arguments like --example, --platform, --architecture, --module
# (Find better name vs language; (proof-)system? adapter?)
mopro init --platform ios,android,pwa,desktop --language circom <MyProject>

## Build dependencies
mopro build --plaform ios,android,pwa

# Update bindings with new API
mopro update --platform ios,android,pwa

# Run tests
mopro test --platform ios --test circom-rsa

Talking to a few projects, it seems like some are hesitant on time investment for a mobile native app and not sure if or when they need it. It can be a significant commitment. We need to reduce this uncertainity and provide a progressive path to onboard people. The way to do this is to (1) show how easy it is to make use of mopro and make an app, including with things like Webview (2) provide a progressive path for app developers.

A progressive path might look something like:
- Desktop/CLI PoC -> PWA (service workers in background, offline support) -> Webview on native -> React Native -> native Swift/Kotlin app

We already have basic "desktop support" in the form of proving and verifying Circom circuits from Rust (used for testing of Rust API), so exposing this wouldn't be too difficult. It'd also get us one step closer to not having rely on JS tooling for everyhing (e.g. see Circom dependency resolution issues).

### (Circom dependency management)

This came up in conversations with Pierre and seems related so adding it here.

Problem: Circom dependency management isn't great. Conflict resolution of duplicate template is a problem, and so is ensuring the use of audited circuits.

Solution: Improving conflict resolution/insight and making it clear what circuits have been audited (a la OpenZeppelin) would help address this problem.

This relates to how we reconcile DevEx with security, especially as we start to deploy this technology in the real world and more and more developers join the space.

### Not reinventing the wheel

To clarify: we don't want to re-invent the wheel. Some good tooling obviously exists already, and when that's the case we should simply re-use that. This can be as simple as wrapping existing commands in a more intuitive and consistent interface (people already do this with ad hoc Circom shell scripts). In other cases it might mean more work, such as circom-compat, circom-witness-rs, or what p0tion did for trusted setups.

## What does the next ~3-6 months of mopro look like?

Rough skech of things we want to do.

1) Improve API and DevEx
2) Onboard more projects
3) Improve performance
4) Add support for more platforms and proof systems

Let's break this down.

### Improve API and DevEx

We want to make it very easy to get started, generally simplifying process, minimizing the amount of steps and making the process robust. We also want to create better documentation and tutorials, and improve CI. The CI should be fast (~10m, now 2h...), test more relevant paths, and perhaps show performance metrics. The API needs to be cleaned up and improved. Also see section on mopro CLI interface above.

1) More robust API
2) mopro CLI interface
3) Docs and tutorials
4) Improve CI

## Onboard more projects

We did a PoC with pocket-kimchi that went very well. We want to identify and onboard more similar projects and help them where we can. One candidate is the Japanese ZK-Identity system. More ideas are welcome, and we should be involved from the beginning with integration to make sure they get what we need and we build for their specific problems. This relates to API/DevEx, where project should be able to control their own repo and not work "inside" mopro (with mopro init).

1) Onboard at least 3 projects

## Improve performance

We want to address bottlenecks identified (zkey and WASM witness generation). We also want to get some traction on GPU experimentation (see Github [issues](https://github.com/oskarth/mopro/issues/22) scoped out). Finally, though this falls more under API/DevEx, we want to speed up CI and ideally use this for performance metrics.

1) Address bottlenecks mentioned
2) GPU Experimentation
3) Speed up CI and get metrics from mobile

## Add support for more platforms and proof systems

No-brainer here is Android, and should be trivial for basics. We also want to add React Native native modules, which includes binding native Swift/Kotlin to JS. Other things useful on the platform front is basic support for PWA (Progressive Web Apps) leveraging service workers, offline usage etc (a la Connect4). We currently basically have Rust CLI for free, so seems useful to expose this too. We also get Python bindings for free with UniFFI, so it might be useful to have a very basic example of how to do things with Python bindings on desktop, especially in terms of onboarding non-ZK people.

On the proof system side, we should add Halo2 bindings, some folding scheme (ideally with folding-schemes repo). Currently can't use Nova Scotia because it is spawning subprocess. Possibly Noir or similar DSL would be useful too. For proof systems, we should also engage directly with projects to tell them requirements for portable (no subprocess, tweaks to API/serialization, small lib size, etc).

1) Add more platforms such as Android, PWA, CLI
2) Add more proof systems such as Halo2 and ~Nova

## Questions

- PSE and 0xPARC alignment on goals and priorities
- Structure: grant vs contract etc
- Team composition
- Splitting up work and leveraging other grants/efforts