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

[low priority] Univariate KZG in evaluation form #339

Open
Tracked by #358
ggutoski opened this issue Jul 4, 2023 · 1 comment · May be fixed by #468
Open
Tracked by #358

[low priority] Univariate KZG in evaluation form #339

ggutoski opened this issue Jul 4, 2023 · 1 comment · May be fixed by #468
Assignees
Labels
cappuccino optimize-vid https://www.notion.so/espressosys/9d835f79d4504926b8b3bb3d015abf06?v=b7028cdaea804b7aa918af95c0cd651 stretch vid

Comments

@ggutoski
Copy link
Contributor

ggutoski commented Jul 4, 2023

In some applications of univariate KZG the polynomial is given in evaluation form (as d evaluations p(1),...,p(d) of polynomial p at input points 1,...,d) instead of the conventional coefficient form (as d coefficients of p). Example: KZG as a vector commitment.

Currently we enforce coefficient form at the API level: commit, open and their batch/multi variants all require a Self::Polynomial in coeff form:

fn open(
prover_param: impl Borrow<<Self::SRS as StructuredReferenceString>::ProverParam>,
polynomial: &Self::Polynomial,
point: &Self::Point,

This API can be used for polynomials in evaluation form, but it forces the user to do a bunch of unnecessary and expensive FFTs.

It is possible to do all KZG operations natively in evaluation form, with no need for FFT anywhere in the stack: see here. (Skip to "evaluation form" section.)

Suggestions

  1. Low-level. Add a mirror API that accepts polynomials in evaluation form. This is a good opportunity to coordinate with Eliminate mem allocation/copy in PCS API #338
  2. High-level. Same API. Set Self::Polynomial to a type that abstracts over the underlying representation (coeff vs. eval). Methods such as commit, open, etc select the underlying implementation according to the underlying polynomial representation.

I prefer a low-level solution such as item 1 but that's open to discussion.

@ggutoski ggutoski self-assigned this Jul 4, 2023
@ggutoski ggutoski added the vid label Nov 13, 2023
@jbearer jbearer added cappuccino optimize-vid https://www.notion.so/espressosys/9d835f79d4504926b8b3bb3d015abf06?v=b7028cdaea804b7aa918af95c0cd651 labels Jan 9, 2024
@ggutoski ggutoski changed the title Univariate KZG in evaluation form [low priority] Univariate KZG in evaluation form Jan 19, 2024
@alxiong
Copy link
Contributor

alxiong commented Jan 20, 2024

as weekend fun, I wrote down how I think KZG in eval form should work here: https://www.notion.so/espressosys/KZG-in-Evaluation-Form-c58004c5ca7f427f92799aaeea7c6e1a

literature note, Dankrad has indeed described how KZG in eval form should work in his blog post linked above, but he only consider the special case when the polynomial degree d equals to the supported degree in SRS setup n.

where what I wrote is more general for any d<=n, which give rise to two flavors of KZG, one with shorter SRS, one with faster commit.

cc @chancharles92 @ggutoski

again, agree this should be super low priority, given the requirement on new trusted setup for the SRS.


update: I think I was mistaken, we don't know new SRS, we can compute the Lagrange poly (of trapdoor) using linear combination of the coefficient form SRS values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cappuccino optimize-vid https://www.notion.so/espressosys/9d835f79d4504926b8b3bb3d015abf06?v=b7028cdaea804b7aa918af95c0cd651 stretch vid
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants