paritytech / paritytech/fflonk

API improvements

Open
#2 1 comment 0 reactions 1 assignee View on GitHub

@swasilyev is already working on this.

Since Jan 20, 2022.

Dominant language
Rust
Stars
31
Forks
16
PR merge metrics
No merged PRs in 30d

Description

An integration attempt https://github.com/w3f/apk-proofs/issues/31 immediately showed a number of API deficiencies:

  • 1. Though to produce an evaluation proof, the prover doesn't even need to compute the evaluation... Notice (f - f(y))/(X - y) = f/(X - y), where '/' stays for "get the quotient" as deg(f(y)) = 0 < 1 = deg(X-y). ...in most usecases prover has to supply the evaluations. So it make sense to make open to return the evaluations together with the proof, or provide a separate convenience method.
  • 2. In a similar vein, the combinations of polynomials are usually committed before generating the proof, so open can take a list of combinations.
  • 3. CommitmentScheme trait that both commits and verifies isn't practical as e.g. in KZG verifying an opening requires less parameter data than committing to the polynomial.
  • 4. Implementing AdditiveCommitment for GroupAffine likely requires a wrapper.
  • 5. 3rd party crate can't implement ShplonkTranscript for merlin Transcript.
  • 6. fflonk verification expects evaluations as a vec per an opening point (root), while shplonk -- as a vec per a polynomial. E.g. let have f and g opened in x and y. fflonk represents evaluations as [[f(x), g(x)], [f(y), g(y)]] vs [[f(x), f(y)], [g(x), g(y)]] in shplonk.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.