CLIENT SIDE PROVING: How big can circuits for mobile proving be?

With Anon-Aadhaar v1 circuits being 1.7m constraints, we wanted to answer this question with Project MoPerf.

While there are many performance related concerns the biggest blocker is memory usage. With modern phones with 4GB we can do 1.7m+ constraints.

We previous did a PoC with Anon-Aadhaar (160k constraints). With AA v1 (nullifiers+selective disclosure, see https://twitter.com/PrivacyScaling/status/1757828914733310047 for more) constraints increased more than 10x to 1700k. We weren't sure if this was still feasible on mobile, so we wanted to test this.

zk-pilled or something | Now: http://zkintro.com, folding, mobile proving, etc | Was: Created @vacp2p and @Waku_org | 英文中文都可以

This is important, because most ZK Identity solutions have the same ballpark complexity (~1m constraints), and they have to be run from mobile to function as desirable. Circom is also still the most mature stack out the there, and other stacks come with different trade-offs.

While there is more work to be done (including improving performance), this gives us confidence to get Anon-Aadhaar v1 to work on mobile in the form of a showcase app. For more details, read here: https://hackmd.io/5ItB2D50QcavF18cWIrmfQ?view=#Results. To be continued.

https://ethresear.ch/t/lookup-singularity-via-mmr/18704/5

I have a way to speed it up even more. The tradeoff for cryptoeconomic security is unnecessary. You can have infra validate the tables used.

Using GKR and Sumcheck you can get a significant boost in batch proving circuits.

Working on building products with zkTLS. A ruthless empiricist.

http://opacity.network

Advisor @ EV3 Ventures

What you are talking about is a different approach to circuit design. While interesting, this is orthogonal to the question "how big can circuits (in number of constraints) be on mobile?", with vastly different ways of approaching performance bottlenecks.

Here’s an easy way to get a huge performance boost.

Just precompute a table of lookups you need, and use that as an input (insensitive computation)

With recursion and infra you can then validate the table.

I got a 5x speed gain in this example:

https://github.com/Hmac512/noir-merkle-root-POC-lookup

https://warpcast.com/eulerlagrange.eth/0xedf2debb

Try this strategy for non-sensitive parts of the computation to get better numbers.