Currently, proofs for the RISC0 RM take several minutes to create (on fast hardware), and sometimes tens of minutes or more on slower hardware. Considering specifically the compliance proof (for which we have a dedicated profile file thanks to @xuyang):
- ~ 2/3 of proving time is spent on proving elliptic curve operations
- ~ 1/6 of proving time is spent on proving hash computations (about 50 hashes)
- ~ 1/6 of proving time is spent on encoding/decoding
For latency-sensitive applications (even simple ones, e.g. Anoma Pay / shielded transfers), proving times in the minutes are not tenable from a UX perspective. For more complex applications, proving times could run into the hours, which is probably also unworkable, so I think we should devote some attention to how the situation might be improved. Unfortunately, for a zkVM stack that we did not write and do not deeply understand (e.g. RISC0), our ability to optimize may be somewhat limited.
At a high level, if we want substantially better proving times in the short term, I think there are directionally two options:
- Attempt to optimize the resource machine RISC0 implementation.
- Explore alternatives to zkVMs (which allow easy programmability but clearly still come with a lot of overhead).
Optimizing the RISC0 RM
For substantially improved proving times, I imagine that we would need to both either highly optimize or remove the elliptic curve operations and either reduce the count or increase the proving speed of hash functions.
Optimize elliptic curve operations
I don’t know the details here and would defer this question to @xuyang – are we using an optimized gadget/precompile for the elliptic curve operations? If not, could we write one, or is that not really possible in RISC0?
Remove elliptic curve operations
We could design a version of the RM which dispenses with the balance check entirely. Some relevant ideas were discussed in this topic a few months ago – we haven’t fully worked out what this would look like, but it’s certainly possible to explore. Likely the elliptic curve operations would be traded for more hash functions, since we’d need to use more ephemeral resources to carry the constraints which are currently carried by the delta and balance checks.
Reduce the count of hash functions required
I don’t know the details here either – maybe this topic is relevant?
Increase the proving speed of hash functions
Are we using the fastest hash function available on RISC0?
Explore alternatives to zkVMs
An interesting option could be to resurrect the old Taiga codebase, which had pretty good proving times even on old hardware. The primary constraint here that we would need to figure out how to satisfy is EVM proof verification (we still want a protocol adapter - like construction). We might be able to verify Halo2 proofs – I did a bit of searching and found this repo by Axiom, although I’m not sure of the performance characteristics there. Another option could be to use Aligned Layer which supports more verifiers.
As an aside, have we explored OpenVM? It looks pretty interesting.
I think there are roughly two feasibility questions here:
- How difficult would it be to update the old Taiga codebase to the current shielded RM design and construction?
- Can we manage to verify the proofs on Ethereum? Would the above Solidity contracts work in a reasonably performant way or would we need to build something custom / do a layer of Groth16 recursion / etc.?
This is just a brief sketch, but I wanted to lay out these thoughts and ping the experts – @vveiln @xuyang @ArtemG – for feedback and a sense as to which directions here are most worth exploring.