# Client-Side Proving - 2025 Q3 Roadmap

Client-side proving is essential to preserve privacy and decentralization. It allows computing ZKPs locally on user device without the need to outsource the computation to a third party which can compromise privacy.

## 1. Team Members

- Alex Kuzmin (team lead)
- Brechy
- Guorong Du

## 2. Q3 Objectives

- The primary objective is to map the current ZKP systems and zkVMs that are feasible to run on mobile and obtain concrete benchmarks of their performance;
- The secondary objective is to explore in detail the most promising existing ZKP systems and their potential enhancements.

Both of the objectives are detailed below.

## 3. Objective 1 - Benchmarks

* Deliverable: **Client-Side Proving Quarterly Report** (details below)
* Must finish before Devconnect: **yes**
* Risk: **very low**
* Team member allocation
* Guorong Du - 100%, Alex Kuzmin - 50%, Brechy - 50%

### 3.1 CSP Quarterly Report

Our [recent benchmarks for zkID](https://pse.dev/blog/efficient-client-side-proving-for-zkid), despite their limited scope, have gained substantial attention of the community. We have realized that PSE is in a great position to continue this effort and extend it beyond zkID by benchmarking the typical circuits in ZKP systems that claim to be CSP-friendly. Expectations:
- After establishing the technical foundation (CI workflow, various circuits in multiple ZKP systems) it will be easy to add new circuits and merge upstream improvements of the target ZKP systems;
- The high publicity and high quality of our benchmarks will attract the community's attention and we will get contributions.

### 3.2 Objective 1 Timeline

You can find the detailed motivation below the table.

| Phase | Deliverable | Motivation |
| ------- | --------------- | ------- |
| Month 1 | zkVM SHA-256 Benchmarks | Very high demand for zkVM on mobile |
| Month 2 | ECDSA benchmarks | Circuit is very different from SHA-256, relevant to zkID |
| Month 3 | Completing the benchmarks according to the [spreadsheet](https://docs.google.com/spreadsheets/d/1LFG-icfQf4-3YoxoR4GPdkcbAmD01mLPhiM3x4ufmnU/edit?usp=sharing), as many as possible. Run on a cloud instance, *mobile benchmarks are optional but desirable.* | CSP Quarterly report should be as thorough as possible |

### 3.3 Motivation: zkVMs Benchmarking

The following developments have informed our choice of targets (see the [spreadsheet](https://docs.google.com/spreadsheets/d/1LFG-icfQf4-3YoxoR4GPdkcbAmD01mLPhiM3x4ufmnU/edit?usp=sharing)):
- Numerous zkVMs are claiming to be CSP-friendly;
- **mopro** team is looking to integrate a zkVM into their libraries.

As a first step, we will benchmark the same kind of circuit (e.g. SHA2-256) in multiple VMs in order to establish a reusable foundation per stack early on, enabling smoother iteration and better parallelism as we benchmark other circuits. This will be a continuation of our previous work where we have benchmarked SHA-256 for zkID.

We also believe the work being done by the EF's Applied Cryptography Team in both [Ere](https://github.com/eth-act/ere) and [zkEVM Bench](https://github.com/eth-act/zkevm-benchmark-workload) is great and we would like to explore possible collaborations on overlapping subjects (e.g., contributing zkVMs of our choice that are absent in Ere).

### 3.4 Motivation: ECDSA Benchmarking

- It's related to zkID;
- It's a very different kind of cirucit compared to SHA-256;
- These two primitives cover the most demanding use cases of zkID where it's necessary to prove credentials coming from conventional digital identity systems.

### 3.5 Benchmarking Pipeline

Explore possible ways of automation to simplify the process of adding new circuits and new schemes to be benchmarked. This would also imply having standardized targets and types of instances being ran to ensure that the same hardware is utilized for all benchmarks.

After benchmarking on cloud instances, we will filter out the ZKP schemes and circuits that fit into average [mobile RAM](https://pse.dev/blog/efficient-client-side-proving-for-zkid) (~4 GB for Android and ~6 GB for iPhone), and run them on mobile to obtain the most accurate results.

### 3.6 Quarterly Report Delivery Format

- Minimum: PSE.dev blog post;
- Desired state: csp.pse.dev that looks like an e-commerce "product comparison" page or DefiLlama (e.g., as a user, I want to be able to filter the ZKP schemes by the lack/absence of setup, PQ-soundness, sort by proving time, etc.).

### 3.7 Optional: Consider CSP SoK/Survey Writeup

Evaluate whether writing a Systematization of Knowledge or Survey of the current state of Client Side Proving is a good idea or valuable output of the team. The downside is that the target is shifting - new ZKP schemes emerge and the information stays relevant most likely for only a few months.

## 4. Objective 2 - New CSP ZKP Exploration

These tasks involve the improvement of the existing ZKP systems or development of new tooling.

* Deliverables: Spartan-WHIR Lite, HyperPlonk-WHIR (details below)
* Must finish before Devconnect: **no**, but nice to have
* Risk: **medium**
* Team member allocation
* Alex Kuzmin - 50%, Brechy - 50%

### 4.1 Spartan-WHIR

Spartan-WHIR is a combination of Spartan PIOP and WHIR PCS developed by World for their [ProveKit](https://github.com/worldfnd/ProveKit). They are heavily invested into that project. It's driven by their need for 3rd parties to develop ZK apps on top of their platform.

The ZKP system looks promising due to combining a high-performant PIOP with a high-performant, ***transparent (no setup!)*** and PQ-sound PCS. However, there are a few things that are specific to their project and could be done differently to gain wider adoption:

- Verify WHIR proof on-chain using PSE-developed Solidity verifier, [Sol-WHIR](https://github.com/privacy-scaling-explorations/sol-whir). Currently ProveKit is supposed to send Spartan-WHIR proofs to an aggregation service that wraps them into Groth16. This allows for proof aggregation, which is a specific feature required by World. At the same time, it undermines the decentralization. Verifying the proof directly is [feasible](https://ethresear.ch/t/on-the-gas-efficiency-of-the-whir-polynomial-commitment-scheme/21301), as demonstrated by PSE's previous work.
- Convert Circom R1CS to Spartan R1CS directly. Currently, ProveKit is using Noir as a frontend, betting on future wide adoption. However, they have spent significant development effort to convert ACIR into R1CS and this conversion introduces complexity and security considerations (e.g., is the resulting R1CS well-constrained? are custom R1CS implementations of Noir "opcodes" correct?). Adding Circom support would also allow to tap in into the huge pool of existing Circom circuits.

### 4.2 Implementation Steps

1. Benchmark SHA-256 in Spartan-WHIR to have an estimate of its performance. This step is also necessary for the CSP Quarterly Report described in section 3.

2. If the results are good, work on adding a **Circom frontend + witness generator**. We're in touch with World team and they think that Circom frontend is a nice-to-have.

3. Evaluate direct on-chain verification.

If the modified ZKP system proves to be worthy, we can further productize it in the next iteration of the project (Q4) by improving the DevEx (e.g., introducing a CLI that allows to compile a Circom circuit, generate SOlidity verifier, etc.)

### 4.3. HyperPlonk-WHIR and SuperSpartan-WHIR, or Mitigating the Spartan-WHIR Risks

The World team is heavily invested into Spartan-WHIR and our modifications should be always judged by what good they bring compared to the upstream. However, there is a more promising potential ZKP system that we can explore -a combination of HyperPlonk PIOP and WHIR PCS.

HyperPlonk paper directly claims better performance than Spartan (https://eprint.iacr.org/2022/1355.pdf). Therefore, it is logical to infer that HyperPlonk-WHIR combination has potential compared to Spartan-WHIR.

We will try to assess feasibility with HyperPlonk authors. However, we have already been in touch with the former colleague Han who has done a lot of experimentation with both HyperPlonk and WHIR:

> HyperPlonk PIOP + WHIR could bring a very good proving time + proof size balance...
> ...for small R1CS perhaps Spartan and HyperPlonk will be almost as fast, but if we need to prove huge amount of complicated relation (e.g. hashes), I think HyperPlonk will be more efficient

Han has already developed a [codebase](https://github.com/han0110/p3-playground/blob/main/hyperplonk/examples/koala_bear_poseidon2.rs) where we can test the HyperPlonk-WHIR combination, so we can quickly evaluate it in comparison with Spartan-WHIR.

HyperPlonk is a plonkish PIOP so it is naturally a much better fit for the Noir frontend which intermediate representation, ACIR, is closer to plonk rather than R1CS. Therefore, if HyperPlonk-WHIR outperforms Spartan-WHIR, we may consider enabling the Noir fronted for this system. Similar to out considerations from 4.1 and 4.2, we may evaluate the on-chain proof verification using Sol-WHIR.

Another promising combination worth evaluating is SuperSpartan-WHIR: https://github.com/TomWambsgans/Whirlaway.

More input from Han:

> Sumcheck based PIOP will be the best choice for mobile (memory constrained). And the rest is about constraint system, R1CS (Spartan), AIR (HyperPlonk), CCS (SuperSpartan) have their own strengths
> not sure in general purpose which one would be better (the proof size will be dominated by WHIR)

### 4.4 Objective 2 Timeline

| Phase | Deliverable |
| ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Weeks 1-2 | Clear winner between Spartan-WHIR, HyperPlonk-WHIR and SuperSpartan-WHIR according to benchmarks |
| Weeks 3-7 | On-chain verifiability assessment |
| Weeks 8-12 | Noir adapter development |