# Mopro progress reports Document for progress reports on Mopro (Mobile Prover). Aiming to do check-ins ~every 2-4 weeks. (There's also a grant document to cross-check with but link is private). ## Feb 1 - Apr 15 Done (abbreviated) - Improve DevEx significantly with mopro-cli as main interface - Demo https://www.loom.com/share/6ff382b0497c47aea9d0ef8b6e790dd8 - Finish up MoPerf: https://hackmd.io/5ItB2D50QcavF18cWIrmfQ - Understand limits of client-side proving (4gb phone ~= 2m constraints np) - Derisked enough for resuming AAMO project - AAMO collab: https://hackmd.io/321WjevGRBWMSPYe6g7mcw - Also with Proof of Passport - Generally good feedback loops, RN support etc - Found unexpected blockers with witness gen and app store - Witness generation notes - See https://github.com/oskarth/mopro/issues/109 for context - Unable to get current dylib setup working for App Store upload - Should be possible, we just couldn't figure it out - Lead some teams to look for alt approach - Found alt slower approach that works (wasm3) - Non-trivial to integrate witnesscalc (C++) with current stack - Native witness gen in Rust turns out to only work for some circuits - Promising in terms of perf (much faster than witnesscalc) - But non-trivial to make complete => more work needed - Talks and workshops - ETHTaipei (Taipei) - Slides https://hackmd.io/@oskarth/S1yGjF8C6#/ - ZK Day workshop (Taipei) - ZK Summit (Athens) ## Dec 1 - Jan 31 - Done - Improve API and DevEx - Simplify config with TOML file; start of CLI interface - ark-zkey better integrated - Misc bug fixes and clean up - Outreach and talking to users - Term Structure and ZK Identity talk at Taipei Blockchain Week - Talk to teams to understand needs (ProofOfPassport, Myna, AA, etc) - Support GPU grantee work - Initial Android support and generate calldata (Vivian) - Shape up Anon-Aadhaar ZK-ID Showcase App (AAMA) - See https://hackmd.io/321WjevGRBWMSPYe6g7mcw?both= - After circuit increased from ~160k to 1700k constraints technical risk went up - We decided to pause this and derisk perf bottlenecks first before resuming - Start MoPerf project collab with AA to find limits of client side proving on mobile - See https://hackmd.io/5ItB2D50QcavF18cWIrmfQ?view= - Understand unknowns and derisk these (see [GH issues](https://github.com/oskarth/mopro/issues/57) for more details) - Good news: Able to run latest AA circuits on new iPhone and clear direction for most unknowns - Next - Finish up MoPerf project (clarity, perf, write-up) - Resume Anon-Aadhaar showcase app (see doc above re scope) - FYI - This is for Dec-Jan; took some time off in middle - Oskar off Feb 5 - 12; Vivian Feb 14 - 20 - Some lack of clarity re grant agreement ## Nov 6 - Nov 30 (3-4 weeks) - Done - ZKHack: RSA Verify and Anon-aadhaar on mobile together with Yanis from Anon-aadhaar - [devfolio pres link](https://devfolio.co/projects/two-and-a-half-zk-pocketaadhaar-and-pocketkimchi-a8a6) ~6.5s (~5s witness gen, ~2s prover time); x10 faster vs browser on phone - PoC of new proof system; (Kimchi, Plonkish) to show ease of integrating new proof systems - RSA verify (zk email circuits) benchmark - arkzkey: zkey bottleneck; sped up by x10 with custom arkzkey format to ~10s; also 50% file size - ProgCrypto presentation: [slides](https://docs.google.com/presentation/d/1afIEgm8oYRvteWxUd04CcMOxChAiHaD55d5AKd0RkvY/edit#slide=id.g29a7b1abf9b_1_543) - Planning at Devconnect: https://hackmd.io/@oskarth/mopro-devconnect - Consider milestone 3 done (will turn talk into write-up too) - Next - Improve API and DevEx - More robust API - mopro CLI interface - Docs and tutorials - General clean up - Improve performance: Address bottlenecks mentioned in presentation - Integrate arkzkey and try to improve further - Experiment with native witness generation - Android support - Write-up - FYI - Quite a lot in next; milestone 4 cleanup before EOY - Oskar will take a bit of time off during holidays then continue in Jan - After milestone 4 inital grant finished, but we decided to continue grant, just less rigid milestones ## Oct 9 - Nov 6 (4 weeks) - Done - Got it working on real device - Lots of debugging related to witness generator wasmer memory restrictions problem; patched wasmer page size bug - Lots of experimentation with dylib to pre-load resources, etc - On modern iPhone (14 Pro Max), Keccak proof generation takes ~1.5s (~x20 vs comparable browser? see last note) - DevEx work to make it easier to use and contribute to - Onboarding second developer (Vivian), who helped with a bunch of DevExp work - Improve scripts, tests, configs, CI, separating out examples, etc - Generally making it easier for someone to run and use - Library maturity: zkey experimentation - Moving from doing in-line setup and .r1cs file to using zkey - Works but (i) Too slow for big circuits (ii) Some API changes needed - Experimentation with improving zkey loading/serializing, but not performant enough yet for e.g. Keccak - Wrote up several issues related to future work - GPU plan of attack: https://github.com/oskarth/mopro/issues/22 + subissues re micro benchmarking, etc - Many others here: https://github.com/oskarth/mopro/issues - related to different platforms, proof systems, setup/zkey, DevEx, RSA example, etc - Next - Disseminate work done so far, give talk at ProgCrypto and involve others - Fix zkey loading performance (proving key loading slow) and adjust API - RSA example - Blockers/FYI - Blocker: Zkey loading too slow for Keccak256, >1m - Some experimental work [here](https://github.com/oskarth/mopro/pull/26) - FYI: Adjusting milestone 2 scope and considering it done - Working on real device took longer than expected - Less GPU focus for now (clear next steps), esp with x20 perf boost; revisit later - Decided to focus more on DevEx to get tighter feedback loop and early usage ## Sep 18 - Oct 9 (3 weeks) - Done - Milestone 1 and PoC finished - Went from doing everything in Rust to exposing API for inputs/setup/prove/verify - Using a more involved circuit (Keccak256) - Open sourced repo [here](https://github.com/oskarth/mopro) (not publicly announced just yet) - Example app with basic Keccak proof and preliminary benchmark - iOS simulator on M1 MBP Keccak256 (150k constraints) ~1.2-1.3s - Comparable: ecdsa_verify 160k constraints ([link](https://github.com/personaelabs/efficient-zk-ecdsa#browser-proving)) in-browser ~35-40s - Preliminary results, need to run on real device and sanity check (see REQ below) - Demo of recent progress available [here](https://www.loom.com/share/1f36229c66534e16b5cf58abb5064add) - Next - Continue with benchmarking - Run app on real device - Do basic profiling (empirically identify bottlenecks) - Find comparable and reliable benchmarks to communicate perf diff with confidence - Improve API/UX for developers - Lots that can be done here, need to identify most low-hanging fruit - Depends on real-world demand (see REQ) - Continue GPU usage trial - Experiment with iOS GPU as a spike (likely requires quite a lot of new learning) - Experiment with Arkworks GPU usage on laptop - Revisit prior note and make plan of attack for incorporating recent advancements with GPU MSMs etc - Blockers/FYI/Requests - FYI: A lot of work spent on getting Rust/Swift to play nicely w.r.t. data types, serialization, error handling etc. This was identified as a risk in project scope, so good to get this done early. - REQ1: It would be useful to have a simple standard and up to date benchmark to compare with for in-browser proving, e.g. with ECDSA/RSA/Keccak. I can set this up myself but if there are any good existing canonical ones it'd be better to use that, as opposed to doing a side quest for messaging around with JS/Web ZK env. - REQ2: Prioritization regarding e.g. GPU vs API DevEx; if we have x20 perf improvement already it might be worth making it easier for Zupass/Aadhaard and similar projects to use at Devconnect. - REQ3: Contact for Circom/Polygon person also looking into mobile proving; any other person you think I should talk to, especially early users. - REQ4: I think it'd be useful to have mopro as a hacking target during Devconnect, either in terms of apps using it or improving tool. Any ideas for how to make this happen would be appreciated! ## Sep 4 - Sep 16 - Done - Library architecture illustration of how things fit together, see drawing - Setup separate components/libs for `mopro-{core, ffi, ios}` in [mopro repo](https://github.com/oskarth/mopro) - Get Arkworks to work on iOS simulator (though still with some errors) with CocoaPod lib and UniFFI Swift bindings - Evaluate easiest proof system/tooling for e2e, decide on circom-compat to start with but keeping it modular - Next - Expand PoC to make basic API (not just example but separate setup/prove/verify bindings), deal with errors etc; make tiny example app with buttons; use non-trivial circuit - Start to scope GPU work - Blockers/FYIs - No real blockers - FYI1: Keeping repo private for now until e2e works nicely, will open source soon but can add people if interest - FYI2: Toolchain/scripting needs work in terms of updating static libs in iOS, working on real device and working nicely for diffeent architectures/environments (aarch64-apple-ios{,-sim}, x86_64-apple-ios different libs libs) - leaving this for now to get e2e nice ### Artifacts Code: [mopro repo](https://github.com/oskarth/mopro) #### Architecture The following illustration shows how mopro and its components fit together into the wider ZKP ecosystem: ![](https://hackmd.io/_uploads/SJFvoIHyp.png) Zooming in a bit: ![](https://hackmd.io/_uploads/B1TvoLBka.png) ## Aug 21 - Sep 1 - Done - Scope out initial work, write grant, milestones - Initial research to understand options better (performance problems, current way, tooling, mobile bindings) - Do PoC spike `rust-swift-spike` to get Rust working on iOS with UniFFI bindings - Next - Draw out library architecture and make illustration of how things fit together - Take spike and split into components; integrate Arkworks for e2e proving on mobile - Blockers/FYIs - No real blockers - FYI: A lot of fiddling with Xcode/iOS toolchain, refamiliarizing myself with ecosystem, opaque configs, different architectures for embedding libraries, linking issues etc - on the flip side this is good because shows mopro can solve a clear pain point