flavor.hpp File Reference

Base class templates for structures that contain data parameterized by the fundamental polynomials of a Honk variant (a "flavor"). More...

#include "barretenberg/common/ref_vector.hpp"
#include "barretenberg/common/std_array.hpp"
#include "barretenberg/common/std_vector.hpp"
#include "barretenberg/common/zip_view.hpp"
#include "barretenberg/polynomials/barycentric.hpp"
#include "barretenberg/polynomials/evaluation_domain.hpp"
#include "barretenberg/polynomials/univariate.hpp"
#include "barretenberg/proof_system/types/circuit_type.hpp"
#include <array>
#include <concepts>
#include <vector>

Go to the source code of this file.

Classes
class	proof_system::honk::flavor::PrecomputedEntitiesBase
	Base class template containing circuit-specifying data. More...
class	proof_system::honk::flavor::ProvingKey_< PrecomputedPolynomials, WitnessPolynomials >
	Base proving key class. More...
class	proof_system::honk::flavor::VerificationKey_< PrecomputedCommitments >
	Base verification key class. More...

Namespaces
namespace	proof_system::honk
	Defines particular circuit builder types expected to be used for circuit construction in stdlib and contains macros for explicit instantiation.
namespace	proof_system::plonk

Concepts
concept	proof_system::IsPlonkFlavor
	Test whether a type T lies in a list of types ...U.
concept	proof_system::IsHonkFlavor
concept	proof_system::IsUltraFlavor
concept	proof_system::IsGoblinFlavor
concept	proof_system::IsRecursiveFlavor
concept	proof_system::IsGrumpkinFlavor
concept	proof_system::UltraFlavor
concept	proof_system::ECCVMFlavor

Functions
auto	proof_system::honk::flavor::get_unshifted_then_shifted (const auto &all_entities)
template<typename Container , typename Element >
std::string	proof_system::flavor_get_label (Container &&container, const Element &element)

Detailed Description

Base class templates for structures that contain data parameterized by the fundamental polynomials of a Honk variant (a "flavor").

#Motivation We choose the framework set out in these classes for several reasons.

For one, it allows for a large amount of the information of a Honk flavor to be read at a glance in a single file.

The primary motivation, however, is to reduce the sort loose of coupling that is a significant source of complexity in the original plonk code. There, we find many similarly-named entities defined in many different places (to name some: selector_properties; FooSelectors; PolynomialIndex; the labels given to the polynomial store; the commitment label; inconsistent terminology and notation around these), and it can be difficult to discover or remember the relationships between these. We aim for a more uniform treatment, to enfore identical and informative naming, and to prevent the developer having to think very much about the ordering of protocol entities in disparate places.

Another motivation is iterate on the polynomial manifest of plonk, which is nice in its compactness, but which feels needlessly manual and low-level. In the past, this contained even more boolean parameters, making it quite hard to parse. A typical construction is to loop over the polynomial manifest by extracting a globally-defined "FOO_MANIFEST_SIZE" (the use of "manifest" here is distinct from the manifests in the transcript) to loop over a C-style array, and then manually parsing the various tags of different types in the manifest entries. We greatly enrich this structure by using basic C++ OOP functionality. Rather than recording the polynomial source in an enum, we group polynomial handles using getter functions in our new class. We get code that is more compact, more legible, and which is safer because it admits ranged for loops.

Another motivation is proper and clear specification of Honk variants. The flavors are meant to be explicit and easily comparable. In plonk, the various settings template parameters and objects like the CircuitType enum became overloaded in time, and continue to be a point of accumulation for tech debt. We aim to remedy some of this by putting proving system information in the flavor, and circuit construction information in the arithmetization (or larger circuit constructor class).

#Data model All of the flavor classes derive from a single Entities_ template, which simply wraps a std::array (we would inherit, but this is unsafe as std::array has a non-virtual destructor). The developer should think of every flavor class as being:

• A std::array<DataType, N> instance called _data.
• An informative name for each entry of _data that is fixed at compile time.
• Some classic metadata like we'd see in plonk (e.g., a circuit size, a reference string, an evaluation domain).
• A collection of getters that record subsets of the array that are of interest in the Honk variant.

Each getter returns a container of HandleType's, where a HandleType is a value type that is inexpensive to create and that lets one view and mutate a DataType instance. The primary example here is that std::span is the handle type chosen for barrtenberg::Polynomial.

#Some Notes

Note

It would be ideal to codify more structure in these base class template and to have it imposed on the actual flavors, but our inheritance model is complicated as it is, and we saw no reasonable way to fix this.

One asymmetry to note is in the use of the term "key". It is worthwhile to distinguish betwen prover/verifier circuit data, and "keys" that consist of such data augmented with witness data (whether, raw, blinded, or polynomial commitments). Currently the proving key contains witness data, while the verification key does not. TODO(Cody): It would be nice to resolve this but it's not essential.

The VerifierCommitments classes are not 'tight' in the sense that that the underlying array contains(a few) empty slots. This is a conscious choice to limit complexity. Note that there is very little memory cost here since the DataType size in that case is small.

Todo:

TODO(#395): Getters should return arrays?

TODO(#396): Access specifiers?

TODO(#397): Use more handle types?

TODO(#398): Selectors should come from arithmetization.