paritytech / paritytech/fflonk
API improvements
Open
@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" asdeg(f(y)) = 0 < 1 = deg(X-y). ...in most usecases prover has to supply the evaluations. So it make sense to makeopento 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
opencan take a list of combinations. - 3.
CommitmentSchemetrait 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
AdditiveCommitmentforGroupAffinelikely requires a wrapper. - 5. 3rd party crate can't implement
ShplonkTranscriptfor merlinTranscript. - 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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.