[ ] 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.
[x] 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.
An integration attempt https://github.com/w3f/apk-proofs/issues/31 immediately showed a number of API deficiencies:
(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 makeopen
to return the evaluations together with the proof, or provide a separate convenience method.open
can take a list of combinations.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.AdditiveCommitment
forGroupAffine
likely requires a wrapper.ShplonkTranscript
for merlinTranscript
.[[f(x), g(x)], [f(y), g(y)]]
vs[[f(x), f(y)], [g(x), g(y)]]
in shplonk.