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

#include "barretenberg/common/assert.hpp"
#include "barretenberg/common/ref_vector.hpp"
#include "barretenberg/common/std_array.hpp"
#include "barretenberg/common/std_vector.hpp"
#include "barretenberg/common/tuple.hpp"
#include "barretenberg/common/zip_view.hpp"
#include "barretenberg/constants.hpp"
#include "barretenberg/crypto/poseidon2/poseidon2.hpp"
#include "barretenberg/ecc/fields/field_conversion.hpp"
#include "barretenberg/honk/types/circuit_type.hpp"
#include "barretenberg/polynomials/barycentric.hpp"
#include "barretenberg/polynomials/evaluation_domain.hpp"
#include "barretenberg/polynomials/univariate.hpp"
#include "barretenberg/public_input_component/public_component_key.hpp"
#include "barretenberg/srs/global_crs.hpp"
#include "barretenberg/stdlib/hash/poseidon2/poseidon2.hpp"
#include "barretenberg/stdlib/primitives/field/field_conversion.hpp"
#include "barretenberg/stdlib/transcript/transcript.hpp"
#include "barretenberg/transcript/transcript.hpp"
#include <array>
#include <concepts>
#include <cstddef>
#include <numeric>
#include <utility>
#include <vector>

Classes
struct	bb::ActiveRegionData

struct	bb::MetaData
	Dyadic trace size and public inputs metadata; Common between prover and verifier keys. More...

struct	bb::PrecomputedData_< Polynomial, NUM_PRECOMPUTED_ENTITIES >
	The precomputed data needed to compute a Honk VK. More...

class	bb::NativeVerificationKey_< PrecomputedCommitments, Transcript >
	Base Native verification key class. More...

class	bb::StdlibVerificationKey_< Builder_, PrecomputedCommitments >
	Base Stdlib verification key class. More...

class	bb::VKAndHash_< FF, VerificationKey >

Namespaces
namespace	bb
	Entry point for Barretenberg command-line interface.

namespace	bb::avm2

Functions
auto	bb::get_unshifted_then_shifted (const auto &all_entities)

template<typename Tuple >
constexpr size_t	bb::compute_max_partial_relation_length ()
	Utility function to find max PARTIAL_RELATION_LENGTH tuples of Relations.

template<typename Tuple >
constexpr size_t	bb::compute_max_total_relation_length ()
	Utility function to find max TOTAL_RELATION_LENGTH among tuples of Relations.

template<typename Tuple >
constexpr size_t	bb::compute_number_of_subrelations ()
	Utility function to find the number of subrelations.

template<typename Tuple , size_t NUM_KEYS, bool optimized = false>
constexpr auto	bb::create_protogalaxy_tuple_of_tuples_of_univariates ()
	Utility function to construct a container for the subrelation accumulators of Protogalaxy folding.

template<typename RelationsTuple >
constexpr auto	bb::create_sumcheck_tuple_of_tuples_of_univariates ()
	Utility function to construct a container for the subrelation accumulators of sumcheck proving.

template<typename RelationsTuple >
constexpr auto	bb::create_tuple_of_arrays_of_values ()
	Construct tuple of arrays.

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 (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 between 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.

Definition in file flavor.hpp.

Classes

Namespaces

Functions

Detailed Description