Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Circuit Independence of public input SRS points #38

Open
4 tasks
burdges opened this issue Feb 19, 2022 · 0 comments
Open
4 tasks

Circuit Independence of public input SRS points #38

burdges opened this issue Feb 19, 2022 · 0 comments

Comments

@burdges
Copy link

burdges commented Feb 19, 2022

Summary

We should support verifier SRS points for public inputs being independent of the circuit and other SRS elements, but maybe only optionally so. ZEXE-like schemes could then be build using MIPP proofs like SnarkPack, without wasting resources on slow recursion.

Proposal

At present, we discover verifier SRS points for public inputs only after performing a Groth16 trusted setup because Groth16 constructs verifier SRS points and prover SRS points for C similarly.

As an optional tweak, I'd propose that verifier SRS public input points should be at least partially constructed via hash-to-curve before running the SRS. We then add one additional prover SRS point for C for each public input point like this, which expresses the actual wiring and binds the hashed-to-curve public input points into the circuit.

We could then construct arbitrary circuits in the future which have (some of) the same public inputs as older circuits, which then simplifies using diverse Groth16 circuits within another proof system like SnarkPack.

We likely fix gamma=1 when doing this, but then each new circuit has its own fresh delta, making [delta]_2 possibly the unique place where SnarkPack proves correctness of the Groth16 circuits used. It's likely the groth16 crate only needs support for circuit Independence of public input SRS points though, and anything else can happen in other crates.

I'll likely convince someone in-house to work on this, but we'll want to upstream the changes, and this issue might spark useful conversation.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant