burdges
commented
1 year ago We'll have niche blockchain adoption for "snark languages" I guess, but if you want crypto performance of the sort desired by say the IRTF then imho full snark languages face serious hurdles..
We've curve order concerns including curves for special purposes like https://eprint.iacr.org/2022/1145 as well as tools for moving commitments from one curve to another https://eprint.iacr.org/2022/1079 if using multiple snarks in one proof.
I'll talk about "zero-knowledge continuations" this coming week at zk summit, meaning groth16 snarks whose trusted setup is extended to permit rerandomization of pedersen commitments in the public input, so the groth16 snarks could be proven once and unlinkably reused arbitrarily many times. See https://github.com/w3f/ring-vrf/blob/master/papers/ring_vrf/rvrf_inst.tex
Although zero-knowledge continuations do not improve anonymous money, I'd expect most real world snarks suitable for say IRTF standards would benefit from using zero-knowledge continuations. Yet zero-knowledge continuations requires groth16s and external PoKs, and optionally uses other snarks like plonk for non-reusable parts.
Is anyone besides arkworks prepared to provide common ground for mixing a groth16 and a plonk? Or make it easy to chop up a circuit into multiple zero-knowledge continuations? Or support circuit independent SRS points ala https://github.com/arkworks-rs/groth16/issues/38 for runtime interchangeable or upgradable zero-knowledge continuations?
As a separate matter, there are many different flavors of ring VRFs, of which I'll only discuss one, but really huge swaths of snark applications fit into being some form of ring VRF, or some other separated proofs of membership and function evaluation thing, so one "developer friendly" things to do is develop various flavors of ring VRFs or similar in nice modular ways. In this, ring VRFs are more amenable than general snarks to classical miss-use resistance techniques.
tl;dr All current snark DSLs were imho designed too soon so curve specific concerns and higher level optimizations could make them obsolete for non-money applications. We'll also continue finding meaningful gadgets that individually support simpler stronger miss-use resistance techniques than general purpose snarks do.
Summary
This is a general-purpose issue talking about the possibility of making arkworks-rs easier to be used by general developers.
Problem Definition
There has been a lot of work in DSL for zkVM/zkEVM. I always have doubts and feel that writing in Rust directly can be beneficial.
Many research articles talk about the benefits of DSL, but this very website, called "GitHub", basically shows that DSL often has low adoption.
Instead of building a language that requires a separate compilation stage, we see a lot of success in providing SDK on a mature language.
And probably the best evidence is that many people who watched this repo or starred this repo deploy ZK applications in Rust.
So, I think arkworks-rs has a special space in the ZKP application development area. A long-term, and probably more HCI-related topic, is to make this library easier to be used by new developers.
For the record, the first step is probably just
ark-simple-nameswhich importsark-relations/r1csand replace names to some simpler ones.Proposal
Have some to-do items to gradually improve usability.
For Admin Use