Research updates June 19th

# Research updates June 19th ## Assisted proving I’ve been thinking about a way to delegate the proving process of FRI to an external entity (remote server) without revealing private information (i.e. the witness). A simple solution is to only execute the first round of the FRI commit & query phases, and send the information necessary to continue the rounds. The first round of commit/query phases can be made zero-knowledge using standard techniques (e.g. methods to construct Zero-Knowledge PIOP described in the HyperPlonk paper). With such “assisted proving”, we could potentially significantly lower client-side proving time. (especially with FRI which the proving mostly consist of hashing) (Will write more about assisted proving in a different doc) ## R1CS might be outdated I had an assumption “R1CS is enough for client-side zk”, but that might be wrong. Firstly, I’m getting the impression that the industry is perceiving R1CS as something that is obsolete, and a modern proof system should come with expressive arithmetization methods like Plonkish/CCS. If we publish a paper/writeup about a proof system, it’ll likely get more impressions (citations, improvements) if it’s built on top of Plonkish/CCS, rather than R1CS. Secondly, R1CS likely won’t be suited for ZKML and other computation-heave situations and will require a more expressive arithmetization method. ZKML will have (or already has) an agenda to improve proving time in resource-constrained devices, so our research is relevant to ZKML. [ezkl](https://github.com/zkonduit/ezkl) and [zkml from Daniel Kang](https://github.com/ddkang/zkml) use Halo2 to write their circuits. Also, by going back to the spartan-ecdsa circuits ([while explaining the circuits for the audits](https://hackmd.io/68TlQZFvQOeMZ2mvFl0Abg)), I realized that having custom gates/look up tables could lower the circuit size of spartan-ecdsa by a meaningful margin since the circuits still require some wrong-field arithmetic, and [it’s known that](https://docs.zkproof.org/pages/standards/accepted-workshop3/proposal-turbo_plonk.pdf) elliptic curve operations can be more efficiently encoded with custom gates. ## ZKML - It’s now cliché to say zk can help distinguish AI-generated content from human-generated content. But this could be an area where our agenda and the industry's agenda align. Our goal is to get client-side proving time down in resource-constrained devices, and that’s what’s needed for [“attested devices”](https://medium.com/@danieldkang/fighting-ai-generated-audio-with-attested-microphones-and-zk-snarks-the-attested-audio-experiment-d6ea0fc296ac). - We’ve been focusing on building **fast and backward-compatible proof systems**, but if techniques like “assisted proving” provide meaningfully faster proving time for all kinds of situations, we could expand the scope where we can provide solutions that improve the convention. ZKML might be one. - This might be a little out there thinking, but circuits that encode ZKML models are likely going to be big, so it could make sense to _stream_ the circuits for client-side proving. - [Gemini](https://eprint.iacr.org/2022/420.pdf) constructs a proof system that can prove _streamed_ R1CS with a motivation to prove large R1CS (>billion constraints) that can’t be loaded to memory. - We could also utilize Nova-style folding to virtually stream the circuits. ## Some readings - https://hackmd.io/@omershlo/rJhgKJPtj - https://polygon.technology/blog/pricing-gas-in-polygon-zkevm - TLDR; zkEVMs have to follow the conventional gas pricing of OPCODEs to be sure all existing smart contracts work on their rollups, even though such pricing is not optimal in the zk configuration. But Starkware doesn’t have that problem.