Two and a Half ZK: pocket-aadhaar & pocket-kimchi

Two and a Half ZK: pocket-aadhaar & pocket-kimchi

Bringing ZKPs to your pocket: fast, secure and accessible. ZK-Identity for 1B+ users; accidentally adding Kimchi proof system to mobile woot woot.

The problem Two and a Half ZK: pocket-aadhaar & pocket-kimchi solves

pocket-aadhaar

pocket-aadhaar enhances the existing anon-aadhaar system, which allows privacy-preserving identity verification of over 1B+ users but with suboptimal proving time in browsers. Anon-aadhaar works by proving that the document was RSA signed by the Indian government. This is useful in many scenarios, such as when we want better security guarantees, performance and general affordances (including UX) you only get when running on mobile. By leveraging mopro for native proving on mobile devices, this project offers a more efficient and seamless ID verification process in real-world scenarios.

pocket-kimchi

pocket-kimchi addresses the limitation of the o1js API, which is primarily browser-focused, by providing mobile bindings to the underlying Kimchi Rust proof system for Swift.

This allows for the execution of proofs and verifications natively on mobile devices. This is useful in many scenarios, such as when we want better security guarantees, performance and general affordances (including UX) you only get when running on mobile. As the Kimchi proof system is usually paired with Mina^HSaurkraut, a succinct blockchain, being able to run on mobile makes a lot of sense.

It also demonstrates the ease of integrating additional proof systems into mobile applications with mopro. Because Kimchi has a Rust native API, this is surprisingly straightforward.

Circom RSA verification

As part of anon-aadhaar, we need to do RSA verification. This circuit was developed by ZK Email. Doing this on mobile demonstrates the capability of executing complex circuits using mopro in a performant way.

This also acts as a good benchmark for complex circuits (~140k constraints) and big witnesses, which (i) informs future optimizations (arkzkey, native witness generation, alternative proof systems, async loading of libraries) and (ii) showcases to people what can be done with Circom on applications mobile today.

Challenges we ran into

pocket-aadhaar

  • Implementing a webview for Anon-Aadhaar and facilitating proof passing to the native prover.
  • Also see Circom RSA verify below.

Disclaimer: Anon-aadhaar already exists (but WebView is new); ditto RSA circuit.

pocket-kimchi

Note that these are most likely not intrinsic problems, but are oversights on my part to solve problem in a short timebox.

  • Limited documentation for Rust Kimchi snarky API.
  • Had to hardcode and include

    vesta.srs

    as bytes due to its relative path in the kimchi project (and to simplify iOS distribution).
  • Serialization issues with some elements like public inputs.
  • Example proofs tightly coupled with the testing framework (harder to consume externally).
  • However, the overall integration process was smoother than expected.

Disclaimer: Kimchi is already developed; API for proving is super hacky.

Circom RSA verify

  • Improving zkey loading performance by ~x10 through custom serialization to arkzkey.
  • Integrating RSA verify circuit into mopro with test vectors.

Disclaimer: zkey problem was identified before hackathon and partial work on it, but x10 perf gains was only realized during hackathon; RSA circuit already existed; mopro library already existed (along with Keccak256 example app); there's a bug where detaching phone from computer causes some issues.

Also Vivian from PSE (Unirep) helped out a bit remotely with zkey verification logic. Hence 2.5 projects/people!

Tracks Applied (3)

O(1)Labs - Open Track

Kimchi proving/tooling on mobile!

O(1)Labs

Develop a zkDapp using the Polygon zkEVM

Not specifically zkEVM, but it is using Circom to do RSA verification on mobile natively :)

Polygon

Chewing Glass

Have you ever tried using Xcode? Custom zkey->arkzkey conversation, tooling for mobile, WebViewnative communication

Discussion