Cg/flavor

[codygunton]

Description

This PR introduces a framework for clearly and modularly specifying Honk variants, which we call "flavors". Some things that determine a Honk variant are:

• The number and interpretation of its "wires", vectors (later, polynomials) containing a prover's witness data.
• The number and interpretation of its "selectors", vectors that describe how a tuple of adjacent witness values are constrained. Specifying this also also means specifying "relations" (called "widgets" in plonk) that execute bits polynomial (resp., field) arithmetic expressions during proving (resp., verification)
• The curve that will be used in the protocol. This choice determines the scalar field FF ($\mathbb{F}$ of the PlonK paper) and the group G1 ($\mathbb{G}_1$ in the paper). Currently we use BN254, but in the short term we would like to use its cycle companion Grumpkin, and longer-term we may use another cycle of curves altogether.
• Whether or not use a full zk-SNARK protocol, or simply a SNARK variation. We will sometimes switch off zk for efficiency, as it is not needed at every step of our proving system stack to provide Aztec users full privacy.

Our foremost goals are clarity for future audits and to help us build out a complicated stack of proving systems involving multiple kind of recursion and boutique Honk variants dedicated to a particular task. We also aim to evolve the PlonK architecture to the needs of Honk, resolving old tech debt along the way.

Some of the key points of this PR:

• A flavor is a class exposing:
  • Type aliases describing: the nature and interpretation of the execution trace; the underlying curve; the polynomial commitment scheme.
  • Global values such as the number of selectors in a given flavor.
  • Class definitions (not instances) describing fundamentally related data structures underlying the protocol, including containers for: the precomputed data; the witness data; commitments; handles on the preceding data; groups of particular interest of the preceding data. Once we chose a flavor, the prover's and verifier's algorithms are written using data structures descrived in the flavor.
• The flavor aims to use basic OOP to reduce boilerplate (hence to reduce opportunities for subtle differences to develop between the flavors), to localize protocol-defining data to a place where it is easy to find and readable, and to address loose coupling of various related structure in plonk (where it was often hard to tell/remember whether, say, if and how to structures were related). Related quantities (e.g., a wire vector, its polynomial extension, a purported/claimed value of that extension, and its commitment) are stored and accessed in a uniform manner. Protocol-specifying information is put in one place, making it easier to 'see' the protocol at a glance and to compare our different variants.
• As a knock-on effect, many "library functions" (functions shared between variants, or even shared with PlonK) that were templated in disparate and more minimal ways are now templated by flavor. We hope to make up in the loss of specificity is compensated by explicitness elsewhere.
• By embracing the use of higher level stuctures (classes and stl containers over global variables and enums) we get more readable and safer code (e.g., less verbose code that uses ranged for loops).
• Various pieces of cleanup: functions were renamed for clarity; variables were named for clarity (e.g., program_width was renamed to NUM_WIRES for Honk, since this is more explicit and useful at a glance); template parameters were consolidated.

Checklist:

• I have reviewed my diff in github, line by line.
• Every change is related to the PR description.
• I have linked this pull request to the issue(s) that it resolves.
• There are no unexpected formatting changes, superfluous debug logs, or commented-out code.
• There are no circuit changes, OR specifications in /markdown/specs have been updated.
• There are no circuit changes, OR a cryptographer has been assigned for review.
• I've updated any terraform that needs updating (e.g. environment variables) for deployment.
• The branch has been rebased against the head of its merge target.
• I'm happy for the PR to be merged at the reviewer's next convenience.
• New functions, classes, etc. have been documented according to the doxygen comment format. Classes and structs must have @brief describing the intended functionality.
• If existing code has been modified, such documentation has been added or updated.

[codygunton]

^ Rebase over #142. Won't build bc last commit is a WIP where only proof_system builds.

[codygunton]

^rebase over #352

[maramihali]

I'm a bit confused - I thought the idea is we have a single HonkComposer/HonkComposerHelper/CircuitConstructor interface with the Flavour telling us whether we use Standard, Ultra or Turbo implementation. Why do we need to keep this classes?

[codygunton]

We don't want a single class template that gives all circuit constructors, composers, provers, verifiers by specifying a single flavor template argument because then we end up with complicated conditional logic, like we have in the plonk prover, where (after non-trivial effort) you can find that one of the rounds is actually a no-op except in the case of UltraComposer. We're trying to strike a balance between explicitness and code reuse. I think we're a bit too far on the side of duplication at the moment, but the general direction is very good.

[Rumata888]

Yes, I think it would be better

[codygunton]

I made an issue #426

[Rumata888]

Could be nice to add a failing version to show that sumcheck is doing its job

[codygunton]

I added a small failure case, but more thorough testing (of everything honk-related) is definitely needed.

[Rumata888]

This is very non-descript. Could you add a minimal description of what this test intends to achieve and how?

[codygunton]

Vague, I agree. I renamed and added some comments. The main point is to test whether you can set a value through an entitiy name and then access that value through the spans produced by a getter.

[codygunton]

^ merge PR with aztec tests

[codygunton]

I think I made some of my comments actually be part of a review? They're marked as pending. Submitting just in case.

[codygunton]

Again, I think I made some of my comments actually be part of a review? They're marked as pending. Submitting just in case.