# Project AAMO

**anon-aadhaar x mopro collab.**

## Updates

*This document was last updated 2024-02-21.*

*Update: 2024-02-21: We have now derisked things with MoPerf and feel confident to resume this work. See [MoPerf](https://hackmd.io/5ItB2D50QcavF18cWIrmfQ?view=) for more details.*

*Update 2024-01-25: Due to high technical risks and uncertainties with performance for significantly increased constraints (currently ~160k to 1.7m from last PoC; at least ~1m constraints needed for Anon-Aadhaar to be useful) we decided to do a performance due diligence bet first before resuming Showcase App.*

## Problem

There are two main problems we want to address.

One, right now it isn't easy for programmers who want to use anon-aadhaar to build for mobile. This is primarily because (i) the tooling is currently too complex (ii) performance in mobile browsers is so bad that it either takes a very long time to do proofs (old circuits) or isn't possible at all (new circuits).

Two, ZK projects that rely on client-side proving want to build for mobile, but currently it is quite complex and tooling isn't robust and performant enough. This is primarily because there are no good production-grade libraries for doing client-side proving on mobile, that are easy to use and with robust performance.

### User stories
Another way of phrasing the above is as user stories. For clarity and consistency, we write user stories below on the form:

As a {role},
I want to {action},
so that {benefit}.

**Anon-Aadhaar SDK user:**
As a programmer with an interest in using anon-aadhaar,
I want to see an example showcase app,
using the anon-aadhaar SDK,
that is convincing from a UX and performance POV,
that is easy to understand and build on,
so that I have confidence that I can make my own successful anon-aadhaar app on top.

**Mopro user:**
As a programmer working on a ZK protocol with client side proving (e.g. anon-aadhaar),
I want to use a tool that makes it easy for me to create and verify proofs on mobile,
it should easy to understand and get started with,
it should be fast,
it should be robust,
it should work for many platforms,
it should allow me to use my existing skills as opposed to learning too many new things,
so that I can create a great anon-aadhaar SDK for my users.

### Secondary user stories
These are secondary user stories to cover the whole range, from people working on tooling to end user. They should not be the primary focus, because it'll dilute the effort, but they are useful to keep in mind.

**End user (prover):**
As an event attendee,
I want to be able to prove I have a valid Aadhaar identity, without revealing anything else, and to do so from my mobile phone, in a fast and fluid manner,
so that I can authenticate in real life, without risking data loss.

**End user (verifier):**
As an event organizer,
I want to able to verify that a user has a valid Adhaar, and to do so from my mobile phone, in a fast and fluid manner, with reasonable security guarantees,
so that I can be sure only people with a valid Aadhaar gets access.

**mopro developer:**
As a programmer working on mopro,
I want to have a concrete artifact to build for, with specific requirements and constraints,
so that I can build a great tool for people with an interest in doing client-side proving on mobile.

### Current status

This is the baseline and what we want to address.

**anon-aadhaar:**
Currently the primary way to use anon-aadhaar is through a web browser. This has problems when it comes to performance (slow proving time), persistence (keeping your ID around for a long time), as well as security (process isolation, user trust issues). With recent changes to the circuits to increase affordances (prove things about specific parts of your digital identity), performance (primarily proving time, but also key size) is currently a bottleneck for users who want to build on anon-aadhaar. Specifically, it now takes around 60 sec time to create proofs on MacBook Pro M1 Pro (16 GB RAM) hardware/environment.

There have been many interesting hackathon projects targeting anon-aadhaar, but very few have targeted mobile specifically. This is likely because of (i) complexity of building for mobile (ii) lack of a good tool, e.g. a mobile SDK. There exists a very rough PoC built with mopro called pocket-aadhaar (created by Yanis and Oskar), but it is very rough and far from production-ready.

**mopro:**
Mopro is a new library that aims to make it simple and fast to create proofs on mobile. While some PoCs have been built, and performance improvements demonstrated, it is still lacking in terms of usability, robustness and performance. It is too hard to get started, you can't create a project without working inside the repo, the API is rough, there are bugs, working on real-world devices needs to be more robust, and there are some low-hanging fruit to further improve performance. Additionally, there doesn't exist a good "showcase app" that shows how mopro can be used to build real production-grade applications. The lack of this makes it harder for ZK teams to justify effort to use mopro due to the perceived risk of a new tool.

## Appetite

We want to constraint the problem such that we can solve it in five weeks. ~Feb 22 - Mar 29.

Because we are addressing two problems, we can imagine these are two tracks, working closely together and feeding into each other. Since this is a cross-team collaboration, fixing the time period makes it easier to coordinate and to ship something valuable in time.

We imagine the two tracks consisting of ~2-3 people each. On anon-aadhaar side, two programmers and one PM/designer. On mopro side, two programmers.

Specifically, Yanis, Vivian and Oskar.

## Solution

We divide the solution into two parts, app and tool. The first is the ZK ID Showcase App and the second is the mopro MVP.


### ZK ID Showcase App
Solution for this has three components: App Performance UX, DevEx.

The goal is to integrate Anon Aadhaar on mobile with the aim of enabling other developers to replicate this functionality. Based on what developers have asked for, building a React Native (RN) library for npm publication seems like a practical. The goal is to leverage Mopro's native performances and wrap with RN.

#### App


- Create a basic app using Anon-Aaadhaar that interact with the main Anon Aadhaar component
- This main Anon Aadhaar component will be imported from RN Anon Aadhaar library and will have the following features:
* Scan an Aadhaar secure QR code
* Create proof from the QR code data
* Verify this same proof
* Update user state (`identity-proven`: true | false)
* Don't need a lot of bells and whistle but should feel polished/native
* Example app part of RN lib repo
w

#### Performance UX


- Smooth UX from a performance POV (from end user perspective)
- ~30s proving time on modern devices
- Background loading of assets if possible
- Possibly proving in background if supported (investigate)
- A lot of this should be enabled from mopro, but some work might be required

#### DevEx


- Should be easy to work on and deploy by developers
- Working on Android and iOS (using mopro bindings for both)
- React Native library support (one code base)
- `@anon-aadhaar/react-native` as npm module
- Handles circuit inputs from QR code scan
- Provides UI components
- RN lib should abstract native bindings and Anon Aadhaar setup, devs should import one main component from RN lib
- Interact with Mopro's native components for verify/generate proofs
- Native modules to link to Android and iOS
- Requires ObjC bridge (collaborative effort with mopro)
- (Bonus: Expo support? For easier development)

Things to derisk early:
- Making proving of new circuits work end to end with new circuits
- React Native bindings

### Mopro MVP (v0.1)
We divide the solution into three main parts: CLI, Robustness and Performance.

#### CLI


- Create a `mopro` CLI as the main way of interacting with mopro
- As opposed to ad hoc scripts and instructions; should feel similar to something like Foundry
- `init` to initialize a project without having to work inside the mopro monorepo
- Should create a new project with example code to run circuit on platforms
- Options possible: `--platform ios,android,pwa,desktop --language circom <MyProject>` (not all have to be implemented)
- Very rough start [here](https://github.com/oskarth/mopro/tree/main/mopro-cli) with Clap
- `prepare` to install dependencies
- basically prepare.sh script - can shell out
- `build` to build all necessary dependencies
- Options: `--plaform itos,android,pwa`
- `update` to update bindings
- `test` to run tests
- More options might be added; basically a minimal surface area that makes mopro users productive quickly

#### Robustness

- Make sure it works seamlessly on real device for both Android and iOS
- iOS support requires fixing dylib integration
- Android support is new and might require more work (?)
- Easy to understand API
- Clear single API to use
- No random gotchas like hardcoded arkzkey etc
- React Native module
- Swift extension
- Objective C header
- New additional scope: cross-team effort to implement this

#### Performance


- We want to have a reasonable prover time, ~30s, for big circuits on modern phones
- Prover should work on recent phones up ~1.7m constraints
- Debug this
- Improve zkey load time (zero-copy serialization to make this very fast, and/or do in background)
- Try Circom native witness generation library in Rust (currently this is in wasm and is 80% of prover time)
- If we do this we don't need to dylib anymore
- Possibly more performance work needed for smooth UX

#### Public release


With the above three done to a level satisfactory for the showcase app, we should be able to release a v0.1:
- v0.1 as first public release
- Works on recent Android and iPhone
- Enable fast performance
- Clean API example usage
- Artifacts published for new users to use

Things to clarify:
- React Native support
- Expo (optional)

Things to derisk early:
- Get end to end working early (Semaphore easy example)
- Including with React Native
- Try to fix performance bottlenecks early

## Rabbit holes

- Chasing performance too much (timeboxed bets for low-hanging fruit OK)
- Going for too much generality as opposed to one specific showcase app

## No-gos

- Fundamentally changing proving stack