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

chore: Remove Params concept #1541

Merged
merged 7 commits into from
Aug 14, 2023
Merged

chore: Remove Params concept #1541

merged 7 commits into from
Aug 14, 2023

Conversation

ledwards2225
Copy link
Contributor

@ledwards2225 ledwards2225 commented Aug 11, 2023

The Params concept, originally introduced by Adrian, was outdated and largely superseded by the Flavor concept. It previously specified the Curve, various Curve subtypes, and defined CommitmentKey and VerificationKey for different PCS suites. The information contained in Params was redundant and confusing and led to issues in my work on the recursive verifier. This work:

  • Defines CommitmentKey and VerificationKey in unique files as single classes templated by Curve with appropriate specializations
  • Removes the concept of Params altogether (along with the poorly named commitment_key.hpp). Things previously templated by Params are now templated by Curve. (The new commitment_key.hpp now just contains.. the CommitmentKey)
  • Specifies the Curve, CommitmentKey, and PCSVerificationKey directly in the Flavor classes

Checklist:

Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.

  • If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag.
  • I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code.
  • Every change is related to the PR description.
  • I have linked this pull request to relevant issues (if any exist).

@ledwards2225 ledwards2225 changed the title Lde/params refactor chore: Lde/params refactor Aug 11, 2023
@ledwards2225 ledwards2225 changed the title chore: Lde/params refactor chore: Remove Params concept Aug 11, 2023
@ledwards2225 ledwards2225 self-assigned this Aug 11, 2023
Copy link
Collaborator

@ludamad ludamad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. When you say concept do you just mean common type shape passed throughout? I was somewhat expecting e.g. template <CurveLike Curve> with a CurveLike C++ concept

@ledwards2225
Copy link
Contributor Author

LGTM. When you say concept do you just mean common type shape passed throughout? I was somewhat expecting e.g. template <CurveLike Curve> with a CurveLike C++ concept

Hah no I meant it in the colloquial sense. I was conscious of the potential confusion as I was typing the word. Probably time I drop it from my vernacular.

@ludamad
Copy link
Collaborator

ludamad commented Aug 12, 2023

Hah no I meant it in the colloquial sense. I was conscious of the potential confusion as I was typing the word.
Probably time I drop it from my vernacular.

At least when discussing template parameters maybe :D

Copy link
Contributor

@maramihali maramihali left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really great work cleaning this up :) I just had some comments relating documentation and naming.

using PCSCommitmentKey = typename PCSParams::CommitmentKey;
using PCSVerificationKey = typename PCSParams::VerificationKey;
using PCSCommitmentKey = typename Flavor::CommitmentKey;
using PCSVerificationKey = typename Flavor::PCSVerificationKey;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here about naming

using GroupElement = Curve::Element;
using Commitment = Curve::AffineElement;
using CommitmentHandle = Curve::AffineElement;
using FF = Curve::ScalarField;
using Polynomial = barretenberg::Polynomial<FF>;
using PolynomialHandle = std::span<FF>;
using CommitmentKey = pcs::CommitmentKey<Curve>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we have either both of these name with or without the PCS prefix (I think we can do without without clashing with anything else).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Decided to change these to CommitmentKey and VerifierCommitmentKey. We already have a VerificationKey so that language is ambiguous even with the PCS prefix. The verifier is actually using this object to compute commitments (in the full sense in IPA but also in Shplonk) so I think the name is appropriate and more descriptive. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, sounds reasonable!

using GroupElement = Curve::Element;
using Commitment = Curve::AffineElement;
using CommitmentHandle = Curve::AffineElement;
using FF = Curve::ScalarField;
using Polynomial = barretenberg::Polynomial<FF>;
using PolynomialHandle = std::span<FF>;
using CommitmentKey = pcs::CommitmentKey<Curve>;
using PCSVerificationKey = pcs::VerificationKey<Curve>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and here

@@ -23,239 +23,55 @@

namespace proof_system::honk::pcs {

namespace kzg {
/**
* @brief CommitmentKey object over a pairing group 𝔾₁, using a structured reference string (SRS).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only applicable for KZG, for IPA the srs is random points in G_1


/**
* @brief Simulates a KZG CommitmentKey, but where we know the secret trapdoor
* which allows us to commit to polynomials using a single group multiplication.
* @brief Uses the ProverSRS to create a commitment to p(X)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, there are comments about the SRS for IPA in the ipa namespace of the previous version.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Corrected. thanks

using Commitment = typename Params::Commitment;
template <typename Curve> class GeminiVerifier_ {
using Fr = typename Curve::ScalarField;
using GroupElement = typename Curve::Element;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have strong opinions between Element and GroupElement for the projective form. I found both of them rather unintuitive. I much prefer ProjectiveElement and AffineElement but this is open for discussion

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I was just going with what was there. I don't have strong feelings either so unless you do I;ll just leave it for now

@iAmMichaelConnor iAmMichaelConnor added the crypto cryptography label Aug 14, 2023
@ledwards2225 ledwards2225 merged commit f4bd85e into master Aug 14, 2023
@ledwards2225 ledwards2225 deleted the lde/params_refactor branch August 14, 2023 16:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crypto cryptography
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants