Field-to-ring evaluation reduction
This page explains the first correctness obligation of an Akita opening: given the partial evaluations produced by the scheduled opening method, how do public weights recombine them into the scalar claim carried by the protocol?
Start with the base-field specialization
Here both the polynomial table and the opening point are defined over the base field . Akita commits the table through the cyclotomic ring
The schedule chooses one of two opening methods. EvaluationTrace keeps one
full element per live block and finishes the inner contraction
with TraceOpen. SubringCoefficientPacking contracts part of the inner axis
earlier and keeps a shorter polynomial over the opening field. In
both cases the result is a field-valued linear relation on the committed
opening digits:
| Opening method | Partial carried into the fold | Scalar target bound here |
|---|---|---|
EvaluationTrace | full-ring | the trace target; it equals in the base-field case |
SubringCoefficientPacking | shorter | the original extension-valued |
For a proper extension-field point, EvaluationTrace first uses
extension-opening reduction, or EOR, and
the derivation below applies to the reduced trace target. Coefficient packing
instead binds the original extension-valued opening directly. The
fold-path overview states where the schedule uses each
method.
The evaluation problem
Choose a ring dimension and a power-of-two number of positions per block. Re-index the polynomial table as
where:
- is an inner index that will become a ring coefficient;
- is a position inside a block; and
- is a block index.
Missing entries in a partial final block are public zeros.
Split the opening point in the same order:
Write the corresponding interpolation weights as
For a multilinear opening in the Lagrange basis, these are equality weights:
The evaluation claim is therefore
Akita evaluates the three axes in the order
Reduce to a ring-valued evaluation
Pack the inner axis into ring coefficients
For each position and block , pack the inner slice into a ring:
This is only a change of representation. The table entry becomes the coefficient of .
Equivalently, the values form a ring-valued multilinear table
This is the same underlying table under a lossless coefficient packing, not a new witness. The ring polynomial has fewer variables and is opened at
whose base-field coordinates act as constant elements of .
Evaluate the ring polynomial
First evaluate the position coordinate independently inside every block:
The coefficient of in is
Next evaluate the block coordinate:
Thus Equation (4) is the ring-based evaluation claim
Now
Thus contains the polynomial after evaluating the position and block parts of . Only the inner coordinate remains.
Pack the inner opening weights
Pack the remaining weights into a second ring:
The two rings have different sources:
| Ring | Derived from | Meaning |
|---|---|---|
| , , and | the polynomial after the two outer folds | |
| the weights for the remaining inner fold |
Using Equation (5), the original evaluation can already be written as
Recover the evaluation with TraceOpen
Let be the ring automorphism
For any , define
where denotes the constant coefficient in .
If
then the matching terms in are
They contribute to the constant coefficient, giving
Applying this definition to and using Equation (7),
Therefore:
TraceOpen is a coefficient pairing. It is not the univariate evaluation
used to reduce ring-valued relations to the field.
Eliminate the intermediate ring evaluation
Hachi: expose
The baseline Hachi protocol exposes and checks two statements:
and
The first statement proves that is the correct evaluation of the ring-valued polynomial. In this fold, each is digit-decomposed into the committed partial-evaluation witness:
where are the digit rings and are public gadget weights. Substituting this decomposition into Equation (12) gives
Equation (15) is a relation over the ring that enforces consistency between the ring element and the witness polynomials . Hachi sends to the verifier, which checks Equation (13) directly. The prover then proves Equation (15) using the same ring-relation machinery as the other constraints that bind the previous witness to the next witness, as described in Semantic relations in an Akita fold.
Akita: compose the two checks
Akita's crucial observation is that is already determined linearly by the
committed partial-evaluation witness and that
is itself a linear map. Sending would
therefore introduce a redundant ring element, an extra interface between the
two checks, and additional verifier work. Akita instead composes the two
linear maps and applies TraceOpen directly to Equation (15):
Write each digit ring as
and define the public inner trace weight
By linearity,
Equation (16) becomes the direct evaluation-consistency relation
In the base-field setting, Equation (9) gives
Thus every factor in Equation (18) has a simple role:
- recomposes the digit planes;
- evaluates across blocks; and
- evaluates inside the packed ring.
This row acts on the committed partial-evaluation digits . The other fold relations bind those digits back to the original committed polynomial.
The two possible protocol views are:
Expose Y:
committed ê ──recompose──> E_b ──block fold──> Y
│
TraceOpen
│
v
Eliminate Y:
committed ê ───────composed public linear map──────> v
Express the direct relation as a sumcheck claim
The committed fold witness is stored as one flat table . Flatten the indices into a Boolean address , and define the public weight function
Then Equation (18) is
This is the evaluation-correctness relation consumed by the later sumcheck protocol. It is already a field-valued linear relation on the committed witness. It therefore needs neither evaluation at nor a ring-switch quotient. This fact concerns only the scalar opening row. Quotient-free ring checking is a separate method for converting the physical ring equations into field claims. Those equations must still bind the partials to the committed source.
Subring coefficient packing: shorter partials
The evaluation-trace partial retains all inner coefficients. Subring coefficient packing shortens this partial by contracting one part of the inner axis before the opening digits are formed.
Return now to the general case in which the opening point lies in a field containing ; the interpolation weights , , and are then -valued. The case is included. Let
Choose a retained-axis dimension —later also the challenge-subring dimension—and write
Here is the packing factor. The implementation and specification call this value ; this page uses so that it cannot be confused with the opening-digit index already used in the evaluation-trace derivation. Every inner coefficient index has a unique form
Split the inner opening point in the same order:
The tensor-product interpolation weight therefore factors as
The index is contracted now; remains explicit. It helps to see this as a two-dimensional coefficient table rather than one flat list. For a fixed block , first apply the position weights and write
The rows are indexed by the coefficient that will remain in the packed partial. The columns are indexed by , which is consumed now:
| retained row | after contracting the row | ||||
|---|---|---|---|---|---|
The table is not a new witness. It is only a view of the position-folded source coefficients. Contracting one row gives
For example, take , , , and . Then , so the flat inner coefficients become two rows:
j = 0: ell = 0 1 2 3 -> e[b,0]
j = 1: ell = 4 5 6 7 -> e[b,1]
Each row is contracted to one element of the degree-two field . The packed partial therefore contains two elements of , or four base-field coordinates, instead of all eight source coefficients.
Substituting Equations (24) and (25) into the original multilinear evaluation gives
Thus the early contraction loses no part of the claimed evaluation. It only splits the old inner contraction into two stages: is consumed while the partial is formed, and is consumed in the final scalar relation.
Package the retained coefficients as
The ring has coefficients in . Fix the canonical -basis of and write
Consequently one packed partial has base-field coordinates, rather than the coordinates of . The basis elements are fixed by the canonical extension-field representation; they are not transcript challenges or schedule choices.
The next witness stores balanced digits of these base-field coordinates. Use for the opening-digit index:
Substituting Equations (28) and (29) into Equation (26) gives the direct packed opening relation
Read Equation (30) from the inside out. The opening gadget weights rebuild each base-field coordinate from its digits. The basis elements rebuild the extension-field coefficient . The tail weights consume the retained rows, and the block weights combine the live blocks. The result is the original scalar opening .
This is an -valued virtual row on the committed digit witness. It is not a ring-matrix row and has no cyclotomic quotient. Claim batching and Stage-2 row batching multiply the displayed weights by additional public scalars, without changing the single-claim identity.
At this scalar layer, the two methods have the same high-level output: a public linear map from the method-selected opening digits to the scalar target. They use different digit geometries and different public maps.
What scalar correctness does not prove
Equations (21) and (30) answer the scalar question under one assumption: the partials or are the correct partial evaluations of the incoming committed polynomial. The equations do not establish that assumption. A prover could otherwise choose unrelated partials that satisfy the scalar equation.
The next chapter supplies the missing source-consistency statement. Rather than check every block independently, Akita samples random fold challenges and batches the blockwise equations into one relation on the folded response . The two method-dependent shapes are
and
Semantic relations in an Akita fold derives both relations. In particular, it explains why the packing challenges must act only on the retained axis. Checking ring relations over a field comes later, after this semantic relation and its physical rows are established. Sumcheck stages explains how the method-selected scalar relation is row-batched and fused with the other Stage-2 terms.
Opening-method code reference
Evaluation trace
This subsection applies when the schedule selects EvaluationTrace. A fold
that selects SubringCoefficientPacking uses the coefficient-packing flow in
the following subsection instead.
The CPU backend performs the private opening arithmetic. The base-field path follows the reduction above:
- Prepare the opening weights.
prepare_opening_pointconstructs , , and . - Evaluate the ring polynomial.
evaluate_claims_at_prepared_pointreturns the position-folded rings and the temporary ring . - Recover the scalar evaluation.
scalar_opening_from_folded_ringcomputes . - Prepare the trace factors.
prepare_evaluation_trace_group_parametersprepares the block point underlying , the gadget weights , and the inner trace weights . - Construct the trace weights.
build_evaluation_trace_weightscombines those factors with the claim coefficients and physical locations to construct . - Fuse the Stage-2 relation.
accumulate_fused_relation_linear_signedadds the prepared linear relation to the fused Stage-2 sumcheck.
PreparedFold::relation_groups retains one method-selected point and the
scalar openings for each group as PreparedRelationGroupPublic metadata.
For evaluation trace, PreparedRelationGroupPublic::kind() gives the prepared
, , and factors. PreparedFold::witness_handle is an opaque handle
to the backend-owned digit witness. Protocol orchestration can use the public
weights but cannot inspect the private opening digits through that handle.
The main data flow is:
opening point r
|
v
PreparedOpeningPoint: weights Q_p, B_b, P
|
v
OpeningFoldOutput
|-- folded: [E_b] -- digit decomposition --> e_hat in witness w
`-- eval: Y ------- TraceOpen_P ----------> v_tr
|
v
PreparedFold
|-- evaluation_trace_claim: v_tr
|-- relation_groups: method-selected points and scalar openings
|-- evaluation_trace_claim_coefficients: c_q
`-- witness_handle: opaque backend-owned digit witness
|
v
prepare_evaluation_trace_group_parameters
|
`-- public factors B_b, G_h, J_l
|
v
build_evaluation_trace_weights
|
`-- T(x) on the committed e_hat segment
|
v
accumulate_fused_relation_linear
|
`-- Stage 2 proves v_tr = sum_x w(x) T(x)
In the base-field case, calling as_base() on
PreparedOpeningPoint::ring_multiplier_point returns Some(base_point).
The table uses base_point for the contained RingOpeningPoint reference.
The main values are:
| Code value | Mathematical object |
|---|---|
base_point.position_weights in the base-field case | |
base_point.live_block_weights in the base-field case | |
PreparedOpeningPoint::packed_inner_trusted() | |
OpeningFoldOutput::folded | |
OpeningFoldOutput::eval | temporary |
PreparedEvaluationTraceClaim::claimed_evaluation | |
PreparedEvaluationTraceClaim::claim_coefficients | claim-batching coefficients |
RingRelationGroupWitness::folded_opening, in its EvaluationTrace variant | position-folded rings |
RingRelationGroupWitness::e_hat | digit rings |
PreparedFold::evaluation_trace_claim | carried into Stage 2 |
PreparedFold::relation_groups, through PreparedRelationGroupPublic::kind() | prepared , , and for each evaluation-trace group |
PreparedFold::witness_handle | opaque handle to the backend-owned digit witness, including the opening digits |
PreparedFold::evaluation_trace_claim_coefficients | carried into trace-weight construction |
EvaluationTraceGroupParameters::shared_block_opening_point | block point from which is evaluated |
EvaluationTraceGroupParameters::opening_digit_weights | |
EvaluationTraceGroupParameters::shared_inner_trace | , equal to in the base-field case |
EvaluationTraceWeights |
The temporary ring is used only to compute ; it is not
stored in PreparedFold or sent to the verifier. Stage 2 instead proves
directly from the committed digit witness.
Subring coefficient packing
The implementation follows the same derivation in three stages:
- Prepare the point.
PreparedSubringCoefficientPackingPointchecks and prepares the packing, tail, position, and block weights. - Pack and bind the partials.
The prover contracts the and axes to obtain the coordinates
in
[block][extension coordinate][subring coefficient]order. It recombines those coordinates as in Equation (30), then binds their digit decompositions before sampling the fold challenges. - Fold and verify.
fold_coefficient_packing_groupfolds the packed partials and produces . Stage 2 then checks both the packing relation and the direct scalar opening, using to rebuild each extension-valued coefficient.
The reference tests in
coefficient_packing_fold_tests.rs
compare the direct partial and scalar formulas with the flat factorization.
The Stage-2 tests in
coefficient_packing_relation_tests.rs
check the expanded prover terms and that every extension-coordinate plane is
bound. The verifier tests in
coefficient_packing_relation/tests.rs
compare the compact evaluation with dense oracles built from those expanded
terms.
Base-field polynomial at an extension-field point
The scheduled opening method determines this case.
With EvaluationTrace, Akita does not treat a base-field multilinear
polynomial as an ordinary extension-valued opening of the same arity. It first
runs the extension-opening reduction. The
low variables are packed into extension-field
coefficients, and one degree-two tensor sumcheck reduces the original claim to
a claim on that packed polynomial with fewer variables. The reduced claim then
enters the evaluation trace. The trace represents its extension weights by
canonical subfield coordinates, and the verifier rejects invalid shapes,
coordinate counts, and noncanonical images before using them. Configurations
with skip this reduction.
With SubringCoefficientPacking, Akita keeps one coefficient axis in the
challenge subring, contracts the other axes over the extension field, and
binds the original scalar opening directly in Stage 2 without EOR. The
derivation is in Subring coefficient packing: shorter
partials; Fold path and field
geometry states the schedule boundary.