Introduction

Akita is a lattice-based polynomial commitment scheme, or PCS, implemented in Rust. Akita lets a prover commit to a large table and later prove an evaluation of the multilinear polynomial represented by that table. The verifier checks the proof without receiving the whole table. Akita uses transparent setup, so it needs no trusted ceremony. Its production parameters provide 128-bit post-quantum security under Module-SIS.

Akita's small proofs are one of its strongest advantages. Current production benchmarks produce opening proofs of roughly 65 to 80 KB. This contrasts with hash-based post-quantum polynomial commitment schemes, which produce proofs of hundreds of kilobytes at the same polynomial sizes Akita supports.

The codebase implements a standalone PCS that other proof systems can use. Its first major integration is Jolt, a zero-knowledge virtual machine, or zkVM, that proves the correct execution of 64-bit RISC-V programs.

Our claim: Akita is the first production-ready lattice-based polynomial commitment scheme. Earlier systems such as Greyhound showed that lattice commitments could be practical. Akita improves on that line of work and adds the validation, portability, verifier isolation, and integration work needed for deployment.

Why Akita exists

Many proof systems deployed today commit to their data with elliptic curve cryptography. Groth16, Plonk, and Bulletproofs are prominent examples. Their commitments are compact and well understood, but a sufficiently powerful quantum computer could break the assumptions behind them.

The commitment is often the part of the proof system that carries this assumption. The surrounding protocol checks polynomial identities using algebra and random challenges. Replacing the PCS with a post-quantum PCS can therefore protect the complete proof without replacing every other protocol in the system.

Hash-based commitments provide one post-quantum path. They are well developed, but they tend to produce larger proofs and require more prover memory. Akita takes the lattice path. It uses structured lattice problems to obtain post-quantum security, compact proofs, and a commitment operation that can preserve sparse inputs.

What a polynomial commitment proves

A proof system often represents a computation as one or more large tables. The prover has the tables. The verifier wants confidence in a calculation over them without downloading the tables or repeating the calculation.

The word polynomial describes how the proof system gives a table useful algebraic structure. A table with $2^n$ entries defines a multilinear polynomial with $n$ variables. Each variable appears with degree at most one. For example, eight table entries define a polynomial in three variables because three bits select one of eight positions.

The polynomial also has values away from those eight table positions. A larger proof system uses evaluations at such points to combine many table checks into a small number of claims.

A PCS gives the prover and verifier four operations:

The commitment fixes the data before the evaluation point is known. A valid opening should not let the prover change that data after seeing the point.

Akita currently exposes multilinear commitments. Its folding protocol needs tensor structure rather than multilinearity itself, so the same architecture can support a future univariate interface.

Why Akita uses lattices

The choice of commitment changes the security, proof size, prover work, and verifier work of the complete proof system.

Akita writes each field value as small signed digits and multiplies those digits by a public matrix. A zero digit contributes nothing to that product. The prover can therefore keep sparse polynomials sparse instead of first expanding them into a dense encoding. This is useful for one-hot tables such as those created by Jolt memory checks.

Module lattices also connect Akita to the direction taken by post-quantum cryptography more broadly. NIST standardized module lattice systems ML-KEM for key establishment and ML-DSA for signatures. Akita brings module lattice algebra to polynomial commitments, which makes it a natural commitment layer for proof systems that need to reason about post-quantum protocols.

The Why lattices? chapter develops this comparison, the sparse advantage, and the protocol lineage in more detail.

How Akita makes the proof small

Akita combines lattice commitments with repeated folding. A fold replaces one large claim with a smaller claim that has the same form. The proof records why the replacement is valid. Akita can then apply the same step again instead of sending evidence proportional to the original table.

First, the prover commits to small signed digits using public matrices over polynomial rings. Binding rests on Module-SIS. Informally, Module-SIS says that it is hard to find a short nonzero input that a public matrix maps to zero.

Second, Akita follows a fold schedule. This is a plan that says how large each intermediate claim will be and which security limits the verifier will enforce.

The benchmark suite currently tests 13 cases. Each case fixes the arithmetic field and the shape of the polynomial data. It also fixes how many polynomials are opened and how the prover handles the public setup calculation. Twelve cases use seven fold levels. A fold level means one reduction step. The seventh level is the terminal fold, where the verifier checks the remaining response directly. One benchmark case divides the work into eight chunks during its first two steps and uses eight fold levels in total.

For a concrete example, consider the benchmark that opens one dense polynomial over Akita's 128-bit field. Dense means that every position in the polynomial's table may contain an arbitrary element of that field. This polynomial has 28 variables, so its table contains $2^{28}=268,435,456$ field values. The fold schedule reduces the data that remains to be checked as follows:

The first six levels send a new commitment and a few small field values. They also send short algebraic proofs, called sumchecks, that connect the next claim to the previous one. Those messages occupy 19,912 bytes in this benchmark case. L6 performs the terminal check, adds a 4-byte number used when choosing the folding challenge, and sends the remaining response directly. The complete fold payload is therefore 19,916 bytes.

That complete proof is 73,018 bytes. Its 53,102-byte terminal response contains three parts:

Another fold is useful only when the bytes it removes from this remaining response exceed the bytes needed to prove the extra fold. The planner stops at the least expensive valid point. Across the latest complete profile run, all 13 production cases passed with proofs from 66,600 to 79,527 bytes. The benchmark report guide explains how to inspect the current totals and the byte cost of every fold.

Finally, the verifier checks the selected schedule, replays the same transcript, checks every fold, and verifies the clear terminal response before it accepts the claimed evaluation.

Akita does not need a trusted ceremony or a secret trapdoor. The prover may cache expanded public setup for speed, but correctness does not depend on anybody keeping a setup secret. The current PCS proof is not itself zero knowledge. Applications that require witness privacy must account for that boundary. The zero-knowledge roadmap describes the planned privacy layer.

The How it works section follows the complete protocol from configuration through setup, commitment, folding, and verification. The security model gives the exact Module-SIS assumptions and parameter checks.

Built as a complete system

Akita treats deployment engineering as part of the cryptographic design. The repository ships external schedule artifacts, checked security parameters, a separate verifier package, canonical proof encoding, and portable optimized arithmetic. The verifier rejects malformed public input with structured errors instead of panicking. The prover preserves sparse inputs and streams selected matrix operations in bounded chunks.

Memory is another scaling advantage. An arbitrary dense source still occupies one field element per table entry, but Akita can take ownership of that buffer instead of copying the complete table. Its folding schedules replace the source with progressively smaller intermediate data. For large supported tables, the prover's working memory beyond the source polynomial grows more slowly than the polynomial itself. This is in contrast to standard hash-based PCS provers, which usually materialize an encoded word and a hash tree during commitment, then retain both to answer later openings. The memory for those objects grows linearly with the polynomial size.

The 65 to 80 KB figures cover the Akita commitment proof. The host proof system contributes its own proof data.

Jolt is the first demanding host for these boundaries. It exercises Akita inside another verifier and accounts for proof bytes, verification work, memory, serialization, and guest failures as one integration problem. The same interfaces are designed for other proof systems to adopt.

The Built for production chapter explains the engineering evidence behind the production-ready claim. The Reviewing and auditing Akita chapter maps the security boundaries to the code, generated artifacts, and tests that enforce them.

Continue through the Book

Choose the next section by what you want to do:

The Book explains each mechanism before pointing to its implementation. Current code is the authority for runtime behavior. Live specifications record accepted designs that have not yet been fully folded into the Book, while archived specifications record history rather than current requirements.

Why lattices?

Akita uses structured lattices because they offer more than post-quantum security. Their algebra fits polynomial commitments. Linear operations can preserve sparse data, while ring structure supports the fast arithmetic needed by a large prover.

This chapter explains that choice in the wider commitment landscape.

The polynomial commitment carries the assumption

Many proof systems check polynomial identities using algebra and random challenges. Those checks do not need an elliptic curve hardness assumption. The PCS fixes the polynomials and later proves their evaluations. In these systems, the PCS is the part that introduces the computational assumption.

This division gives system designers a focused post-quantum upgrade path. They can replace a curve-based PCS with Akita while preserving much of the protocol that constructs and checks the polynomial identities.

When the PCS is the host system's main computational assumption, replacing it with Akita changes the security of the complete proof. Any additional computational assumptions in the host must provide their own post-quantum security.

Three polynomial commitment approaches

The main approaches make different choices about proof size, setup, and prover work.

Elliptic curves and pairings

Curve-based commitments support very small proofs and fast verification. This has made them a common choice in deployed systems such as Groth16 and Plonk. Their binding rests on discrete logarithm assumptions that a large quantum computer could break. Some pairing-based systems also require a trusted setup ceremony.

Hash functions

Hash-based commitments use a conservative post-quantum foundation and need no trusted setup. A prover usually encodes the complete object and commits to it with a hash tree. An opening includes authentication paths through that tree.

This design is general, but it moves substantial data. The prover must hash the dense encoding, and the proof carries the paths needed to authenticate opened positions. These costs are a major part of the proof size and memory traffic in many post-quantum proof systems.

In a standard in-memory prover, the encoded word and hash tree require memory that grows linearly with the polynomial size. A prover can reduce RAM by recomputing data or moving it to external storage, but then pays more work or disk traffic.

Structured lattices

A lattice commitment applies a public linear map to a representation with small coefficients. Akita performs that map over polynomial rings. The ring structure turns large matrix products into fast polynomial operations, while the small coefficient bounds provide the binding statement priced by Module-SIS.

This gives Akita a transparent commitment with post-quantum security and useful algebra. Every layer agrees on the exact dimensions, decomposition ranges, challenge distributions, and accepted response bounds. Akita makes those choices explicit in generated schedules and validates them at the verifier boundary.

Sparse data stays sparse

Akita first decomposes a field value into small signed digits. It then multiplies those digits by a public matrix. A zero digit adds nothing to the result, so the prover does not need to process it as a nonzero matrix input.

This property is important for a one-hot polynomial. Divide its evaluation table into blocks. Each block contains one value equal to one, and every other value is zero. A dense encoding stores every zero. A hash tree also hashes every encoded position. Akita can store the hot positions and perform commitment work for the nonzero digits.

Jolt memory checking creates tables with this structure. Akita provides one-hot polynomial sources and generated one-hot configurations for them. The same principle applies to other applications whose committed data has a sparse representation.

Sparse input does not make every later proof operation sparse. Folding combines values and can produce dense intermediate witnesses. The gain begins at the commitment boundary and continues wherever the operation can preserve the sparse representation. The prover code makes each transition explicit instead of hiding it behind a dense polynomial interface.

Ring structure supports fast arithmetic

Akita groups coefficients into elements of a polynomial ring. Public matrices then become matrices of ring elements rather than unstructured scalar matrices. The implementation uses number theoretic transforms to multiply these ring elements quickly.

The selected schedule may use different ring dimensions for different matrix roles and fold levels. Larger rings reduce the number of independent matrix entries, but they also change transform cost, exact arithmetic bounds, and available parallelism. The offline planner compares those costs and emits a concrete schedule. Normal proving and verification consume the generated result instead of searching again.

The NTT, CRT, and fast ring arithmetic chapter explains the arithmetic. Configuration and planning explains how generated schedules select it.

Part of the post-quantum direction

Module lattices already support major post-quantum standards. NIST standardized ML-KEM for key establishment and ML-DSA for signatures. Akita uses module lattice algebra for a different purpose: binding polynomial commitments.

The shared algebra creates a natural path for proof systems that need to prove statements about lattice-based encryption, signatures, and related protocols. The host can represent those computations using the same broad family of ring and module operations instead of translating them into an unrelated commitment model.

Akita therefore serves two roles. It can replace a curve-based commitment in a proof system that needs post-quantum security. It can also provide the commitment layer for proving the post-quantum primitives that modern cryptographic systems are beginning to use.

From practical commitments to repeated folding

Akita follows a line of work that includes LaBRADOR, Greyhound, and Hachi. These systems established compact lattice proofs and practical polynomial openings. Greyhound and Hachi produced small Module-SIS-based proofs, but their verifiers still performed work that grew roughly with the square root of the polynomial size.

Akita makes the reduction repeatable. It replaces one large opening relation with a smaller relation of the same general form, then folds again. A generated schedule continues this process until the remaining claim is small enough for direct verification.

Repeated folding is what turns the lattice commitment into a PCS with a small verifier. It also creates the need for exact transcript binding, per-level parameters, setup contribution checks, and terminal verification. The How it works section develops those mechanisms.

Multilinear today, broader tensor structure tomorrow

The current API commits to multilinear polynomials represented by evaluation tables. A table with $2^n$ entries has one axis for each of its $n$ variables, so it already has tensor structure.

Akita's folds use that tensor structure. They do not rely on multilinearity as the only possible interpretation of the data. The coefficients of a univariate polynomial can also be arranged as a tensor and folded one axis at a time.

The repository does not yet expose a univariate commitment interface. The protocol architecture can support one without changing the central reason for using lattices: efficient linear commitments over structured ring data.

Built for production

Akita treats deployment engineering as part of the cryptographic protocol. A proof system can adopt the PCS only when its parameters, proof format, verifier, optimized arithmetic, and operational tools agree on one exact design.

Akita is the first implementation in this line built around that complete requirement.

From research result to deployable primitive

Related public implementations such as LaBRADOR, LaZer, RoKoko, and Jindo made important lattice proof techniques reproducible. Their code is organized around research experiments, benchmark configurations, or narrow machine targets.

Akita takes the next step. It provides a standalone PCS that another proof system can integrate as a maintained dependency. The planner chooses parameters, and normal builds consume generated artifacts. Separate prover and verifier paths share canonical serialization. Portable arithmetic, profiling, and end-to-end host integration complete the deployment system.

Production readiness comes from agreement across that complete system.

External schedule artifacts are fixed before proving

An Akita fold uses concrete ring dimensions, digit decompositions, challenge spaces, and response bounds. Those choices determine security, proof shape, and the checks performed by the verifier. A proof must not be allowed to define them.

The planner searches this space offline. It prices complete proof schedules, checks their security requirements, and emits reviewed .aks artifacts. The host loads the selected artifact into one validated catalog shared by the configured prover and verifier. Neither runs the planner during normal proving or verification.

The public opening statement carries a 32-byte digest that names one row in that catalog. This digest is not a schedule and is not part of the proof payload. The verifier accepts it only when it matches a row in its own enabled catalog. It then reads the dimensions, bounds, and expected proof shape from that local row. An unknown digest is rejected, so a prover cannot supply an unchecked schedule.

This separation keeps verification small and deterministic. Parameter changes also appear as ordinary generated source changes that code review and continuous integration can inspect.

The Configuration and planning chapter explains the catalog keys and validation path. The Security model explains how the repository prices Module-SIS and response bounds.

The verifier is an independent boundary

Verifier-only consumers can depend on akita-verifier, akita-types, and akita-config without pulling in prover polynomial backends or planner search. This crate boundary keeps proving convenience code away from the code that accepts or rejects a proof.

Every verifier facing artifact is untrusted. The verifier checks lengths, shapes, schedule identity, setup identity, and canonical field encodings before using them. Malformed input returns AkitaError or SerializationError. It must not trigger a panic or an unchecked allocation.

This rule is enforced as a repository contract rather than an informal coding preference. The Verification chapter describes the complete boundary and its rejection rules.

Proof identity is explicit

Akita binds the configuration, setup identity, opening layout, selected schedule, commitments, points, and claimed evaluations into the transcript. The prover and verifier derive challenges only after they have committed to the same public statement.

Proofs and setup artifacts use canonical encodings with checked decoding. The verifier derives the expected proof shape from the public statement and selected schedule before decoding. Applications pin an exact Akita revision when they exchange proof artifacts because protocol evolution can change those bytes.

The Transcript and instance binding chapter follows the absorption order and challenge schedule. The Usage section explains the artifact lifecycle expected from an integrating application.

Optimized arithmetic remains portable

Large lattice operations need optimized ring arithmetic. Akita provides scalar implementations together with AVX2, AVX-512, and NEON paths. Runtime dispatch selects an implementation supported by the host CPU. Differential tests compare optimized outputs with portable reference paths.

The implementation also distinguishes arithmetic representations by their exact bounds. Some AVX-512 kernels use 50-bit residues in 64-bit lanes, while ordinary i32 transforms retain their own dispatch rules. These are backend choices. They do not change the proof statement or public setup identity.

Portable reference paths make correctness testable on ordinary development machines. Optimized paths allow the same protocol to use wide instructions on production hosts. The Optimizations and NTT, CRT, and fast ring arithmetic chapters explain these layers.

The prover controls memory as well as time

The committed polynomial is often the largest object in the application. The current dense API receives a materialized table. When the application passes an owned field buffer, Akita reuses that buffer instead of making another complete copy.

The generated fold schedule replaces the source with progressively smaller intermediate data. At large supported polynomial sizes, this additional working state grows more slowly than the source table. The dense digit cache is capped at 512 MiB. Large ring relation and quotient transforms operate on bounded chunks instead of retaining complete transformed matrices.

The current 128-bit dense benchmark makes this concrete. Its $2^{28}$ field elements occupy a 4.0 GiB source table. The first fold reduces that table to 55,332,544 field elements, about one fifth as many. The complete benchmark process peaks at about 5.1 GiB while it constructs setup, commits, proves, and verifies.

One-hot sources store their hot positions instead of a full table. Setup matrices come from a deterministic public stream and can be materialized only to the capacity required by a deployment. Prepared NTT entries are reusable compute state rather than part of public setup identity.

The prover exposes explicit release points for hosts that need to free shared matrix state before a recursive suffix. These controls let an integration make memory policy visible and measurable instead of relying on hidden global caches.

A fully streamed dense source could remove the need to store the original table inside Akita. That source path is not part of the current production API.

Performance claims come from complete proofs

The profile harness measures setup, commitment, proof generation, serialization, and verification for complete opening statements. It reports proof bytes, peak resident memory, selected schedule geometry, and separate phase timings.

Representative dense, one-hot, and grouped profiles across the supported field sizes currently produce Akita proof payloads of roughly 65 to 80 KB. The profile records the exact statement and configuration behind each result. This keeps a proof size attached to the workload that produced it.

Continuous integration compares a pull request with its merge base on the same runner. It also checks external schedule artifact drift, portable and optimized arithmetic, feature combinations, verifier dependencies, documentation links, and malformed input rejection.

The Profiling chapter explains how to reproduce and interpret these measurements.

Jolt exercises the complete boundary

Jolt is Akita's first major integration. It is a zkVM that proves correct execution of 64-bit RISC-V programs. Its memory checks create large one-hot tables, which makes it a natural host for Akita's sparse commitment path.

The integration also exercises more than proving speed. Akita proof bytes must cross a host and guest boundary. The guest must decode hostile bytes, construct the exact public statement, resolve a shipped schedule, and verify within its memory and execution limits. The host must preserve setup identity and transcript inputs across the same boundary.

These requirements shaped the separate verifier package, canonical artifact format, setup narrowing, cache release controls, and integration harness. They are general PCS boundaries, not Jolt specific shortcuts. Other proof systems can use the same interfaces.

The Jolt recursion chapter covers the current host and guest path.

What the production claim means

Akita combines the protocol and system work required for another proof system to adopt it:

• generated parameters tied to the verifier's checks;
• a standalone verifier with a strict hostile input boundary;
• canonical proof and setup artifacts;
• portable and optimized arithmetic with differential tests;
• sparse and streaming prover paths with explicit memory policy;
• complete profiling and integration harnesses.

These are not surrounding conveniences. They determine whether the same cryptographic statement survives planning, proving, serialization, verification, optimization, and host integration. Akita treats that agreement as part of the primitive.

Reviewing and auditing Akita

Akita is designed so that a reviewer can follow a public claim from the Book to the code that enforces it. The main boundaries are visible in crate dependencies, external schedule artifacts, transcript inputs, checked decoding, and verifier rejection paths.

This chapter maps the starting points for a security argument and a code audit.

Start with the accepted statement

An Akita proof does not stand alone. The verifier accepts a statement that includes ordered commitment groups, opening points, claimed evaluations, a configuration, public setup, and a generated schedule selection.

Begin an audit by writing down that complete statement. Check which values come from the host application and which values the verifier derives. Then confirm that the transcript binds every public value that can change the meaning of the proof.

The Commitment API explains the public object lifecycle. Transcript and instance binding gives the protocol order. Verification follows the checks made before and during replay.

Treat every verifier input as hostile

Proof bytes, setup artifacts, schedules, commitments, points, evaluations, and length fields may all come from an attacker. Verifier reachable code must reject malformed data with AkitaError or SerializationError.

The no panic contract prohibits verifier reachable panic!, assert!, unwrap, unchecked indexing, and unbounded allocation unless an earlier boundary has established the required invariant. Checked arithmetic is part of the same rule because an overflow can otherwise turn a small encoded shape into the wrong allocation or loop bound.

Review the boundary in this order:

1. Canonical decoding and size limits.
2. Configuration and generated schedule admission.
3. Setup capacity and setup identity.
4. Opening claim shape and group order.
5. Transcript binding before each challenge.
6. Response bounds and relation checks.
7. Terminal consistency checks.

This order follows the path from attacker controlled bytes to the final cryptographic decision.

Crate boundaries carry security meaning

Akita uses separate crates so that verifier code does not depend on the planner or prover implementation.

Verifier only applications should depend directly on akita-verifier, akita-types, and akita-config. If verifier replay begins to require a prover polynomial backend or planner search, the dependency change itself is a security review event.

The Architecture overview contains the complete crate graph and core type map.

Check one source of truth for each concept

Security and sizing logic must use the same primitive that the verifier enforces. A planner estimate, certificate check, and runtime verifier must not carry separate versions of one bound.

The repository follows one canonical function per concept. Generic checked integer formulas live in akita_error::checked. Schedule validation belongs to the configuration and schedule admission path. Transcript labels and order belong to the transcript implementation. Serialization validity belongs to the type that owns the encoding.

When a review finds two helpers that appear to compute the same security value, the right question is which one the verifier trusts. Thin wrappers and copied formulas make that answer harder to establish and should not become alternate sources of truth.

Schedule artifacts need review too

Normal builds load approved external schedule artifacts. The planner is an offline tool, but its output selects the dimensions, challenge rules, bounds, and opening methods that the verifier accepts.

A schedule review should establish:

• the lookup key describes the complete ordered opening layout;
• the selected row belongs to the artifact family bound to the configuration;
• every fold satisfies the accepted Module-SIS and response policies;
• setup capacity covers each direct matrix use;
• setup offloading metadata matches the carried setup commitment;
• the terminal parameters cover the remaining relation.

Generation scripts and continuous integration byte-compare committed .aks artifacts with fresh planner output. An external schedule artifact is still protocol source. Review changes to it with the same care as handwritten verifier code.

The Configuration and planning, Setup offloading, and Security model chapters divide this review into its protocol parts.

Follow transcript identity end to end

The transcript turns public objects and prover messages into challenges. If the prover and verifier absorb different statements, they are no longer executing the same protocol.

Check that both sides bind the same configuration, setup identity, schedule, claim layout, commitments, points, and evaluations in the same order. Then check that each prover message is absorbed before the challenge that depends on it. Group order and point coordinates are protocol data, not presentation details.

Logging transcript tests record the schedule of absorb and squeeze events. Hardening tests mutate public values and confirm that verification rejects the changed statement. These tests provide useful evidence, but the review should also establish why every meaning changing value appears in the transcript.

Review optimized arithmetic against a reference

Akita uses scalar, AVX2, AVX-512, and NEON arithmetic. Unsafe code and vector kernels deserve their own pass because a platform specific error can change a commitment or verifier relation without changing high level Rust code.

For each optimized kernel, identify:

1. The scalar or mathematical reference operation.
2. The accepted input range and intermediate bound.
3. The runtime feature check that selects the kernel.
4. Differential tests over boundary values and random inputs.
5. Exact reduction before values cross into canonical serialization or transcript code.

The Optimizations chapter maps the main kernels. The NTT, CRT, and fast ring arithmetic chapter explains the representations and exact reconstruction bounds.

Understand what each repository source proves

The repository has several forms of documentation, and they have different jobs.

When these sources disagree, record a documentation or implementation defect. Do not combine parts from different versions into an unstated protocol. The Spec index identifies live and historical design records.

Suggested audit paths

Different reviews can start at different boundaries:

A complete audit eventually crosses all of these paths. The table identifies a clear first boundary for each kind of question.

Using Akita

Akita gives a proof system a complete polynomial commitment interface. An application commits to a large table, claims the value of that table's multilinear extension at a chosen point, and asks Akita to prove the claim. The verifier checks the proof without receiving the table.

Akita is built for use as infrastructure. The repository provides generated security parameters, optimized prover code, a compact proof format, and a separate verifier package. A host proof system can use the complete Rust API or carry only the verifier into a smaller trusted environment.

The complete lifecycle

An Akita integration performs four operations.

The shortest complete path looks like this:

choose a configuration
        ↓
build and prepare setup
        ↓
commit to polynomial groups
        ↓
state the opening points and values
        ↓
prove and encode
        ↓
decode and verify

The first proof chapter runs this full path with one dense polynomial. It uses a real external schedule artifact and the same public API used by larger integrations.

What Akita commits to

The current API commits to multilinear polynomials represented by their values on the Boolean cube. A polynomial with $n$ variables has $2^n$ entries. Akita supports arbitrary dense tables and a compact one hot representation for tables with one selected entry in each fixed size chunk.

Applications may commit to several polynomials at once. Polynomials with the same number of variables and the same opening point form one commitment group. A proof may contain several ordered groups, and each group may use its own point. Akita binds the group order, commitments, points, claimed values, configuration, and selected proof schedule into the transcript.

This group model lets a host combine earlier commitments with a final group in one proof. It also lets Akita preserve structured inputs instead of expanding every table into a dense allocation.

Choose your path

Readers who want to understand the protocol itself can continue to How it works. Readers who need the mathematical ideas first can start with Foundations.

Which crate to use

The repository separates proving from verification on purpose.

An application that proves and verifies can begin with akita-pcs. A small verifier should depend directly on akita-verifier, akita-types, and akita-config. Pin every Akita crate to the same revision because a proof and its verifier must use the same protocol format.

Akita chooses the proof plan

The application chooses the field, data shape, and group layout. Akita then resolves an approved row from the catalog supplied by the application. That row fixes the ring dimensions and all later fold parameters.

This division keeps the application interface small. It also keeps parameter search out of the verifier. The verifier uses the exact catalog bound to its preprocessing or setup package and replays the statement-selected approved row.

The configuration guide explains the choices an application should make and the choices Akita deliberately makes for it.

Your first proof

The quickest way to understand Akita is to run one complete commitment and opening proof. The repository includes a checked example that uses the real production API from setup through verification.

Run this command from the repository root:

cargo run -p akita-pcs --release --example quickstart

The first release build compiles the complete proving stack. Later runs reuse those build results. A successful run ends with output of this form:

Akita proof verified

The complete source is crates/akita-pcs/examples/quickstart.rs. The normal Cargo checks compile this example with the public API. The chapter therefore stays tied to code that works.

The statement being proved

The example uses fp128::Dense, Akita's direct configuration for arbitrary values in its 128 bit field. It creates a table with $2^{14}$ field elements. That table represents a multilinear polynomial with 14 variables.

The example then chooses a point with 14 coordinates and evaluates the multilinear polynomial there. This value is the public claim. In a larger proof system, the host protocol usually produces the table, point, and claimed value.

#![allow(unused)]
fn main() {
type Config = fp128::Dense;
type F = fp128::Field;

const NUM_VARS: usize = 14;

let polynomial = DensePoly::from_field_evals(NUM_VARS, &evaluations)?;
let evaluation = evaluate_multilinear(&evaluations, &point);
}

The helper that computes evaluation is independent of the Akita prover. It exists to give the verifier a concrete public value to check.

Load schedules and build reusable setup

The configuration determines the expected schedule family and policy. The application loads approved artifact bytes from its own storage; Akita validates them before setup or proof work begins. setup_prover then sizes public matrix data from the exact rows in that catalog.

#![allow(unused)]
fn main() {
let artifact_bytes = std::fs::read("parameters/fp128_dense.aks")?;
let scheme = AkitaCommitmentScheme::<Config>::from_schedule_artifact(
    &artifact_bytes,
    akita_params::ChunkedWitnessCfg::default_non_chunked(),
)?;
let setup = scheme.setup_prover(NUM_VARS, 1)?;
let backend = std::sync::Arc::new(CpuBackend::new(setup.expanded.clone())?);
}

The prepared backend holds reproducible compute state such as transformed matrix prefixes. Applications should reuse it across commitments and proofs. Setup is public. Akita does not require a secret trapdoor or a trusted setup ceremony.

Commit to the polynomial

One call commits to one group of polynomials. This example has one polynomial and no earlier groups.

#![allow(unused)]
fn main() {
let source = backend.import_source(vec![polynomial])?;
let commit_output = backend.commit(
    scheme.schedules(),
    &source,
    GroupContext::scheduler_without_precommitted_groups(),
)?;
}

The call returns two values:

• committed_group is public. The verifier receives it.
• private_handle retains the exact immutable source and commitment parameters.

The group context tells Akita which catalog row to use for the commitment. A later chapter explains how earlier commitment groups change this context.

Assemble the opening claim

An opening claim joins the point, claimed value, and commitment. The prover also supplies the reusable commitment handle. It cannot substitute another polynomial.

#![allow(unused)]
fn main() {
let prover_claims = OpeningClaims::from_groups(vec![
    PolynomialGroupClaims::new(
        point.clone(),
        vec![evaluation],
        commit_output.committed_group.clone(),
    )?,
])?;

let prover_data = SelectedProverOpeningData::from_committed_claims::<Config>(
    prover_claims,
    vec![commit_output.private_handle.clone()],
    scheme.schedules(),
)?;
let selection = prover_data.selection();
}

SelectedProverOpeningData checks that the public claims, commitment profiles, private hints, and polynomial groups have the same order and shape. It also selects the exact trusted catalog row for the complete batch.

Produce the proof

The prover starts a transcript with an application specific domain. This domain separates the proof from every other protocol that may use the same transcript construction.

#![allow(unused)]
fn main() {
const TRANSCRIPT_DOMAIN: &[u8] = b"akita/book/quickstart/v1";

let proof = scheme.batched_prove(
    &setup,
    prover_data,
    &backend,
    TRANSCRIPT_DOMAIN,
    BasisMode::Lagrange,
)?;
}

BasisMode::Lagrange means that the committed table contains values on the Boolean cube. This is the standard representation for multilinear extensions in proof systems.

Transport the proof

The proof is already the canonical Spongefish argument byte string. Store or send it directly; the public schedule bounds every message the verifier reads.

#![allow(unused)]
fn main() {
let proof_bytes: Vec<u8> = proof;
}

Akita resolves the authenticated schedule before reading proof messages and rejects truncation, noncanonical atoms, and trailing bytes.

Verify with fresh public state

The verifier needs public setup, the commitment, the point, the claimed value, and the selected schedule row. It does not receive the polynomial or private prover state.

#![allow(unused)]
fn main() {
let verifier = scheme.verifier(scheme.setup_verifier(&setup)?)?;
let verifier_claims = OpeningClaims::from_groups(vec![
    PolynomialGroupClaims::new(
        point,
        vec![evaluation],
        &commit_output.committed_group,
    )?,
])?;
let statement = GroupBatchStatement::new(selection, verifier_claims)?;

verifier.batched_verify(&proof_bytes, TRANSCRIPT_DOMAIN, statement, BasisMode::Lagrange)?;
}

Akita constructs fresh prover and verifier states and binds the complete public statement before deriving proof challenges, so a change to the group order, point, value, commitment, configuration, or schedule causes verification to fail.

What to change next

The example fixes its choices so that the lifecycle stays easy to follow. A real integration will choose them from the host protocol.

• Use Choosing a configuration to select the field and polynomial representation.
• Use Integrating the PCS for several polynomials, several opening points, or earlier commitment groups.
• Use Verifier only integration when verification must compile without the prover backend.
• Use Integrating with a proof system to connect Akita to a host protocol or recursive verifier.
• Use Profiling to measure a production size workload.

Choosing a configuration

An Akita configuration defines the field, committed data shape, security policy, and expected schedule-artifact family. The application chooses the family and supplies its approved artifact. Akita selects the exact row from the validated catalog.

This split is one of Akita's strengths. Applications make decisions about their own data. They do not tune ring dimensions or search for cryptographic parameters at runtime.

Start with the host field

Each production family has a base field for commitments and an opening field for evaluation points and claimed values.

All three families target 128-bit quantum security under Akita's concrete lattice attack model. The smaller base fields use extension fields for opening points and claimed values. The host should choose the family whose opening field matches the values it needs to prove. The rings and fields chapter explains the construction.

Match the committed data

The next choice is the representation of the table.

The direct fp128 types are fp128::Dense and fp128::OneHot. fp128::DenseBounded accepts every u64 value and the corresponding negative range. It uses the fp128_dense_bounded artifact family.

The bounded configuration enforces its range during commitment. This is useful because the tighter range becomes part of the commitment profile and the security calculation. Use ordinary Dense when the application cannot prove the bound before calling Akita.

One hot is more than a label on a dense table. The prover stores selected indices and uses kernels written for that representation. Applications should keep structured data in this form instead of expanding it into a dense vector.

Describe the opening batch

A schedule is selected for the complete ordered batch. The selection depends on the following public shape:

• The number of commitment groups.
• The number of variables in each group.
• The number of polynomials in each group.
• The commitment profile carried by each group.
• The opening method fixed by the configuration and commitment profiles.

Polynomials in one group have the same number of variables and share one opening point. Polynomials with another arity or point belong in another group. The order of those groups is part of the proof statement.

The common direct case uses one group and GroupContext::scheduler_without_precommitted_groups(). A grouped opening commits earlier groups first, then commits the final group with GroupContext::scheduler_with_precommitted_groups(&prior).

Direct and recursively offloaded setup checks

Every Akita proof reduces a large opening through a sequence of folds. The word recursive in RecursiveCommitmentConfig<Cfg> refers to an additional setup checking path. It lets the proof carry the large public setup contribution into a later fold instead of asking the verifier to scan it directly.

Use the direct configuration first. It has the simplest setup and is the right choice for ordinary local verification. Use a shipped recursive configuration when the verifier environment makes direct setup evaluation expensive. The setup offloading chapter explains the complete protocol and its supported families.

Precommitted groups in a recursive grouped opening still use the base configuration. The final group and the proof use RecursiveCommitmentConfig<Cfg>. This preserves the commitment identity of the earlier groups while selecting the recursive adapter for the complete opening.

Partition large prover work

The fp128 configuration module also provides multi chunk companions for selected production workloads. These configurations divide the witness relation into exact chunks during the first folds. They let the prover spread large work across a controlled partition without changing the public claim.

The profile name W8R2 means eight chunks in the first two folds (levels 0 and 1), followed by single-chunk folds. R3 extends that prefix to three folds (levels 0, 1, and 2). The fp128 presets OneHotMultiChunkW2R3, OneHotMultiChunkW4R3, and OneHotMultiChunkW8R3 offer two, four, and eight chunks; DenseMultiChunkW8R3 offers eight chunks for dense sources. RecursiveCommitmentConfig<fp128::OneHotMultiChunkW2R3>, RecursiveCommitmentConfig<fp128::OneHotMultiChunkW4R3>, and RecursiveCommitmentConfig<fp128::OneHotMultiChunkW8R3> combine each chunk width with recursive setup offloading. Each preset uses its own trusted schedule catalog; OneHotMultiChunk and DenseMultiChunk continue to use W8R2.

Multi chunk configurations are deployment choices for measured large workloads. Begin with Dense or OneHot. Move to a multi chunk companion after profiling the complete host application and confirming that its trusted external catalog contains the required row.

Let the trusted catalog choose dimensions

Akita may use different ring dimensions for the commitment matrix, later relations, and different fold levels. The offline planner searches these choices under the same security rules that the verifier enforces. The selected row records the result.

Application code should not choose a fixed ring dimension. It should describe the field, data representation, and opening batch. This lets Akita improve offline schedules without changing the high level integration model.

Normal proving and verification never run the planner. They resolve a row from the catalog supplied to the scheme instance. AkitaError::UnsupportedSchedule means that catalog does not contain the exact request. The troubleshooting guide lists the information needed to diagnose that result.

Practical choices

Use these starting points:

The first proof uses fp128::Dense. The integration guide develops grouped openings and prepared state. The profiling guide shows how to measure the selected configuration at the host's real workload size.

Integrating the PCS

Akita gives a host proof system a clear boundary between private proving work and public verification. The prover owns the large polynomial tables and the compute state used to open them. The verifier receives commitments, claimed values, and one compact proof.

This boundary is designed for real integrations. A host can prepare setup once, reuse commitments across later claims, batch several polynomial groups into one opening, and carry the verifier into a package that has no prover backend or runtime planner.

The integration flow

A complete host follows this order:

1. Choose a configuration for the host field and polynomial representation.
2. Load and validate the approved external schedule artifact.
3. Build prover setup for the largest supported workload from that catalog.
4. Prepare the compute backend and keep it warm across proofs.
5. Commit to each polynomial group and retain its private hint.
6. Assemble the ordered opening claims for one proof.
7. Let the catalog select the exact trusted row for that batch.
8. Produce and encode the proof.
9. Send the catalog identity, public statement, proof, and verifier setup.
10. Restore the same approved catalog, decode under its expected shape, and verify.

The first proof runs this lifecycle with one polynomial. The chapters below explain how to turn that example into an application boundary.

Public and private data

Akita keeps the data split explicit.

The verifier never needs the original polynomial or the private commitment hint. The prover never chooses unchecked cryptographic parameters. Both sides use the same public configuration and trusted catalog identity.

Four contracts to preserve

An integration stays simple when it preserves four contracts.

Group contract

One commitment call creates one homogeneous group. Every polynomial in that group has the same number of variables. Every polynomial in one opening claim group shares one opening point.

Order contract

Group order is part of the public statement. The prover must keep commitments, hints, polynomials, points, and claimed values in the same order. Akita checks this shape before proving and binds it into the transcript.

Setup contract

The prover setup and verifier setup must describe the same public matrix stream and setup prefix commitments. Prepared CPU caches may differ because they are local compute state, not protocol identity.

Revision contract

The prover and verifier must use the same Akita protocol revision. Pin every Akita crate together and revalidate proof exchange when upgrading.

Read the focused guides

• Commitment groups and opening claims explains single groups, earlier commitments, and ordered batched claims.
• Setup and prepared compute state explains reusable public setup, verifier setup, backend caches, and persistence.
• Proof encoding and transcripts explains the public artifact, schedule selection, transcript domains, and decoding.
• Verifier only integration gives the direct verifier dependency path and call.

The protocol chapters under How it works explain why these contracts are sufficient. Application code can use them without reimplementing the protocol internals.

If Akita will sit inside a larger proof system, continue to Integrating with a proof system. That chapter explains the adapter around this PCS lifecycle: field conversion, statement ownership, artifact transport, and verifier placement.

Commitment groups and opening claims

Akita commits to polynomials in groups. Each group has a public commitment and an immutable private handle retaining its exact source. One backend can reuse these handles across independent and concurrent proofs.

Commit one group

Construct a backend from the public setup, then transfer the polynomials into its source storage. Each commit names the trusted catalog that selects the group's profile:

#![allow(unused)]
fn main() {
let backend = std::sync::Arc::new(CpuBackend::new(setup.expanded.clone())?);
let source = backend.import_source(polynomials)?;
let CommitOutput {
    committed_group,
    private_handle,
} = backend.commit(
    scheme.schedules(),
    &source,
    GroupContext::scheduler_without_precommitted_groups(),
)?;
}

All polynomials in a source group must have the same number of variables and one supported source representation. Akita rejects a mixed group instead of padding smaller tables. Put polynomials with another size or representation in another group.

committed_group carries the public commitment and its frozen profile. private_handle retains the exact source, parameters, and private commitment material. It remains usable after the application drops source. Clone the handle when opening the same commitment in another proof.

State one group's opening claims

Every public group claim contains one complete point, one claimed value for each polynomial, and the group commitment:

#![allow(unused)]
fn main() {
let group = PolynomialGroupClaims::new(
    opening_point,
    evaluations,
    committed_group.clone(),
)?;
let claims = OpeningClaims::from_groups(vec![group])?;
let prover_data = SelectedProverOpeningData::from_committed_claims::<Config>(
    claims,
    vec![private_handle.clone()],
    scheme.schedules(),
)?;
let selection = prover_data.selection();
}

If the group contains four polynomials, evaluations contains four values in the same order. The point has one coordinate for each polynomial variable. The constructor selects one exact catalog row. The backend checks that each handle belongs to it and matches the supplied public commitment and profile. The proof checks the claimed evaluations against the retained source.

The returned selection is public and travels with the verifier statement. Opening accepts only the handles and public claims; the application cannot substitute a different polynomial table at proof time.

Open several groups in one proof

Separate groups may have different numbers of variables and different points. Akita keeps each point with its own group:

#![allow(unused)]
fn main() {
let claims = OpeningClaims::from_groups(vec![
    PolynomialGroupClaims::new(point_a, values_a, commitment_a.clone())?,
    PolynomialGroupClaims::new(point_b, values_b, commitment_b.clone())?,
    PolynomialGroupClaims::new(point_c, values_c, commitment_c.clone())?,
])?;
}

The final group is the last item. Every earlier item is a precommitted group. Build the commitment handle vector in exactly the same order. Each group binds its variable count, polynomial count, frozen profile, commitment, point, and claimed evaluations.

Before committing the final group, derive the ordered profiles of the earlier commitments:

#![allow(unused)]
fn main() {
let prior = PrecommittedGroupProfiles::from_profiles(
    prior_commitments.iter().map(|group| *group.profile()).collect(),
)?;
let final_source = backend.import_source(final_polynomials)?;
let final_output = backend.commit(
    scheme.schedules(),
    &final_source,
    GroupContext::scheduler_with_precommitted_groups(&prior),
)?;
}

The grouped context selects a trusted catalog row keyed by the complete ordered prefix and final group. Earlier independent commitments remain reusable in later batches. PrecommittedGroupProfiles is nonempty by construction; the independent case uses its own constructor.

Recursive grouped openings

A RecursiveCommitmentConfig<BaseConfig> uses setup offloading for supported large verifier workloads. Commit the final group under the recursive catalog. Earlier groups use the reviewed independent commitment profile from the base catalog, supplied through GroupContext::explicit(&base_profile). The final group uses GroupContext::scheduler_with_precommitted_groups(&prior).

This keeps one backend owner for the entire proof and preserves the independent public profiles of earlier groups. The proof's recursive catalog checks the complete ordered batch.

Dense and one hot groups in one batch

Import dense and one hot polynomials as separate homogeneous source groups. Their commitments have the same opaque handle type, so their handles can be placed in one ordered opening batch. Concrete CPU source operations remain inside the backend, and one hot data retains its compact representation.

The backend stores no catalog, so one backend commits every group. Pass each group's producer catalog to its own commit, then commit the final group and open the batch under the proving catalog:

#![allow(unused)]
fn main() {
let dense_output = backend.commit(
    dense_scheme.schedules(),
    &backend.import_source(dense_polynomials)?,
    GroupContext::scheduler_without_precommitted_groups(),
)?;
let prior = PrecommittedGroupProfiles::from_profiles(vec![
    dense_output.committed_group.profile.clone(),
])?;
let final_output = backend.commit(
    onehot_scheme.schedules(),
    &backend.import_source(onehot_polynomials)?,
    GroupContext::scheduler_with_precommitted_groups(&prior),
)?;
}

The catalog passed to commit is the producer contract for that group: it fixes the commit profile and the source class and coefficient bound that admission enforces. The handle records that contract, and CommitmentHandleMetadata::producer_contract returns it. Opening data built with SelectedProverOpeningData::from_committed_claims::<Cfg> rejects a final group whose recorded contract differs from Cfg::committed_source_contract(), since the proving catalog plans its final group under that contract.

Schedule rows carry no producer identity for precommitted groups, so opening does not check them. The application must commit each precommitted group under the configuration whose contract the proving catalog's row assumes for that group, and it can compare each handle's producer_contract() with the contract it planned. A mismatch cannot make a false claim verify, since the verifier enforces the row's frozen caps. The proof's completeness and grinding budget, however, no longer follow from the planner's model, so an honest proof can fail. Proof bytes do not bind the producer contract.

The setup must cover every family that commits on the backend. When the proving catalog's rows already include each precommitted profile, its own setup suffices. Otherwise build the setup from combined requirements, as in Share one setup across families.

A handle from another backend is rejected during admission. When transferring an existing commitment deliberately, use backend.import_commitment(&handle). The receiving backend checks the source and commitment material against its own setup before issuing a fresh handle owned by that backend.

Explicit commitment parameters

Normal applications use trusted catalog selection. A caller that already owns a reviewed commit profile may use GroupContext::explicit(&profile). Explicit mode commits the supplied GroupCommitPhaseParams. The opening schedule validates its compatibility when the commitment is consumed. Use explicit mode when the application owns the reviewed parameter distribution.

What the verifier receives

The verifier rebuilds the same ordered claims with borrowed commitments and joins them to the public schedule selection:

#![allow(unused)]
fn main() {
let statement = GroupBatchStatement::new(
    selection,
    OpeningClaims::from_groups(vec![
        PolynomialGroupClaims::new(point, values, &committed_group)?,
    ])?,
)?;
}

The statement contains no source tables or private handles. The verifier only guide continues from this object. The proof artifacts guide explains how to carry it across a process boundary.

Setup and prepared compute state

Akita uses transparent public setup. The setup contains no secret trapdoor and needs no ceremony. A deployment can generate it from the public setup seed, store it for reuse, and derive a smaller verifier package for each supported proof shape.

The API separates protocol identity from local compute state. This lets a host cache expensive transforms without changing commitments or proof bytes.

The four setup objects

The public matrix stream has one identity across ring dimensions. A trusted schedule row takes the exact widths and dimensions needed by each operation from a prefix of that stream.

The current identity is Shake256PagedV1: independently derived 4096-element SHAKE256 pages followed by exact field rejection sampling. Setup and commitment gives the byte encoding. A host that regenerates setup must use that versioned derivation, not an application-specific PRG expansion of the 32-byte seed.

Build prover setup once

The normal entry point takes the largest number of variables and largest total polynomial count across the final and all precommitted groups in one opening batch that the host plans to support.

#![allow(unused)]
fn main() {
let catalog = TrustedScheduleCatalog::<Config>::from_artifact_bytes(&artifact_bytes, akita_params::ChunkedWitnessCfg::default_non_chunked())?;
let scheme = AkitaCommitmentScheme::<Config>::new(catalog);
let setup = scheme.setup_prover(
    max_num_vars,
    max_total_batched_polys,
)?;
}

A larger covering setup can serve a smaller proof under the same public seed. Of the setup, the commitment and proof bind only the seed, not the amount of matrix data that one prover happened to store.

For a recursive configuration, setup construction also prepares the setup prefix commitments required by its supplied catalog. The host should build setup with the configuration that will produce the final proofs.

Share one setup across families

Configurations with the same field can share one setup, and those that also share the extension field can share one backend. Compute each catalog's requirements at the same bound, combine them, and build the setup from the combined requirements:

#![allow(unused)]
fn main() {
let requirements = SetupRequirements::from_catalog::<DenseConfig>(
    dense_scheme.schedules(),
    max_num_vars,
    max_total_batched_polys,
)?
.union(SetupRequirements::from_catalog::<OneHotConfig>(
    onehot_scheme.schedules(),
    max_num_vars,
    max_total_batched_polys,
)?)?;
let setup = akita_pcs::new_prover_setup::<Field>(&requirements)?;
}

The combined setup uses the same public seed as each per-family setup, so a proof produced with it is byte-identical to one produced with the smaller per-family setup. The transcript's instance descriptor binds the field algebra, the family's decomposition and SIS profile, the setup seed, the selected schedule row, the grinding plan, and the call layout. It binds no provisioned capacity: neither the setup's variable and polynomial bounds nor its materialized matrix length. Commitments read the same seed-derived matrix prefix under either setup. Each commitment call uses its producer catalog. Each opening selects a row from, and is admitted against, its opening catalog.

SetupRequirements<F> is tied to the field and has no public constructor other than from_catalog and union, so every requirement passed to new_prover_setup comes from validated catalog metadata.

Prepare the compute backend

The CPU backend turns public setup into reusable execution state.

#![allow(unused)]
fn main() {
let backend = std::sync::Arc::new(CpuBackend::new(setup.expanded.clone())?);
}

The prepared state starts with empty transform caches. Commitment and proving kernels build exact entries as needed. A larger cached prefix can serve a smaller request with the same field, ring dimension, and transform domain.

These caches are derived from a matrix view. They are not part of the public stream and are not covered by AkitaSetupSeed. Two machines may retain different transform domains and prefix lengths while producing identical commitments and proofs.

Keep the shared backend alive across repeated work. It owns prepared setup resources and caches. Reusable commitment handles retain their immutable sources, while every proof creates separate temporary state. Finishing or abandoning one proof leaves other proofs and commitments valid.

Build verifier setup

The simplest conversion keeps the complete materialized public matrix prefix.

#![allow(unused)]
fn main() {
let verifier_setup = scheme.setup_verifier(&setup)?;
}

This is a good starting point for local verification and the first integration.

A deployment that knows the exact proof schedule can derive a smaller verifier setup:

#![allow(unused)]
fn main() {
let resolved = scheme.schedules().resolve_selection(selection)?;
let opening_layout = verifier_claims.committed_layout()?;
let verifier_setup =
    scheme.setup_verifier_for_schedule(
        &setup,
        resolved.schedule(),
        &opening_layout,
    )?;
}

The narrowed setup retains the terminal matrix and every public matrix prefix that verification still reads directly. A setup contribution carried by a recursive setup proof does not need the same direct prefix in the verifier hot path.

The complete setup prefix commitment registry remains part of verifier setup. Those commitments authenticate the offloaded public setup contributions.

Reuse and release CPU caches

Prepared state stays warm by default. That is the right policy for a service that proves many statements with the same setup.

Applications can call backend.trim_caches() to release reusable transform entries. Active operations retain the storage they still need. Proof completion releases proof-owned temporary state while shared caches may survive for later proofs. Cache entries rebuild lazily when needed.

The release policy changes local memory and compute time. It does not change setup identity, commitment identity, or proof bytes. Measure the complete host before choosing it.

Disk persistence

The disk-persistence feature stores public matrix coefficients and setup prefix artifacts. It does not store backend transform caches.

Stored setup entries include their public identity and provisioning limits. Versioned filenames prevent an older setup format from being accepted as a current entry. If a cache entry is missing or invalid, Akita can regenerate the public data from the seed.

A deployment that distributes verifier setup should authenticate the package or regenerate it from the public seed. This gives every verifier the same public setup identity while allowing each machine to choose its own local storage and compute caches.

Setup offloading

Recursive setup offloading commits to an actual power of two prefix of the public matrix stream. The prefix may be longer than the active setup weight. The extra coefficients are still real public setup data, while the weight is zero outside its natural support.

The planner chooses the commitment parameters for that prefix independently of the fold that produced or consumed it. The setup offloading chapter explains this lifecycle from planning through verifier replay.

Operational rule

Share protocol identity and choose compute state locally.

• Prover and verifier packages must agree on the setup seed and prefix commitments.
• A prover may materialize a larger covering matrix prefix.
• Each machine may build its own prepared transform caches.
• Cache release and persistence policies may follow the host's measured memory budget.

The profiling guide reports setup size and prepared cache size separately so these costs remain visible.

Proof encoding and transcripts

An Akita verification request combines proof bytes with a complete public statement. That statement contains the setup identity, commitments, opening points, claimed values, configuration, and selected trusted schedule row.

Akita binds all of these values before deriving proof challenges. This makes the public integration boundary part of the cryptographic statement.

The public proof bundle

A host should define one versioned container with these fields:

The host may store verifier setup separately and refer to it by an authenticated identifier. The remaining values still belong to one public verification request.

Use a stable session for each protocol

The host chooses an application specific session label. Give it a version and a clear protocol owner.

#![allow(unused)]
fn main() {
const SESSION: &[u8] = b"my-system/akita-opening/v1";

let proof = scheme.batched_prove(&prover_setup, opening, &stacks, SESSION, basis)?;
scheme.verifier(verifier_setup)?.batched_verify(&proof, SESSION, statement, basis)?;
}

The verifier binds the canonical Akita instance descriptor before replay. That descriptor covers the configuration, setup identity, schedule, and public claim layout. Akita then absorbs commitments, points, claimed values, and proof messages in protocol order.

Akita constructs fresh prover and verifier states internally. Do not serialize a live state or reuse proof bytes under another session. Both sides use the same session bytes and independently bind the same public instance.

The transcript chapter lists the exact binding order and explains the wire checks used by transcript tests.

Carry the trusted row selection

SelectedProverOpeningData::selection() returns an OpeningScheduleSelection. It names the exact row digest in the trusted catalog used for the complete batch.

The verifier does not reconstruct a planner request from proof contents. It resolves this explicit identity in the supplied catalog, checks the row digest, and replays that schedule. This keeps planner search outside the verifier and prevents a proof from supplying its own unchecked parameters.

Store the proof canonically

The PCS returns the canonical Spongefish argument byte string.

#![allow(unused)]
fn main() {
let proof_bytes: Vec<u8> = proof;
}

The verifier resolves the selected row from the approved catalog before it reads messages. Schedule-derived fixed counts and bounds control decoding and allocation; no proof-supplied shape is accepted.

Canonical encoding means that one accepted object has one encoding within a protocol revision. Pinning the producer and verifier to the same commit or release gives the host one proof format and transcript schedule. Upgrade both sides together and regenerate proof fixtures for the new revision.

Rebuild the statement at verification

The verifier uses borrowed commitments because it does not own prover state.

#![allow(unused)]
fn main() {
let claims = OpeningClaims::from_groups(vec![
    PolynomialGroupClaims::new(point, values, &commitment)?,
])?;
let statement = GroupBatchStatement::new(selection, claims)?;
}

This constructor checks that the claim set is nonempty and structurally valid. The verifier then checks each commitment profile against the claims, setup, and resolved schedule.

Treat every incoming byte as public input

The verifier accepts public data from another process or machine. Decode it with explicit shape and size limits, build the typed statement, and pass errors back to the host.

Akita's verifier boundary returns AkitaError or SerializationError for malformed input. This gives hosts one normal rejection path for invalid bytes, unsupported schedules, mismatched claims, and failed cryptographic checks.

The verifier only guide puts these pieces together without the prover dependency path.

Verifier only integration

Akita provides a separate verifier package for hosts that want the smallest trusted dependency path. This package contains the public types and replay logic needed to check an approved proof schedule. Polynomial backends, commitment hints, setup generation, and planner search remain in the proving packages.

This boundary is useful for a zkVM guest, a network service, or any process that only receives proofs.

Dependencies

Pin every crate to the same Akita revision. A verifier consumer needs these packages:

[dependencies]
akita-verifier = { git = "https://github.com/LayerZero-Labs/akita", rev = "<commit>" }
akita-config = { git = "https://github.com/LayerZero-Labs/akita", rev = "<commit>", default-features = false }
akita-types = { git = "https://github.com/LayerZero-Labs/akita", rev = "<commit>", default-features = false }
akita-transcript = { git = "https://github.com/LayerZero-Labs/akita", rev = "<commit>", default-features = false }
akita-serialization = { git = "https://github.com/LayerZero-Labs/akita", rev = "<commit>" }

The default akita-verifier features enable the Blake2b transcript backend. Schedule rows are external data, not features. The host loads approved artifact bytes, constructs a TrustedScheduleCatalog<Cfg>, and supplies that config-bound catalog to every verification call.

The verifier package stays small when the consumer depends only on the crates above. The repository checks in CI that akita-verifier has no dependency on akita-pcs, akita-prover, akita-planner, or akita-setup.

Inputs to verification

The verifier receives these public values:

• An AkitaVerifierSetup for the configuration and supported schedule.
• The approved external schedule artifact or its validated catalog.
• A schedule selection produced with the proof.
• Ordered commitments, points, and claimed values.
• Spongefish argument bytes.
• The application transcript domain and basis mode.

The host should place them in one versioned public artifact or authenticate the setup separately. The proof artifacts guide explains the bundle.

Keep proof bytes opaque

Do not decode the proof into a host-side Rust object. Pass the argument bytes to verification; the approved schedule supplies all message counts and allocation bounds.

Commitments and verifier setup use their own canonical decoders and validation rules. Decode every public object before constructing the statement.

Build the public statement

Each group owns one point and one value for each committed polynomial.

#![allow(unused)]
fn main() {
let claims = OpeningClaims::from_groups(vec![
    PolynomialGroupClaims::new(
        opening_point,
        claimed_values,
        &committed_group,
    )?,
])?;

let statement = GroupBatchStatement::new(
    schedule_selection,
    claims,
)?;
}

For a multi group proof, preserve the exact order used by the prover. The final group is last, and every earlier group is a precommitted group.

Verify directly

Build one AkitaVerifier from the verifier setup and the trusted catalog, then pass the application session label to its verification method.

#![allow(unused)]
fn main() {
let verifier = akita_verifier::AkitaVerifier::new(verifier_setup, catalog)?;
verifier.batched_verify(
    &proof_bytes,
    TRANSCRIPT_DOMAIN,
    statement,
    BasisMode::Lagrange,
)?;
}

Construction fixes the catalog rows this verifier admits: those whose opening key fits the setup descriptor and whose direct matrix uses fit the setup's public matrix. It prepares the terminal matrix transforms of those rows once. Verification never mutates the verifier, so one instance can serve many proofs and threads. A verifier that checks a single proof, such as a zkVM guest, uses AkitaVerifier::for_selection to admit and prepare only that proof's row.

The verifier resolves the explicit schedule selection in the supplied catalog. It does not run the planner. It then binds the instance descriptor, validates the public claims, and replays every fold through terminal verification.

The repository's quickstart example uses this verifier after producing and decoding a proof. Cargo compiles that call as part of the normal example checks.

Supply verifier setup

The proving environment normally creates verifier setup before packaging or serving proofs.

For a first integration, use:

#![allow(unused)]
fn main() {
let verifier_setup = scheme.setup_verifier(&prover_setup)?;
}

For a fixed production schedule, use setup_verifier_for_schedule. It retains only the public matrix prefix that the selected verifier path reads directly, plus the complete setup prefix commitment registry.

The verifier package consumes this artifact. It does not need setup generation code. A host can authenticate the package by digest, distribute it with the application, or regenerate and validate it before placing it in the verifier environment.

Handle rejection as a normal result

All verifier facing proof, setup, schedule, claim, and transcript data is untrusted public input. The verifier returns AkitaError or SerializationError when decoding or proof replay fails.

Match on the error at the host boundary and reject the request. Do not retry verification with another configuration or reconstructed schedule. A valid proof names one configuration, one catalog row, and one ordered public statement.

The verifier code follows a strict no panic contract for malformed public input. CI checks the dependency boundary, and the test suite exercises shape, schedule, transcript, serialization, and proof rejection paths. The verification chapter describes the full contract and the checks applied at each stage.

Verify the package boundary

Run these checks when changing a verifier integration:

scripts/check-crate-deps.sh akita-verifier
cargo clippy -p akita-verifier --all-targets --release \
  --no-default-features \
  --features transcript-blake2b \
  -- -D warnings

The first command confirms that the verifier crate has not gained prover or planner dependencies. The second checks the narrow feature graph used by a minimal verifier build.

Operating Akita

Akita exposes its deployment choices through external schedule artifacts, explicit Cargo features, prepared compute state, and one end to end profile harness. A host loads the exact catalog it approves and measures proofs under that same catalog.

The operating path has three layers:

1. Choose the feature set and load approved catalog bytes from normal storage.
2. Run a complete proof workload and inspect time, memory, and proof size.
3. Use focused reports or kernel benchmarks when a complete run identifies a component that needs deeper analysis.

Start with the complete build

The default akita-pcs features provide parallel CPU execution and the Blake2b transcript backend. Schedule rows are not Cargo features and are never linked into the binary; the first proof loads an artifact explicitly.

Use Feature flags when the host needs sequential execution, disk persistence, another transcript backend, or diagnostic instrumentation.

Measure a real proof first

Akita's profile harness runs setup, commitment, proof generation, encoding, and verification. It reports the complete public statement and the trusted schedule selected for that statement.

Start with Profiling a workload. It gives one canonical command and explains every output. This complete run shows whether a local optimization improves the time and memory of the host proof.

Read CI performance results

Profile CI compares a pull request with its merge base on the same machine. It runs dense, one hot, grouped, recursive setup, and partitioned prover cases.

Reading benchmark reports explains the public claim behind each case, the timing and memory phases, and the generated report files.

Inspect arithmetic kernels

When an end to end trace points to public matrix multiplication or transform work, use the focused NTT benchmarks. They compare ring dimensions, input widths, exact CRT paths, and available SIMD implementations without setup or transcript work.

Arithmetic microbenchmarks explains those shapes and how to interpret the 50 bit AVX-512 IFMA path.

Diagnose failures

Troubleshooting covers unsupported schedule requests, setup cache recovery, equality table limits, thread selection, verification rejection, and the Jolt guest path. Each entry begins with the public error or observable behavior and gives the next concrete check.

Akita treats these operating tools as part of the PCS. The same external catalog identity connects setup, proving, verification, profiling, and CI comparison.

Feature flags and build recipes

Akita uses Cargo features for transcript backends and compute support. Schedule rows are external runtime artifacts, not Cargo features. The default akita-pcs build is a parallel CPU configuration for ordinary use.

Default features

The normal build uses both:

cargo build -p akita-pcs --release

Common build recipes

Sequential CPU build

Keep the default transcript while removing Rayon:

cargo build -p akita-pcs --release \
  --no-default-features \
  --features transcript-blake2b

This build produces the same protocol results. It changes local execution and performance.

Schedule families

Choosing fp128::DenseBounded, RecursiveCommitmentConfig<_>, or a multi-chunk preset does not change the feature graph. Load the matching .aks artifact from application-owned storage and pass its bytes to AkitaCommitmentScheme::from_schedule_artifact. The config validates the family name and planner-policy digest before any row can be used.

Disk backed public setup

cargo build -p akita-pcs --release --features disk-persistence

This stores public matrix coefficients and setup prefix artifacts. Prepared NTT caches remain local memory state and rebuild from the public setup.

Backend routing requires no Cargo feature; see backend routing.

Transcript backends

Production builds enable exactly one transcript backend.

The transcript backend is part of proof compatibility. Prover and verifier must use the same backend and protocol revision.

Schedule catalog storage

Tracked development artifacts live under artifacts/schedules/. Production applications may use a filesystem, database, object store, or another trusted parameter channel; Akita itself accepts bytes or a validated catalog and does not choose that storage policy. The configuration guide explains which family to choose.

Diagnostic features

response-model-diagnostics scans witness data that normal proving does not scan. Use it for model calibration runs, not for ordinary performance numbers.

The transcript_schedule example uses logging-transcript:

cargo run -p akita-pcs \
  --features logging-transcript \
  --example transcript_schedule

Profile CI features

The benchmark workflow uses narrow features such as profile-ci-fp32 and profile-ci-distributed. Each feature compiles only the modes in one CI shard. profile-ci is their compatibility union, and profile-bench-selected is an internal marker used by those groups.

Application builds should treat profile CI features as repository-only mode selectors. Production schedule coverage comes from the external catalog, not the feature graph. The benchmark report guide explains how the workflow uses these selectors.

Pin one feature contract

Pin every Akita crate to the same commit or release and record the accepted feature set and approved catalog digest with the deployment. This gives the prover and verifier the same catalog identity, transcript backend, public types, and proof format.

Profiling a workload

Akita ships one profile harness for complete PCS measurements. It runs the public statement preparation, setup, commitment, proof generation, encoding, and verification needed by a real opening proof. It also records the generated schedule and proof size breakdown.

Run the canonical profile

Run this command from crates/akita-pcs:

AKITA_MODE=onehot_fp128 AKITA_NUM_VARS=36 \
  cargo run --release --no-default-features \
  --features parallel,profile-onehot-fp128,transcript-blake2b \
  --example profile

This build contains only the adaptive fp128 one hot profile and its required protocol features. Schedule rows are loaded from the external artifact, while a narrow build keeps unrelated profile-mode monomorphizations out of the binary.

The harness requires --release. Set AKITA_ALLOW_DEBUG_PROFILE=1 only when debugging the harness itself.

What the default statement proves

onehot_fp128 commits to one multilinear polynomial with $2^{36}$ entries and opens it at one 36 coordinate point. The source stores one selected position in each 256 entry chunk.

The public statement proves commitment and opening consistency. One hot is the prover representation that lets Akita skip zero work. A host constraint system can prove the one hot property separately when its application needs that claim.

The admitted row from the external schedule artifact chooses the ring dimensions for the root and every later fold. The report prints the selected sequence. The application does not choose a fixed ring dimension for this run.

Read the main phases

The profile output separates these phases:

Statement preparation belongs to the harness, not the PCS. Use the named setup, commit, prove, encode, and verify phases for protocol comparisons.

Choose the workload

The compiled binary accepts only modes enabled by its feature set. An unknown mode prints the available names.

The repository also provides dense, small field, grouped, recursive setup, and multi chunk modes. Use the narrow feature that owns the selected mode when collecting numbers for comparison.

Record a Perfetto trace

Tracing is enabled by default for the profile harness.

The trace contains counters for effective CPU cores, CPU percentage, resident memory, virtual memory, and logical CPU count. One effective core means one core was busy for the complete sampling interval.

After writing the trace, the harness writes a sibling *.summary.json. The summary records the run identity, Git revision, exact peak resident memory, root wall time, CPU pool use, counter statistics, and time for every span label.

Inspect it without opening Perfetto:

jq '{run, root, peak_rss_gib, cpu_utilization}' \
  profile_traces/akita_nv36_onehot_fp128_*.summary.json
jq '.spans["AkitaCommitmentScheme::batched_prove"]' \
  profile_traces/akita_nv36_onehot_fp128_*.summary.json

The sampled memory line shows when memory changes. The exact process high water mark records the largest resident set even when a short peak falls between samples.

Compare thread policies

Set prover and verifier counts before the process starts. Rayon fixes its global pool during initialization.

A prover value of zero lets Rayon choose. A verifier value of zero reuses the resolved prover count. A positive verifier value creates a separate pool when the counts differ. The harness prints both resolved counts.

Build without parallel to measure the same workload sequentially:

AKITA_MODE=onehot_fp128 AKITA_NUM_VARS=32 \
  cargo run --release --no-default-features \
  --features profile-onehot-fp128,transcript-blake2b \
  --example profile

Measure response model data

Normal profile runs measure the production prover path. Response model calibration adds full witness scans, so enable it explicitly for those runs:

AKITA_MODE=onehot_fp128 AKITA_NUM_VARS=32 \
  cargo run --release --no-default-features \
  --features parallel,profile-onehot-fp128,transcript-blake2b,response-model-diagnostics \
  --example profile

This mode records exact source and response energies, planned caps, accepted nonces, and attempt counts. Those additional scans change prover work, so keep their results separate from normal performance measurements.

Continue the analysis

• Reading benchmark reports explains the CI matrix and pull request comparison artifacts.
• Arithmetic microbenchmarks isolates NTT public matrix multiplication and SIMD paths.
• Troubleshooting explains profile startup, schedule, allocation, cache, and thread errors.

Reading benchmark reports

Akita profile CI measures complete opening proofs at several public statement shapes. Pull request runs compare the branch with its merge base on the same runner, using the same feature set and interleaved executions.

The workflow at .github/workflows/profile-bench.yml defines the current cases. The report scripts turn those runs into a compact pull request comment and a full downloadable artifact.

Current statement matrix

The workflow splits these cases into narrow feature groups so each runner compiles only the profile modes it measures. Each runner loads the matching checked-in .aks schedule artifact at runtime.

What each statement means

The dense cases commit to one arbitrary multilinear table and open it at one point. The current fp32, fp64, and fp128 cases use 30, 29, and 28 variables.

The one hot source places one selected value in every 256 entry chunk. The public statement still checks commitment and opening consistency. The source representation changes prover work, not the meaning of the opening claim.

The multi group cases contain four polynomials in three ordered groups. Two earlier groups each contain one 16 variable polynomial and use separate points. The final group contains two polynomials that share one point. It uses 34 variables in the direct and standard recursive cases. The W8R2 case uses 32 variables.

Direct and recursive rows prove the same opening statement. The recursive setup row carries the large public setup contribution through a Stage 3 sumcheck. Direct mode evaluates that contribution during Stage 2.

W2R2, W4R2, and W8R2 divide the witness relation into 2, 4, or 8 chunks during the first folds. The generated schedule may choose different A, B, and D ring dimensions at each level.

Work performed by one sample

Every measured process performs these operations:

1. Generate deterministic source data, opening points, and expected values.
2. Build setup and prepare retained NTT requirements.
3. Commit to every polynomial group.
4. Produce and serialize one complete opening proof.
5. Check the reported proof size.
6. Build verifier setup.
7. Verify with the configured worker pool.
8. Verify the same proof again with one worker.

Each sample runs in a fresh process. Setup is built in memory, and profile CI does not enable disk persistence.

How the comparison works

Pull request runs compare with the merge base, not the current tip of main. The workflow builds both revisions and runs them on the same machine. It interleaves the two binaries so changes in runner load affect them as evenly as possible.

Each case has one discarded warmup process and three measured processes. The report uses the median time and the largest peak resident memory. A negative delta means that the branch used less time, memory, or proof data.

The x86 runners compile for the fixed x86-64-v3 target. This keeps the instruction set stable across machines while retaining AVX2. CPU fingerprints are recorded with the artifacts.

Compact pull request comment

The compact comment begins with the public statements. It then separates:

• Phase time.
• Peak memory and setup size.
• Proof size.
• The resolved A, B, and D dimension sequence.

Consecutive repeated dimension tuples are collapsed. This keeps the comment readable while still showing a schedule change.

Failed cases remain visible and name the phase that failed. A missing or unsupported merge base mode is reported instead of being compared with a different workload.

Full report artifact

scripts/profile_bench_report.py writes these files:

The detailed report shows every fold. Each fold records matrix geometry, decomposition, challenge parameters, witness or setup input, relation geometry, and proof components. Multi group rows repeat these blocks for each group instead of joining unrelated values.

The report also names the opening method for each group. A coefficient packing row includes its challenge subring dimension, packing factor, partial width, and packed field width. These fields explain a time or setup difference that a single ring dimension cannot explain.

Interpreting setup and cache numbers

Setup and preparation includes exact NTT prewarming for the selected commit and prove schedule. The retention policy skips large ring switch requirements that the runtime streams.

The harness checks that retained shared matrix cache entries do not grow during commit or prove. As a result, these phases measure warm retained entries plus intentional streamed work.

Prepared NTT cache size reports the retained shared matrix footprint at the prewarm boundary. Compression cache entries are built by their operations and are not included in that line. CpuPreparedSetup::ntt_cache_bytes reports the complete resident cache when an application needs that number.

Dense statement preparation appears in traces but is excluded from protocol phase comparisons. It includes deterministic evaluation generation and the independent expected opening calculation.

Keep reports tied to public claims

A performance number is useful only with its complete statement, schedule, feature set, thread policy, and Git revision. The Akita report preserves these facts so a proof size or timing change can be traced to the protocol choice that caused it.

Use Profiling a workload to reproduce one case locally. Use Arithmetic microbenchmarks when the report points to NTT public matrix multiplication as the next target.

Arithmetic microbenchmarks

Akita's complete profile is the main performance measure. Focused arithmetic benchmarks answer a narrower question after that profile identifies a hot kernel.

The ntt_matvec Criterion target measures public matrix multiplication without setup construction, transcript work, planning, or the rest of the proof.

Run the benchmark groups

cargo bench -p akita-cpu-backend --bench ntt_matvec -- rank_ring_dim
cargo bench -p akita-cpu-backend --bench ntt_matvec -- width
cargo bench -p akita-cpu-backend --bench ntt_matvec -- equal_output
cargo bench -p akita-cpu-backend --bench ntt_matvec -- equal_io

Use a shape filter for one quick comparison:

cargo bench -p akita-cpu-backend --bench ntt_matvec -- d64_r4_w128

Prepared cache construction is outside the timed region. The measurement includes digit validation, forward transforms, pointwise accumulation, inverse transforms, CRT reconstruction, and output allocation.

Compared kernels

Every common shape includes the production i8 commitment path and the unified i16 path. The i16 cases cover digit bases L2 through L11 where supported. The label states whether exact reconstruction uses only the base CRT residues or also needs the optional i16 tail.

On an x86 host with AVX-512IFMA, eligible labels also include ifma52. This path stores canonical 50 bit prime residues in u64 lanes and uses the IFMA52 instructions for exact arithmetic.

The label applies only to the selected exact i16 cache and kernel. The ordinary i32 NTT still dispatches to AVX2 on x86. The benchmark names these paths separately so an IFMA result cannot be mistaken for a global NTT backend change.

Ring dimension and rank sweep

The rank_ring_dim group tests ring dimensions 64, 128, 256, and 512. At each dimension it tests output ranks 1, 2, 4, and 8 with ring width 128.

This sweep changes both the scalar input size and the ring structure. Use it to see which dimensions are competitive for a specific matrix geometry, not to claim that a larger ring is always faster.

Width sweep

The width group tests widths 128 through 1024 at ring dimension 64 and rank 4. It shows how the kernel scales as the number of input ring columns grows.

Equal output and equal input cases

The equal_output group compares these shapes:

D64  rank 8
D128 rank 4
D256 rank 2
D512 rank 1

Each shape returns 512 field coefficients. Its scalar input size still grows with the ring dimension.

The equal_io group also adjusts the width:

D64  rank 8 width 1024
D128 rank 4 width 512
D256 rank 2 width 256
D512 rank 1 width 128

These shapes hold both scalar input and output sizes fixed. This isolates the trade between ring structure, transform cost, and available parallel work.

Understand the scaling

Let n = width * D be the scalar input length and m = rank * D be the scalar output length. An ordinary dense matrix multiplication costs O(m * n).

Akita stores the matrix as rank * width negacyclic ring blocks. With a prepared matrix, the approximate work for each CRT residue is:

input transforms:  n * log D
pointwise products: m * n / D
output transforms: m * log D

The ring structure divides the pointwise term by D. Larger rings also reduce prepared matrix storage for a fixed scalar input and output shape.

Transform work grows with log D. Exact CRT bounds also grow with D, and a shape with fewer ring rows may expose less parallel work. The generated planner therefore chooses dimensions from measured and certified candidates instead of always choosing the largest ring.

Return to the complete proof

Criterion throughput counts rank * width * D coefficient products. The complete profile adds setup, commitment assembly, sumcheck, transcript work, proof encoding, and verification.

After a kernel change, run the matching complete mode from Profiling a workload. The end to end result decides whether the change improves Akita for its host application.

Troubleshooting

This page covers failures that can occur before or around a proof run. When an error comes from verification, first read Verifier only integration and the verifier no-panic contract.

The profile example exits before running

The profile example requires a release build because debug timings are not useful. If it prints this message, add --release to the Cargo command.

examples/profile must be run with --release for meaningful timings.

Set AKITA_ALLOW_DEBUG_PROFILE=1 only when you need to debug the harness. Do not compare timings from that run with release results.

An unknown AKITA_MODE also stops the process. The error lists the modes that were compiled into the current binary. A build with a narrow feature set can contain only one profile family, so use the matching mode and feature. See Profiling for the canonical command and Feature flags for the available profile modes.

The requested schedule is unsupported

AkitaError::UnsupportedSchedule means the catalog supplied to the scheme does not contain a row for the exact request. Runtime code does not invoke the planner to fill a missing row.

Check these causes in order:

1. Confirm that the application loaded the intended family artifact and that its catalog identity matches the setup or preprocessing package.
2. Confirm that the chosen preset supports the requested polynomial arity, group shape, and opening method.
3. For a recursive grouped opening, commit each precommitted group with the base configuration. Use the recursive configuration for the final grouped commitment and proof.
4. If the request should be supported, record the complete error text and the exact configuration, num_vars, polynomial counts, and ordered group layout. A catalog row may need to be generated and shipped.

See Configuration and planning for catalog ownership and Recursive grouped openings for the grouped setup pattern.

Equality table allocation is rejected

Akita checks each materialized equality table allocation against a 1 GiB budget. A request over that limit returns AkitaError::InvalidInput before the allocation. The message includes the table label, element count, byte count, limit, and source location.

Lower num_vars when testing a workload that does not need the larger domain. For a production request, keep the complete error and configuration details. Some protocol paths use split equality weights and do not materialize the full table. Do not raise the limit as a first fix. It is an allocation safety boundary, not a tuning knob.

This check covers equality tables only. The witness, setup matrix, retained NTT entries, and proof workspace use additional memory. Use the RSS counters and summary described in Profiling to locate the phase where memory grows.

A setup cache cannot be loaded or saved

The disk-persistence feature stores the public setup matrix and setup prefix registry. It does not store backend NTT caches.

Cache entries use versioned filenames, and prefix registry names include a digest of the setup requirements: the capacity bound and the sorted setup prefix slot ids. Old, truncated, corrupt, or mismatched entries are not accepted as current setup. Akita logs the load failure and regenerates the setup. If saving the replacement fails, Akita logs a warning and continues with the in-memory setup.

Akita chooses the cache directory from environment variables in this order:

1. If LOCALAPPDATA is set, use $LOCALAPPDATA/akita.
2. Otherwise, if HOME/Library/Caches exists, use $HOME/Library/Caches/akita.
3. Otherwise, if HOME is set, use $HOME/.cache/akita.

This order is independent of the operating system. If neither environment variable is set, disk persistence has no cache path.

Normal upgrades do not require manual cache deletion. If every run reports a write failure, check that the directory is writable or build without disk-persistence. If every run rejects a newly written entry, preserve the warning and affected cache file for diagnosis before removing that file.

Thread counts do not match the profile request

The profile harness reads AKITA_PROFILE_PROVE_THREADS and AKITA_PROFILE_VERIFY_THREADS. Each value falls back to RAYON_NUM_THREADS when it is missing or invalid. The prover pool resolves first. A prover value of 0 lets Rayon choose the global pool size. A verifier value of 0 reuses that resolved prover size. A positive verifier value creates a separate pool only when it differs from the prover size. The harness prints both resolved counts at startup.

Set the profile variables before the process starts. Rayon global pool size is fixed during initialization. When the parallel feature is disabled, prover and verifier work is sequential and all reported thread counts are one.

Verification rejects an artifact

A verifier error does not always mean the proof was wrong. Decode and shape errors mean the public artifact was malformed. A statement that does not fit the verifier's setup or the selected schedule row returns the failing check's own error before transcript replay starts: InvalidSize or InvalidPointDimension for a statement larger than the setup, and InvalidInput with a message for a claim group or commitment profile that does not match. AkitaError::InvalidProof means the proof bytes failed a protocol check.

Confirm that prover and verifier use the same Akita revision, configuration, transcript backend, transcript domain, ordered commitment groups, opening points, and claimed evaluations. Akita does not preserve proof bytes across revisions. Regenerate the proof and verifier setup after an upgrade.

Akita reports an internal error

AkitaError::Internal means an invariant that Akita maintains itself failed after the inputs were accepted. The cause is a bug in Akita or in a custom backend. It is not a problem with the request, the setup, or a proof. The message names the failed invariant. Report it with the complete error text and the configuration that produced it. Verification can report this error too, and it still means a bug rather than a rejected proof.

A Jolt recursion run fails

The Jolt host performs strict native decoding and Akita verification before it starts guest preprocessing. Fix that preflight error first.

The guest output has three defined values:

A guest panic is reported separately as guest_panic. Start a new schedule or larger arity with --trace-only and confirm that it fits the guest trace limit before running the full Jolt prover.

For a panic, temporarily change the guest attribute to backtrace = "dwarf", rebuild the guest, and run with JOLT_BACKTRACE=full. The exact commands, cache paths, memory limits, and current trace limit live in the profile/akita-recursion runbook.

What to include in a bug report

Include the full error, Akita commit, Cargo feature set, configuration type, ordered group layout, num_vars, polynomial counts, operating system, CPU architecture, and resolved thread counts. For performance or memory failures, also include the profile summary JSON and the command that produced it. Do not attach private witness data or application inputs.

Integrating with a proof system

Akita is a standalone polynomial commitment scheme. It can serve any proof system that works with polynomial evaluation tables and can state the values it wants to open. The host system does not need to adopt Akita's internal ring arithmetic or proof planner. It needs a small adapter that translates its own polynomials and claims into Akita's public interface.

This chapter describes that adapter. The Jolt recursion chapter then shows a complete integration in which a zkVM executes the Akita verifier.

What the adapter owns

The host system owns the meaning of the committed data. It may be a virtual machine trace, a lookup table, a memory-checking polynomial, or another value used by the host protocol. Akita sees an ordered collection of polynomial tables and opening claims.

The adapter joins these two views.

This is the main design rule: keep the host meaning outside Akita, but make the translation into Akita explicit and deterministic. The prover and verifier must construct the same ordered statement from the same public host data.

Start from the host's polynomial model

Akita's current API opens multilinear polynomials. A multilinear polynomial in $n$ variables is represented by its $2^n$ values on Boolean inputs. Many proof systems already store trace columns and lookup tables in this form.

For each host polynomial, record:

1. Its field.
2. Its number of variables.
3. Its table representation.
4. The point where the host protocol opens it.
5. The position of its claimed value in the host transcript.

Use DensePolynomial for a general evaluation table. Use OneHotPoly when the host already has one selected value in each fixed size chunk. Keeping one hot data structured avoids building a large dense table only to recover the same sparsity inside the prover.

Polynomials with the same arity can share a commitment group. Polynomials in one opening group also share one opening point. If the host opens different groups at different points, preserve those groups and their order. Akita can batch them into one proof.

Select the field boundary once

Choose one Akita configuration whose base field matches the values supplied by the host. Keep conversion code at the adapter boundary. A field element should enter Akita through one canonical conversion and leave through one canonical encoding.

Do not convert values by copying their in-memory bytes. Rust field types can use different internal representations even when they describe the same prime field. Convert through canonical integers or an agreed canonical byte encoding, then test the boundary with zero, one, the largest canonical value, and random values.

The configuration guide explains the shipped dense and one hot configurations. Akita chooses the ring dimensions and fold schedule after the adapter supplies the field and claim shape.

Build one public statement

The host should define a single versioned Akita artifact. It contains, or securely identifies, everything the verifier needs:

• the Akita revision and configuration;
• the verifier setup;
• the exact generated schedule selection;
• the ordered commitments;
• the ordered opening points and claimed values;
• the proof bytes;
• the session bytes used by this host protocol.

This bundle is more than a transport format. It is the complete public claim. The verifier should not infer missing group order, try several configurations, or choose a schedule after receiving the proof.

Use session bytes owned by the host, such as my-system/trace-openings/v1. A versioned label separates this proof from every other Akita use and gives the host a clean protocol upgrade boundary.

The proof encoding and transcripts chapter gives the exact Akita objects and decoding flow.

Place the verifier where it provides the most value

Akita's verifier is a separate Rust package. A host can place it in several environments:

The direct akita-verifier path has no polynomial backend, setup generator, or planner search. This makes it the right boundary for small verifier targets. The host decodes the public bundle, reconstructs the typed statement, starts a fresh verifier transcript, and calls AkitaVerifier::batched_verify.

When the verifier itself runs inside another proof system, begin with native verification of the same bundle. Then move the exact accepted bundle into the guest or circuit. This gives the integration a simple debugging order:

host creates Akita proof
        ↓
native Akita verifier accepts it
        ↓
guest or circuit decodes the same public bundle
        ↓
guest or circuit runs the Akita verifier
        ↓
outer proof system proves that execution

The native check separates an Akita statement error from a guest runtime or outer prover error.

Plan setup and upgrades as deployment inputs

The proving service prepares the large reusable compute state. The verifier receives only the public setup needed by its selected schedule. A deployment can package this setup with the verifier or authenticate it by an application owned identifier.

Pin every Akita crate to one revision. Akita's protocol and proof encoding can advance together, so treat an upgrade as a new host artifact version. Rebuild setup packages, regenerate proof fixtures, and run the complete host-to-verifier path before deploying the new version.

Validate the integration at its real scale

A useful integration test covers more than one successful proof. It should:

1. Compare host and Akita field conversions in both directions.
2. Compare each claimed value with an independent host evaluation.
3. Round trip the complete public artifact through serialization.
4. Accept a valid proof through the final verifier entry point.
5. Reject changed commitments, points, values, schedules, and proof bytes.
6. Measure proving time, peak memory, verifier time, and proof size at the host's intended polynomial sizes.

For a zkVM or recursive circuit, also measure input decoding separately from Akita verification. A large verifier setup can make transport and decoding the dominant cost even when the verifier kernel is fast.

The repository's Jolt harness follows this pattern. It produces a real Akita proof, checks it natively, transports one bounded verifier bundle into a RISC-V guest, runs the direct verifier there, and measures each phase.

Jolt recursion

Jolt is a zero-knowledge virtual machine that proves the correct execution of 64-bit RISC-V programs. Akita's Jolt integration turns the Akita verifier into one of those programs. Jolt can therefore produce an outer proof that says an Akita opening proof was accepted.

This is recursive verification: one proof system proves the execution of another proof system's verifier. It lets a host combine Akita's compact, post-quantum polynomial commitments with the execution and composition tools provided by a zkVM.

The live integration is the standalone workspace under profile/akita-recursion/. Its runbook contains current commands, environment variables, and measured trace notes.

The complete path

The integration has four small crates.

The data flow is direct:

Akita artifact generator
        │
        │ AkitaJoltInputs bytes
        ▼
strict native Akita verification
        │
        ▼
Jolt RISC-V guest
        │ decode input
        │ rebuild statement
        │ run Akita verifier
        ▼
guest result: accepted or rejected
        │
        ▼
Jolt proves and verifies the guest execution

Before compiling or proving the guest, the host strictly decodes the bundle and runs the native Akita verifier. This makes failures easy to locate. If the native check fails, the public statement or Akita proof is wrong. If it passes, the remaining work belongs to guest compilation, execution, or the Jolt prover.

What crosses into the guest

AkitaJoltInputs<F, D> is one versioned verifier bundle. It contains:

• the transcript domain;
• the polynomial arity and opening point;
• the claimed value and commitment;
• the exact generated schedule selection;
• the verifier setup;
• the canonical native Akita proof bytes.

The decoder checks a format marker, the fixed source-view dimension, bounded lengths, complete consumption of the input, and a schedule-derived upper bound on the proof stream before allocation. The guest then rebuilds the same opening statement used by the native verifier.

The guest depends on akita-verifier rather than the complete PCS package. It does not carry the polynomial backend, setup generator, or planner into the RISC-V program.

The current configuration

The harness uses proof_optimized::fp128::OneHot. Its input is one structured one hot polynomial, and the guest is compiled with a source-view dimension of $D=256$. This fixed type is the root envelope for the current adaptive configuration. The generated schedule still chooses the dimensions used at each later fold.

AKITA_NUM_VARS chooses the polynomial arity. The artifact generator resolves the approved row for that exact arity and rejects a row that does not match the guest's fixed source view. The default is 20 variables. The 32 variable target uses the same $D=256$ source view and is the large recursion benchmark.

The recursion workspace is separate from the main Cargo workspace. It pins Rust 1.95, the RISC-V targets, and one exact Jolt revision. This keeps Jolt's toolchain and patched dependencies out of the main Akita dependency graph.

Run the native artifact and guest trace

Install the Jolt CLI from the same revision pinned by the recursion workspace. Then run these commands from profile/akita-recursion/:

cargo build --release

AKITA_NUM_VARS=20 \
    ./target/release/akita-recursion-artifact

ZEROOS_GUEST_RUSTFLAGS=-Zunstable-options \
    AKITA_RECURSION_LOG=info \
    ./target/release/akita-recursion-host \
    --trace-only \
    --trace-output /dev/null

The artifact command proves and verifies natively before publishing the input blob. The trace command compiles and executes the guest without running the full Jolt prover. It is the fastest way to confirm that a new Akita revision or larger arity fits the guest.

The guest reports three cycle regions:

At large arities, decoding the expanded verifier setup can dominate the guest trace. Measuring it separately makes that transport cost visible instead of attributing it to the Akita verifier.

Run the full recursive proof

Begin with the 20 variable target, whose trace fits the guest's current $2^{32}$ instruction limit:

AKITA_NUM_VARS=20 ./target/release/akita-recursion-artifact

ZEROOS_GUEST_RUSTFLAGS=-Zunstable-options \
    AKITA_RECURSION_LOG=info \
    ./target/release/akita-recursion-host \
    --input target/akita_recursion_inputs.bin

The full command performs Jolt preprocessing, proves the guest execution, and verifies the resulting Jolt proof. Success ends with Akita-in-Jolt proof OK, is_valid=true, and guest_panic=false.

The 32 variable target is intended for a server with enough memory for its large input and trace. Measure it with --trace-only first. The current follow-up is to record its adaptive trace length and raise Jolt's trace limit if that measured execution exceeds $2^{32}$ instructions.

Rejection is part of the proved execution

The guest returns a small status value:

Malformed public input produces a defined nonzero guest result. Jolt proves that result in the same way it proves a successful result. A guest panic is reported separately.

Trusted benchmark setup

The host always performs strict setup decoding and Akita verification before the guest runs. For cycle measurement, the RISC-V benchmark guest then uses the already checked expanded setup matrix directly. This keeps the benchmark focused on transport and verifier execution.

A deployment can preserve the same trust boundary by authenticating the setup package outside the guest. A deployment that receives setup from an untrusted source should use strict setup decoding inside the guest. The normal guest feature keeps strict decoding enabled; the host opts into the benchmark path only for the ELF it builds through the pinned Jolt SDK.

Keep the integration current

The smoke workflow compiles and tests the glue, artifact, and host against the current Akita APIs. It does not run the expensive Jolt trace or proof. After an Akita or Jolt upgrade:

1. Run the recursion workspace tests and release build.
2. Generate a fresh artifact and confirm native verification.
3. Run --trace-only and compare the three cycle markers.
4. Run the full Jolt proof at a known arity.
5. Measure the intended production arity on its deployment class machine.

Pin the complete integration to one Akita revision. Regenerate the verifier bundle after every protocol upgrade because setup, schedule identity, proof shape, and proof encoding advance together.

How it works

Akita opens a committed polynomial by repeatedly replacing a large hidden table with a new committed witness. Every replacement comes with a proof that the new witness carries the same opening claim and satisfies the required commitment relations. The last witness is small enough for the verifier to check directly.

That repeated reduction is the central idea behind the implementation. The configuration decides the exact sequence of folds. The prover executes it. The verifier derives the same sequence from public inputs and rejects any proof whose shape or messages do not match.

This part of the Book explains that path from public configuration to final acceptance. It is for contributors, integrators who need to understand the proof boundary, and reviewers who want to connect each protocol claim to the code that enforces it.

The same batched_prove and batched_verify APIs always use a folded schedule. Every schedule contains a root fold and a terminal cleartext witness, with zero or more recursive folds between them. The root may connect directly to the terminal witness when no recursive fold is needed. Schedule selection rejects a request when the audited fold domain contains no valid complete schedule.

The complete proof in one view

An Akita opening moves through the following stages.

1. Resolve the schedule. The selected CommitmentConfig maps the workload shape to one generated schedule row. That row fixes every fold, matrix dimension, decomposition basis, opening method, and terminal profile.
2. Prepare the setup and commitments. The prover materializes the required prefix of the public setup. Each polynomial group is committed with the parameters assigned to that group.
3. Bind the public statement. The transcript absorbs the configuration, setup identity, schedule, commitment groups, opening points, and claimed evaluations before deriving challenges that depend on them.
4. Run the root fold. The prover prepares each requested opening, builds the first fold relation, and proves that relation with the scheduled sum-checks. The fold emits a recursive digit witness and a new opening claim; the root witness need not be smaller than its input.
5. Run any recursive folds. Each nonterminal successor authenticates the witness produced by its predecessor and repeats the same reduction. A fold may also authenticate a prepared setup prefix when setup offloading was selected.
6. Check the terminal witness. The final witness is sent in clear encoded form. The verifier checks its consistency, commitment relation, evaluation trace, and any scheduled norm bound directly. There is no further recursive commitment and no terminal sum-check cascade.

The verifier performs the same steps in the same transcript order. It does not trust the proof to choose a schedule or describe its own lengths. Public configuration and claims determine the expected shape before proof data is decoded.

polynomial groups + opening claims
                 |
                 v
       generated root schedule
                 |
                 v
        root relation and fold
                 |
                 v
      next committed digit witness
                 |
          zero or more recursive folds
                 |
                 v
      clear terminal witness check
                 |
                 v
              accept

What one fold preserves

A fold reduces the current relations to a recursive opening claim without weakening their connection to the committed source. The full next-level witness includes auxiliary and representation data, so its physical size is not guaranteed to decrease at every fold. In particular, root folds may be non-contractive. Akita maintains three invariants at every nonterminal level.

The opening claim remains attached to the witness

The current level starts with one or more claims that committed polynomials evaluate to stated values at stated points. Its relation turns those claims into one evaluation of the next witness. That value becomes the opening claim consumed by the successor.

Multiple commitment groups may enter the root together. Each group keeps its own commitment, point, values, and parameters. The root batches their checks, then returns to the ordinary recursive path with one folded witness.

The commitment relations remain binding

The prover cannot choose an arbitrary successor witness. Each fold proves the relations that connect source digits, inner commitment values, outer commitments, opening digits, and the folded response. The proof may carry raw commitment values or smaller compressed payloads, but both forms enforce the same semantic commitment statements.

Every size and method comes from the schedule

The schedule owns the ring dimensions for the A, B, and D matrix roles, the number of blocks, the digit bases, the opening method, the proof shape, and the terminal policy. Prover and verifier consume these values through the same typed schedule structures. Unsupported geometry fails during schedule resolution or validation rather than selecting an improvised protocol.

The main branches in the protocol

The fold engine is shared, but a generated schedule can select among several well-defined paths.

These choices are not independent switches supplied by a proof. The generated schedule contains one complete compatible assignment.

Read this section by goal

Understand the system first

Read these chapters in order:

1. Architecture overview for crate ownership and the public commit, prove, and verify lifecycle.
2. Configuration and planning for the generated schedule and the difference between offline search and runtime resolution.
3. Setup and commitment for the public matrices and Ajtai commitment.
4. The proving protocol for one fold from input claim to successor witness.
5. Verification for transcript replay, final checks, and malformed-input rejection.

Implement or review a proof stage

Start with The proving protocol, then follow its links to the relation, layout, and sum-check chapter for the stage being changed. Pair the prover path with the matching page under Verification. The protocol is complete only when both sides compute the same claim from the same ordered messages.

Review security boundaries

Read Transcript and instance binding, Verification, and Security model. Then trace each accepted norm bound and matrix role back to the generated schedule and Module-SIS tables. The useful review question is not merely whether an equation appears in the prover. It is whether the verifier derives and enforces every public condition needed by that equation.

Review performance

Read Optimizations after the protocol path is clear. The fast implementation changes table representations, arithmetic kernels, and execution order. It does not define a second proof system. Scalar references, schedule checks, and verifier equations remain the correctness boundary.

Chapter map

Where the lifecycle enters the code

The public orchestration lives in crates/akita-pcs/src/scheme/. The prover walk begins in crates/akita-prover/src/protocol/prove/root.rs. The verifier mirror begins in crates/akita-verifier/src/fold/verify.rs.

Those files should remain orchestration layers. Mathematical rules belong to their canonical layout, algebra, schedule, sum-check, or verifier helpers. A reviewer should be able to follow the lifecycle here, enter one of those three paths, and find one implementation owner for every rule.

Architecture overview

How the workspace is organized and how a single commit → prove → verify call flows through it.

Crate map

Workspace members live under crates/. There is no akita-scheme crate: end-to-end AkitaCommitmentScheme orchestration lives in akita-pcs.

Dependency graph and ownership rules: docs/crate-graph.md. CI enforces one-way boundaries via scripts/check-crate-deps.sh.

Key structural facts:

• akita-error is the lowest shared failure layer. It owns AkitaError and reusable exact usize formulas in akita_error::checked. These formulas return Option; each caller maps failure to the AkitaError variant that describes its protocol boundary. Field arithmetic lives in the shared external jolt-field crate.
• akita-planner owns offline schedule search and artifact emission. Normal search is Cfg-free and is not on the verifier runtime dependency path. The optional catalog-gen feature enables akita-config, so artifact-emission binaries may name concrete CommitmentConfig presets.
• akita-verifier depends on akita-config, akita-schedules, and akita-params. It receives a validated trusted catalog and never reaches planner search.
• Verifier-only integrations should use akita-verifier + akita-types + akita-config, not the umbrella akita-pcs package.

End-to-end lifecycle

1. Preset and trusted catalog selection. The caller picks a CommitmentConfig preset and loads the matching schedule artifact from the same trusted parameter source used for setup or preprocessing. The caller constructs one AkitaCommitmentScheme<Cfg> with that catalog. The catalog contains complete expanded rows. Planner search remains offline. Each row selects SubringCoefficientPacking or EvaluationTrace for every nonterminal fold. EOR is present only for an evaluation trace opening over a proper extension field. See Fold path and field geometry.
2. Setup. akita-setup scans the rows in the scheme's trusted catalog and expands the setup (Ajtai matrices and stride envelopes) to cover the requested capacity.
3. Commit. The application consumes its polynomials into a reusable CpuBackend and commits the imported source using GroupContext. The result contains a public commitment and an opaque handle retaining the exact source and commitment parameters. Scheduler mode selects the scalar row when the group has no precommitted groups, or the exact grouped row when it does. Explicit mode validates caller-supplied root parameters. A group committed under a scalar row may later be supplied as a precommitted group.
4. Claims. The caller supplies ordered PolynomialGroupClaims; each group owns its complete point, evaluations, and commitment.
5. Prove. batched_prove receives retained commitment handles and public claims. The backend checks that each claim matches its commitment before preparing a fresh proof session. The generic prover walks the schedule, absorbs backend messages, samples challenges, and assembles the proof. Source coefficients and witness arithmetic remain inside the backend.
6. Verify. batched_verify resolves the proof row digest in the trusted catalog, replays nonterminal sumchecks and relation-matrix evaluations, then closes the terminal with direct consistency/A and weighted trace checks. The proof never supplies schedule bytes. Prover and verifier share bind_transcript_instance_descriptor so Fiat-Shamir challenges match.

Entry points: crates/akita-pcs/src/scheme/mod.rs, crates/akita-prover/src/protocol/prove/root.rs, crates/akita-verifier/src/fold/verify.rs.

Further reading: Configuration and planning, Setup offloading, Proving, and Verification.

Recursive setup offloading adds one setup-only Stage 3 message group at each nonterminal producer whose successor consumes a setup prefix. Its wire payload is the setup claim, the setup-prefix evaluation, and one degree-two sumcheck over the native setup domain. Its round count and planned size do not depend on the successor witness length. The setup offloading chapter follows this path from offline planning through the recursive verifier handoff.

Prover consumer boundary

Protocol orchestration passes private state as associated handles through OpaqueProverConsumer. It owns transcript order, public plans, commitments, claims, and round messages. The selected consumer owns opening buffers, fold responses, compression witnesses, recursive witnesses, and mutable sumcheck and extension-opening sessions.

One CpuBackend implements the opaque contracts directly. Physical routing, prepared setup storage, and cache policy live in akita-cpu-backend. The generic prover has no production dependency on that crate. Source import and persistence are application/backend operations. Setup prefixes enter generic proving as ordinary reusable commitment handles with checked public metadata.

A shared ConsumerIdentity binds all fold levels to the same setup. A ProofContext identifies an active proof, fold level, and source group before private preparation starts. Witness assembly checks those identities before consuming its inputs, and checks that each accepted fold carries its original public challenges. EOR openings also bind to the exact witness operation that produced them. Finishing or abandoning a proof invalidates its retained scope leases; round operations check those leases without locking the scope registry.

Ring-dimension ownership

The cyclotomic ring dimension is schedule-derived shape metadata, not a type parameter of the protocol. Protocol data — commitments, hints, proofs, claims, and root polynomial storage (DensePoly<F>, OneHotPoly<F, I>, and their enum wrapper) — is flat field-element vectors (RingVec<F>). Per-level CommitmentRingDims (d_a / d_b / d_d from CommittedGroupParams::role_dims()) is the operation authority for how those vectors are interpreted; levels may differ. Here, role is the historical protocol name for a commitment matrix's fixed job: A carries the relation witness, B commits the next witness, and D commits the opening digits. The matrices do not switch roles when their ring dimensions change. User-facing prose therefore calls a non-uniform tuple such as 128/64/64 per-matrix ring dimensions and a change between levels a ring-dimension transition. [validate_schedule_ring_dims] checks every scheduled dimension directly against the field's dispatch and NTT support. The public setup is one flat field stream with no ring dimension.

A, B, and D matrix dimensions form a separate admission domain and are all at least 64. Compressed commitments derive their two smaller dimensions directly from the modulus profile (q128: 16/8, q64: 32/16, q32: 64/32). Those compression-only dimensions never become CommitmentRingDims and never reduce the ordinary relation's common coefficient block.

Every function on the prove/verify path has one of two roles:

• Orchestration reads schedule types, drives the transcript, and moves D-free storage. It never carries const D.
• Kernels (NTT, digit decomposition, commit/opening folds, ring-switch arithmetic) are const-generic over D and receive extracted numbers, never schedule types.

The bridge is the operation adapter: a D-free function that extracts the ring dimension of the specific data one operation touches and enters the kernel through akita_params::dispatch_for_field! exactly once, returning D-free storage. Dispatch is per operation — never per level or per proof — so that per-matrix ring dimensions inside one fold (d_a/d_b/d_d, see specs/runtime-ring-cutover.md) reduce to feeding different dimensions to different adapters. CommittedGroupParams::role_dims() names the per-matrix ring dimensions; prove and verify hot paths dispatch on d_a(), d_b(), or d_d() per operation, not on a single fused dimension.

The normative contract (discriminator rule, forbidden facade/level- monomorphization patterns) lives in specs/runtime-ring-cutover.md. Mixed-dimension malformed proof rejection is covered by crates/akita-verifier/tests/mixed_d_rejections.rs through the verifier API.

Core types

Opening batch kernels validate one authoritative challenge partition against every source and return one aggregate witness per requested chunk. The protocol combines their z values into the global fold witness; non-fused backends reuse the public checked aggregator within each chunk.

Per-fold execution ownership

The batched_prove API keeps one transcript while assigning each successor fold to a registered backend instance. A typed executor owns its local session and setup-prefix handles. The coordinator carries a public continuation (level, commitment binding, challenges, and openings) separately from an opaque, owner-tagged witness/material pair. Handle pairs and transfer packets are erased only at dispatch; all arithmetic kernels keep their associated handle types.

Backend routing

Backend routing is always available through batched_prove; it requires no Cargo feature. A nonterminal fold reduces the current claims to an opening of a successor witness. The complete successor witness need not be smaller than its input.

Before preparing any executor, a caller-defined policy resolves the owner of every fold. Each producer commits its successor once. On a switch, the source exports a typed packet, a registered bridge converts it, and the destination imports local handles synchronously. The source finishes its sumchecks before the destination executes its fold. The terminal fold can have its own owner as well.

Construct BackendRegistry<Cfg>, register each backend with its local akita_prover::SetupPrefixProverRegistry. Registration returns a BackendId. Pass the registry, typed opening inputs, and route to batched_prove. FixedFoldRoute::new(vec![a, b, a]) assigns folds 0, 1, and 2 to those registry entries. Custom FoldExecutionPolicy implementations select every level through choose_backend, called once per level in order before preparation; its current owner is absent at level 0. Choices remain fixed throughout the proof. The registry dispatches the root to the selected executor, checks its commitment handle family, and validates that the handles belong to that instance. The route stores only IDs. Each instance supplies the prefix handles needed by its folds and successor commitments. Registration builds a union of public prefix slots and rejects conflicting public values for a shared slot ID. Public agreement is checked once for the immutable registrations; each selected executor must still have its required local handles. Registration also rejects duplicate instances; IDs from another registry reject. Route implementations own any cost model; Akita does not request or compare cost estimates.

Backends implement SuccessorExportKernel and SuccessorImportKernel alongside ordinary typed kernels. Backend-provided conversions implement SuccessorBridge on Edge<A, B>. Register the bridge explicitly with registry.register_bridge::<A, B>()? before selecting a switch. Same-type instance switches (two CpuBackends) still need register_bridge::<CpuBackend<F, E>, CpuBackend<F, E>>()?. Heterogeneous routes register each directed edge (for example PrivateCpu ↔ CpuBackend). For an application-owned converter, use registry.register_bridge_with::<A, B>(convert)?. It accepts a function or closure from A::ExportPacket and the handoff plan to B::ImportPacket, allowing applications to connect dependency-owned backends without implementing a foreign trait. Both registration APIs share the same type-pair key and reject duplicates. A missing bridge or foreign ID rejects before any executor is prepared. Only selected instances are prepared, and their prefix handles and fold capacities are checked before opening the transcript. Akita never silently reroutes a proof. A single instance needs no bridge: same-ID choices retain native handles without export, conversion, or import.

The handoff is blocking: export a typed packet, convert it to the destination's packet, then validate and import both handles. Every import packet exposes HandoffMetadata: the identity of this transfer and the logical witness geometry. The destination checks this metadata against the handoff plan before adopting private payloads. The coordinator dispatches typed bridges without prescribing payload encoding. CPU self-edges share immutable packed witness and material storage. External bridges can construct CpuImportPacket::new(descriptor, sections) with packed or signed digits, canonical field coefficients, and compression sections described by CpuPacketDescriptor. These section types and encodings belong to akita_cpu_backend; other backend pairs can use their own packet formats. CPU exports provide into_sections() for conversion to another representation. Import checks section lengths, the admitted handoff, digit bounds, and canonical encodings. Portable packets carry logical witness digits only; CPU import derives the tensor representation when needed. Native CPU self-edges retain the private transformed cache through shared storage. For outer successors, import trusts that the bridge's inner rows and compression material reproduce the public commitment; it checks geometry and canonical encoding, and the verifier checks consistency. Terminal successors also cross-check the imported inner rows against the public fields. Switching retains the producer's handles until its sumchecks complete. The CPU scheme method uses this same prover with every level assigned to its supplied backend. Routing does not change the setup, commitment, transcript, or proof format.

Before any proof computation, the coordinator calls prepare_executor on each selected backend to open its local proof session. It then calls begin_fold for every assigned level to validate that level and its successor commitment work before opening the transcript. Preparation does not require a backend to execute unassigned levels. All prepared sessions use ProofScope to finish on success or abort on failure, including scopes whose completion fails. A registry supports repeated proofs, with one active proof at a time.

Implementation: crates/akita-prover/src/protocol/prove/registry.rs, crates/akita-prover/src/protocol/prove/execution.rs, crates/akita-prover/src/backend/transfer.rs, and crates/akita-cpu-backend/src/opaque/transfer.rs. Design record: specs/dynamic-backend-bridges.md. Regression coverage: crates/akita-pcs/tests/dynamic_backends.rs.

Configuration and planning

This chapter explains how a preset becomes a concrete recursion schedule. It covers the CommitmentConfig trait, the fold parameters stored in a schedule, and the planner that searches for schedules and prices their proof size offline.

CommitmentConfig and presets

The single user-facing trait that defines every per-config policy hook (algebra, exact SIS profile, decomposition, layout, schedule, transcript bind, prove params), and the fp32 / fp64 / fp128 preset families built on it.

Both field roles live on the trait: Field carries committed witnesses, setup matrices, and SIS, while ExtField carries public opening points, claimed evaluations, and Fiat-Shamir challenges. The protocol geometry gates on whether the two roles coincide (EXT_DEGREE == 1, all fp128 presets) or claims live in a proper extension (EXT_DEGREE > 1, fp32 / fp64), never on field bit-width. See Fold path and field geometry.

CommitmentConfig selects bounded adaptive A, B, and D domains. It does not carry a separate default ring dimension. The resolved schedule owns every dimension used by setup preparation, commitment, proving, and verification. Setup-prefix slots also record the dimension selected by the fold that consumes the prefix.

Implementation map

• crates/akita-config/src/lib.rs:54-120.
• crates/akita-config/src/proof_optimized/.
• crates/akita-planner/README.md for the current planner/config boundary.

Runtime witness chunking

A deployment can choose how many witness chunks it uses and how many leading folds remain chunked without defining another configuration type. For example, two chunks across four leading folds use:

#![allow(unused)]
fn main() {
let chunking = akita_params::ChunkedWitnessCfg {
    num_chunks: 2,
    num_activated_levels: 4,
};
let policy = akita_config::policy_of::<Config>(chunking);
}

The same chunking value is an explicit argument to TrustedScheduleCatalog::<Config>::from_artifact_bytes or AkitaCommitmentScheme::<Config>::from_schedule_artifact. Config still fixes the field types, decomposition, security policy, and challenge rules. Preset chunking values are conveniences for callers generating the packaged fixtures; they do not override the runtime argument. These presets live in akita_params::MultiChunkProfileId (for example, MultiChunkProfileId::W2R3.cfg()), with packaged inventories selected by family_row! in akita-planner/src/generated_families.rs.

Packaged fixture paths are keyed by family name and contain one geometry per name. The remaining geometry-named config types identify these fixed fixtures; they are not required to use runtime geometry. Applications can use the same base config for multiple catalogs, assigning each its own path and supplying its expected geometry explicitly.

The fixture helpers empty_emit_spec and emit_spec_for_family take explicit chunking. Preplans are reused only for matching geometry. Precommitted producer profiles remain independently selected: a consumer's geometry does not change an already committed producer.

The planner validates geometry and searches for schedules. Catalog admission checks the expected policy digest and audits every row, including chunking at each fold. A valid chunk count and depth do not guarantee that a particular polynomial shape admits a schedule. The catalog retains the exact policy that passed validation, so grouped planning can reuse it without reconstructing geometry from a preset.

Chunking and the catalog are trusted preprocessing inputs. Proofs select an admitted row; they cannot change this policy or supply replacement schedules. One verifier binary and one Config type can use multiple independently owned catalogs with different chunking. No environment variable or process-global configuration is consulted by Akita verification.

Bounded committed sources

The fp128::DenseBounded preset is for dense polynomials whose centered coefficients fit within a declared signed width of 65 bits. This range is [-2^64, 2^64 - 1], so it contains every u64. The narrower declaration lets the artifact schedule use the actual source range instead of charging every coefficient for the full 128-bit field width. Commitment rejects a source that does not fit the declared interval.

This preset expects the fp128_dense_bounded family artifact. Applications load and approve those bytes through the same trusted parameter channel as their other preprocessing data.

External catalog rows serialize one expanded schedule. The root groups determine the committed profiles, which the validated catalog retains for lookup. Resolving a key, profile, or selection borrows the catalog's row.

SetupRequirements::from_catalog computes the matrix capacity and recursive prefix slots together, and records the capacity bound it was computed at. SetupRequirements::union combines requirements from several catalogs at the same bound. Setup construction reuses those requirements when loading, repairing, or generating a setup. Independently supported precommitted groups still contribute to matrix capacity when their larger grouped schedule exceeds the requested bounds.

Schedule and fold parameters

A FoldSchedule stores one root FoldParams, zero or more recursive FoldParams, and one TerminalFoldParams. Each nonterminal FoldParams points to one CommittedGroupParams. That value owns the fold's groups, the shared D matrix, payload mode, ring-relation mode, source encoding, and witness chunk layout.

The groups are stored in protocol order. An incoming setup prefix comes first, then ordinary precommitted groups, and the fold's own new group comes last. Each GroupOpenPhaseParams holds a frozen GroupCommitPhaseParams and the opening plan chosen by the consuming fold. A setup prefix is the group whose setup_natural_len is set. There is no second prefix identity or separate producer choice to keep in sync.

The fold owns one open_matrix for the complete D product. Each group owns its opening basis and digit depth through GroupOpeningPlan. The verifier checks this ownership, the group order, matrix dimensions, decomposition depths, and witness lengths before it uses the schedule.

Implementation map

• crates/akita-params/src/layout/params.rs defines CommittedGroupParams.
• crates/akita-params/src/schedule/profiles.rs defines GroupCommitPhaseParams.
• crates/akita-params/src/layout/params/precommitted.rs defines GroupOpenPhaseParams and GroupOpeningPlan.
• crates/akita-params/src/schedule.rs defines FoldParams, TerminalFoldParams, and FoldSchedule.
• crates/akita-schedules/src/resolve.rs validates artifact rows before the prover or verifier uses them.

The planner and proof size

Normal planner search is Cfg-free. The optional catalog-gen feature enables akita-config, so table-emission binaries can name concrete CommitmentConfig presets. The emitter writes fully expanded external family artifacts. Runtime proving and verification resolve rows from the explicitly supplied TrustedScheduleCatalog<Cfg> and never run planner search. Shared proof-size formulas remain verifier-reachable and reject malformed input with an error rather than panicking.

Implementation map

• crates/akita-planner/README.md for the current planner overview, search model, and artifact generation.
• crates/akita-planner/src/ owns search and emission. Runtime catalog expansion and audit live in crates/akita-schedules/src/.
• crates/akita-params/src/proof_size.rs and crates/akita-params/src/layout/proof_size.rs (nonterminal_level_layout, planned witness sizing).
• crates/akita-planner/src/generated_families.rs, crates/akita-planner/src/emit/, and crates/akita-schedules/src/artifact.rs.
• book/src/usage/profiling.md and .github/workflows/profile-bench.yml.

Multi-chunk fold prefixes

ChunkedWitnessCfg::num_activated_levels counts folds from the root at level 0. The scheduler applies num_chunks to those leading folds and uses one chunk at every later fold. MultiChunkProfileId provides W2, W4, and W8 profiles for R1, R2, and R3. For example, W4R3 keeps four response chunks at levels 0, 1, and 2, then switches to one chunk at level 3. The terminal step closes the remaining witness rather than adding another chunked fold.

The fp128 R3 companions ship separate external artifacts, including W2R3, W4R3, and W8R3 recursive setup companions. Regression tests check the exact three-fold prefix and single-chunk suffix. They also check that changing the third fold's chunk count without recomputing its geometry fails catalog admission.

Recursive setup catalogs

Ordinary configuration catalogs use direct setup evaluation. The supported RecursiveCommitmentConfig<Cfg> adapters select separate catalogs that may carry a committed setup prefix into the next fold. Keeping the catalogs separate prevents an ordinary verifier from accepting a recursive setup shape under a direct configuration.

The planner prices the Stage 3 proof and the later prefix opening as part of the complete suffix. Artifact rows record every selected prefix edge. Catalog admission checks those edges and never reruns the search. See Setup offloading for the selection rules, setup artifacts, and recursive claim flow.

Ring-relation cutover

Every nonterminal fold selects one RingRelationMode. QuotientLift adds explicit quotient witness spans and proves exact lifted polynomial identities. ReducedEvaluation proves the same native-ring equations after evaluation at the transcript challenge, using signed-wrap residue kernels instead of quotient witnesses. The choice is independent of raw versus compressed payload and of the L∞ versus L2 response-security route.

The currently admitted reduced mode is deliberately narrower than its algebraic definition. The first two folds and every multi-chunk fold require subring packing and quotient lift. At later single-chunk folds, the planner may choose one monotone reduced-evaluation suffix, but only for EvaluationTrace openings with direct setup contribution. Extension-field roots retain packing because their commitments bind canonical coefficients. A reduced fold cannot consume an incoming setup prefix, defer the A/B/D setup product to Stage 3, or switch back to quotient lifting later. These are product-scope admission rules, not claims that the excluded combinations are mathematically impossible. Runtime schedule validation checks them before proving or transcript replay.

The suffix search prices both realizations using their exact witness layouts, proof sizes, setup requirements, response models, and successor states. An external artifact row records the selected mode at every nonterminal level. The mode is part of the canonical plan descriptor and transcript preamble; it is not a proof-supplied negotiation field and there is no verifier fallback.

Guided grouped schedule adaptation

Applications sometimes select a schedule for one large final polynomial group before they know the exact small groups that will already be committed when the final group opens. akita_planner::find_adapted_schedule handles this offline case, usually without rerunning the exhaustive planner.

The application supplies a validated scalar ResolvedScheduleRow and a GroupedGenerationRequest containing exact frozen producer descriptors. The guided search retains the scalar row's structure: recursive depth, dimensions, block splits, slices, digit bases, opening choices, relation modes, witness chunking, terminal shape, and setup-prefix topology. It then rebuilds every value that depends on the combined groups, including D widths and ranks, witness lengths, relation rows, setup-prefix lengths, response bounds, grinding parameters, and proof accounting.

This guided search is a conditional search, not a second global optimizer. When the scalar structure cannot support the grouped request, adaptation falls back to the exhaustive offline find_schedule for the same key. It therefore fails only when the request is invalid or no schedule exists in the audited domain. The fallback costs one full search, and its row need not retain the scalar row's structure.

Both searches give every group of an interchangeable class (equal commit-phase profile and source contract) the same root opening. Many identical producers, such as the chunks of one large object, therefore cost one opening choice between them, and planning time grows only slowly with their number. Distinct classes multiply the opening choices; beyond 256 combinations the searches skip the affected root opening dimension instead of enumerating them.

An adapted row is not trusted merely because planning succeeded. The application merges its selected rows, validates them with ValidatedScheduleCatalog::try_new, binds the result as TrustedScheduleCatalog<Cfg>, and regenerates setup for that catalog. Runtime setup restoration, commitment, proving, proof decoding, and verification continue to resolve immutable catalog rows and never invoke the planner. Adaptation changes no proof field, transcript event, or .aks schema.

The normative constraints and failure behavior are recorded in Guided schedule adaptation.

Selective L2 candidates

The coefficient L∞ route remains available at every fold. A production preset may also enable the typed L2 response model. Every shipped fp32, fp64, and fp128 dense and one-hot family enables it. This includes each generated multi-chunk and recursive companion.

The planner always retains the universal L infinity candidate. When typed moments are available, it also evaluates the modeled L infinity depth. From level 3 onward, an enabled family evaluates the same canonical block split with an L2 A matrix for response bases 8 and above. The planner keeps an eligible L2 alternative only when it lowers the A rank. Basis 8 uses the same fused norm and range-image leaf as larger bases, with its class-indexed source prepared lazily because it has no product-stage prefix.

The planner estimates the squared norm of the actual recursive witness. It applies the following rules.

• A balanced signed-digit root uses the deterministic maximum squared digit energy for every coefficient, summed over the digit planes its declared source bound needs. A bounded source stops short of the field width, so its final plane is charged only the range the bound leaves rather than a full log_basis. A one-hot root uses the canonical coefficient table: each policy-owned source chunk contributes at most one coefficient of magnitude one, distinct chunks occupy distinct coefficients, and the peak coefficient square is one.
• The Z part uses the centered residues of a rounded normal variable. Its variance comes from the previous source energy and the challenge energy.
• The E and T parts, plus the R quotient part when present, use the centered field digit moment for every live scalar. A reduced-evaluation fold has no R quotient span. The final digit plane uses its actual remaining field width.
• Negative binary compression contributes one half unit of expected energy per coefficient.
• Extension tensor packing multiplies the logical energy by (2K - 1) / K, where K is the extension degree.

The planner rounds each source estimate upward while retaining seven leading bits. This adds less than 1/64 relative error and keeps the suffix search small. It then multiplies the source estimate by the challenge squared energy, a 1.03 model envelope, and a 40/39 response allowance. If the model envelope bounds the conditional mean, Markov's inequality gives at least 1/40 acceptance probability on each independent attempt. The protocol permits 4096 attempts, so the resulting exhaustion bound for one response is below 2^-149.

The 1.03 factor covers approximations in the normal, field digit, challenge covariance, and finite mixing models. It is an empirical completeness margin, not a soundness claim. Response-model diagnostics measure exact source and response energy in complete production proofs. The benchmark parser joins each measurement to the planned fold in the same run, rejects a successful run whose response exceeds its frozen cap, and records cap utilization and nonce attempts for every L2 fold. Historical measurements are evidence, not compiled unit test constants.

The field digit model is exact for uniform power of two residues, apart from the negligible pseudo-Mersenne boundary. Recursive setup values can retain correlation. This usually lowers their E, T, and R energy, so the model is conservative. Separate component validation found at most 2.24 percent unfavorable error.

The suffix comparison includes the norm proof, A payload, next witness, later folds, and terminal response. A smaller A rank can reduce the next witness enough to remove a fold, but the planner keeps L∞ when the extra norm proof costs more than the suffix saves.

This model affects completeness and schedule selection only. Once the planner selects a route, its concrete cap is frozen into the artifact schedule. The prover rejection samples against that cap and the verifier enforces the same value. The SIS calculation therefore still uses the public accepted cap and does not trust the statistical model.

If the typed model is disabled, the geometry is ineligible, no Euclidean SIS row exists, or the L2 route does not lower the A rank, the planner keeps the L infinity candidate. Runtime expansion never reruns the model. It only checks the frozen schedule.

Subring coefficient packing candidates

Within the two-level adaptive dimension prefix, coefficient-packing candidates search the A ring dimension and the challenge subring dimension together. For each pair the planner derives the packing factor from d_A = k h s. It rejects unsupported challenge families and invalid D divisibility before it constructs matrices.

The planner does not minimize s, h, or d_A directly. It keeps the same complete-schedule objective as other candidates. Depending on the catalog policy, the numeric prefix is either proof payload then total setup, or first direct-setup capacity then proof payload then total setup. Exact numeric ties prefer the smaller root output witness before the canonical descriptor breaks the final tie. This allows a larger A ring to win when its lower module rank reduces the complete setup or proof suffix.

The first two committed folds require coefficient packing and quotient lift, regardless of chunking. Every later multi-chunk fold has the same requirement. A three-level multi-chunk profile therefore uses packing at levels 0, 1, and 2, with the configured suffix ring dimensions at level 2. A mandatory packing state with no complete packing assignment is unsupported. Single-chunk nonterminal folds at level 2 or later may choose coefficient packing or evaluation trace where their source encoding supports it. The terminal uses evaluation trace. Its seed is priced separately, so a zero EOR packing candidate cannot be mistaken for a terminal opening.

A clear terminal L2 candidate has no recursive norm proof. The verifier checks the decoded response norm directly. The planner may use the certified energy to estimate a smaller Golomb payload for candidate comparison. The scheduled Golomb byte cap and the payload grind remain unchanged.

External schedule identity includes the cap policy and the separate L2 table digest. Artifact decoding audits the route, cap, proof shape, and A rank against that identity. A mismatch between the preset policy and supplied catalog is an error.

Source type is not part of runtime schedule identity. Dense and one-hot presets own different offline policies and external catalogs, but equivalent polynomial groups have the same runtime geometry. In particular, one-hot chunk size is an input to UnitOneHotFoldPolicy; it is not serialized in a commitment, proof, opening layout, or transcript.

Setup and commitment

Akita commits to a polynomial by arranging its table entries into ring elements, decomposing those elements into small digits, and applying public matrices. The result binds the table that the prover will later open. This chapter follows one polynomial through that computation before describing matrix reuse and the dense and one-hot implementations.

Setup

The public setup starts from a seed. Akita deterministically expands the seed into a vector of base-field elements, then interprets checked ranges of this vector as matrices of ring elements. There is no secret trapdoor to retain or discard. Both parties must use the same seed and matrix geometry.

The instance descriptor binds the setup seed identity and selected schedule before protocol replay. Expanded matrix files and prepared NTT views are caches derived from that public identity. Loading a cached coefficient matrix checks that it matches the seed.

Exact public-stream derivation

AkitaSetupSeed contains two values: a 32-byte public seed and a versioned derivation method. The current method is Shake256PagedV1. Versioning the method prevents a change to page size, domain separation, or field sampling from silently changing the setup identified by an existing seed.

The derivation splits the infinite field stream into pages of 4096 elements. For page index $i$, it initializes one SHAKE256 stream with the following length-prefixed fields, in order:

A length-prefixed field is encoded as the little-endian u64 length of its label, the label, the little-endian u64 length of its value, and the value. The explicit field modulus prevents equal seed bytes from identifying the same coefficient stream in two different fields.

The page then calls Field::random repeatedly on that SHAKE256 reader. The production fields use exact rejection sampling, so this is a uniform field stream rather than a fixed-width integer stream reduced modulo the field modulus. Pages may be generated in parallel; concatenating them by page index gives the same prefix as sequential generation.

One stream, several matrix views

Ring dimensions do not enter the derivation. Requests for the same number of field elements return the same prefix whenever the setup seed and field agree. The schedule determines how to read that prefix as a matrix.

A matrix view with r rows and c columns contains r × c ring elements. Each ring element holds D field coefficients, so the view reads r × c × D coefficients from the start of the stream. It groups every D coefficients into one ring element, then fills the matrix one row at a time.

The matrices $\mathbf{A}$, $\mathbf{B}$, and $\mathbf{D}$ each read from field index zero. Their prefixes overlap. The setup therefore needs enough storage for the largest matrix view required by the schedule, not the sum of all views.

This prefix sharing does not require the three roles to use the same ring dimension. For example, two views that each use 4096 field coefficients read the same random prefix even if one groups it into 64-coefficient rings and the other into 128-coefficient rings.

The witness column order is defined by the relation layout, not by setup generation. Akita keeps digits consecutive within each logical value. Exact A, B, and D column orders, including coefficient packing and sliced B layouts, are documented in Advanced relation layouts and Opening points and digit-innermost layout.

A recursive setup schedule may require commitments to selected power of two prefixes of this vector. Setup construction materializes exactly those prefix slots and checks that no required slot is missing. The prover later opens a slot when a fold defers its setup contribution. See Setup offloading for the complete lifecycle.

From a table to inner commitments

Begin with one polynomial, one chunk, and a common ring $R=F[X]/(X^D+1)$, where $F$ is the base field and $D$ is the ring dimension. An element of $R$ stores $D$ field coefficients. Ring multiplication wraps powers with the rule $X^D=-1$.

The polynomial's table supplies coefficients $f[\ell ,p,b]$. Here $\ell$ selects a ring coefficient, $p$ a position within a block, and $b$ a block. Pack one ring element per position:

$$F_{p,b}(X)=\sum _{\ell =0}^{D-1}f[\ell ,p,b]X^{\ell }.\text{\hspace{1em}(1)}$$

This is a representation of the table. It does not evaluate the application polynomial at $X$. Field to ring reduction explains how an evaluation of the table becomes a claim about these rings.

The inner commitment needs short inputs. Let $G_a^{\mathrm{in}}$ be the public recomposition weight for inner digit $a$. Decompose each position coefficientwise into digit rings $s_{b,p,a}$:

$$F_{p,b}=\sum _a{G}_a^{\mathrm{in}}{s}_{b,p,a}.\text{\hspace{1em}(2)}$$

The configured digit range bounds integer representatives of the coefficients. Small digits keep the subsequent commitment and folding relations within their certified norm bounds.

Collect the digits of block $b$ into ${\mathbf{s}}_b$, in position order with digit index innermost. For $L$ positions and $k_{\mathrm{in}}$ digits per position, the public inner matrix has shape $\mathbf{A}\in R^{n_A\times L{k}_{\mathrm{in}}}$. Its image is

$${\mathbf{t}}_b=\mathbf{A}{\mathbf{s}}_b\in R^{n_A}.\text{\hspace{1em}(3)}$$

For a small algebra example, take $R={\mathbb{F}}_{17}[X]/(X^2+1)$, one A row $(2+X,1-X)$, and a digit block ${\mathbf{s}}_b=(1,-1)$. Equation (3) gives $t_b=(2+X)-(1-X)=1+2X$. A second block $(0,1)$ gives $1-X$ using the same A row. These tiny parameters only illustrate the computation; production schedules choose security-sized matrices.

Every block now has a short vector of A outputs, but the number of such outputs still grows with the number of blocks. The outer matrix compresses that collection.

The outer commitment and public payload

Let $\rho$ index an A output row. Decompose each $t_{b,\rho }$ using outer weights $G_h^{\mathrm{out}}$, then concatenate the resulting digits in the outer matrix's column order:

$$t_{b,\rho }=\sum _h{G}_h^{\mathrm{out}}{\hat{t}}_{b,\rho ,h},\mathbf{u}=\mathbf{B}\hat{\mathbf{t}}.\text{\hspace{1em}(4)}$$

The hat distinguishes the short digit representation $\hat{\mathbf{t}}$ from the recomposed inner images ${\mathbf{t}}_b$. The two matrix applications in (3) and (4) form the two-tier Ajtai commitment.

A standalone commitment transmits a compressed payload $p_F$ for $\mathbf{u}$. Two rank-one maps form the compression chain. Each map decomposes its input coefficients into digits in $\{-1,0\}$, packs those digits into its native ring, and applies its public matrix. The digit weights are positive powers of two, interpreted in the base field. The first map produces 256 bytes and the second produces the 128-byte payload $p_F$. The complete source image must fit within 8 KiB.

The ring dimensions are profile-owned:

These smaller rings belong to compression. A, B, and D retain their own dimensions, each at least 64. Repacking coefficients between these rings is a specified coefficient map, so it must not be treated as an arbitrary ring homomorphism. The physical fold relations explain how the proof checks recomposition and every compression map.

Later recursive commitments can use a schedule-selected raw payload $\mathbf{u}$ instead. Standalone commitments and setup-prefix precommitments remain compressed. Recursion describes where the raw suffix is admitted.

What the prover retains

The default portable state is a PortableCommitmentHandle owned by the CPU backend. Protocol code can inspect its shape but cannot borrow its inner rows, compression witnesses, or quotients, or serialize the handle directly. Setup-prefix persistence uses the backend-owned SetupPrefixProverRegistry codec; the verifier registry contains only public commitments.

Commitment produces a public committed group and a prover-only hint. The group associates its payload with the frozen commitment profile. That profile fixes the geometry needed to interpret the commitment, including the inner and outer decompositions and B slicing.

The hint retains the semantic inner images ${\mathbf{t}}_b$ for each polynomial. For compressed commitments it also retains the packed compression digits and, when quotient lifting is used, the compression quotient images. It does not store a second copy of the public commitment or the complete outer digit table $\hat{\mathbf{t}}$. The CPU backend reconstructs those digits from the retained inner images.

The hint avoids repeating work during opening. It is not evidence that the verifier trusts, and it does not replace access to the committed polynomial. The verifier receives the public commitment and opening proof, then checks the corresponding relations.

Where the opening matrix enters

D depends on the opening geometry and is used when proving an evaluation. For the evaluation-trace opening method, the prover computes a ring partial $E_b$ for each block, decomposes these partials into $\hat{\mathbf{e}}$, and forms

$${\mathbf{v}}_D=\mathbf{D}\hat{\mathbf{e}}.\text{\hspace{1em}(5)}$$

The opening proof carries the compressed payload $p_H$, or the raw ${\mathbf{v}}_D$ in an admitted raw fold. Equation (5) binds the opening digits. A separate scalar relation recovers the requested evaluation from them, as derived in the Akita fold.

This is why a standalone commitment profile freezes A and B without requiring D. The query is not needed to commit. Once the query is known, the opening schedule selects D and the proof connects its opening digits to the same source used by A and B.

Dyadic B slicing

At absolute commitment levels zero and one, a compressed commitment may reuse one smaller physical B matrix across S consecutive block ranges, where S is 1, 2, 4, or 8. D is never sliced. Raw commitments and deeper levels require S = 1. Setup prefixes are separate frozen precommitments and may use slicing at any consumer level.

The block ranges are the proportional dyadic ranges

[floor(i * F / S), floor((i + 1) * F / S))

for F live blocks. Sliced commitments require S <= F, so every B slice is nonempty. Each slice is assembled in the ordinary B column order. Within each polynomial-major segment, a shorter slice receives its own zero suffix before the next polynomial segment begins. The prover then applies the same physical B matrix to every slice.

The resulting B images remain logically separate. If B has n_B rows, the relation has S * n_B B rows in slice-major order. Akita stacks the complete image and runs one canonical two-map F compression chain over it. The full stack, not one physical image, must fit the unchanged 8 KiB compression-source limit.

This separates physical and logical cost:

• SIS rank and setup storage use the smaller physical B width.
• Relation rows, compression work, and proof sizing use the complete logical stack.
• Direct and recursive setup contribution evaluation combine all logical slice weights before scanning the physical B matrix, so each physical entry is evaluated once.

The planner checks every admitted slice count. Proof-focused selection keeps the counts through complete schedule scoring. Setup-focused selection keeps the smallest count at the exact local setup floor. The selected count belongs to the commitment group and is frozen in standalone profiles, setup-prefix metadata, descriptors, and trusted external catalog identity.

Relevant implementation sources:

• crates/akita-params/src/commitment_slicing.rs
• crates/akita-cpu-backend/src/commitment/api.rs
• crates/akita-types/src/setup_contribution/plan/physical_b.rs

Public-stream and view sources:

• crates/akita-types/src/proof/setup.rs
• crates/akita-params/src/layout/flat_matrix.rs
• crates/akita-params/src/dispatch/mod.rs

Dense and one-hot backends

The dense backend decomposes the source coefficients and evaluates the inner matrix product with CRT and NTT arithmetic. The one-hot backend uses the source's sparse structure to visit only its nonzero monomial positions. A one-hot source has at most one nonzero entry, equal to one, in each consecutive chunk of onehot_k entries. An all-zero chunk is allowed.

Both backends use the same checked commitment geometry and sliced B executor. They differ only in how they produce the inner A image. Prepared setup and NTT caches remain keyed by the physical matrix, so increasing the logical slice count does not create extra stored B matrices.

Code map

• crates/akita-setup/src/lib.rs constructs setup and validates cached public matrices against their seed. Its tests cover seed and cache mismatches.
• crates/akita-cpu-backend/src/commitment/api.rs checks standalone commitment profiles, computes inner images, and executes sliced outer commitments.
• crates/akita-cpu-backend/src/commitment/portable.rs defines the retained prover state and tests its canonical serialization and shape checks.
• crates/akita-cpu-backend/src/opaque/recursive/commit.rs commits recursive witnesses, selects raw or compressed output, and prepares the A-only terminal handoff.

The production layout can use different native ring dimensions and several polynomials per group. Equations (1) through (5) give the common-ring, single-polynomial meaning; the checked layout determines the coefficient conversions and concatenation in those larger cases.

Transcript and instance binding

Akita replaces interactive verifier randomness with Fiat-Shamir challenges. Prover and verifier derive each challenge from the same public parameters and the same preceding messages. The transcript records that order.

For example, suppose two claimed values $v_0,v_1$ will be checked through $v_0+\gamma v_1$. Both values must be fixed before the transcript produces $\gamma$. If a prover could choose $v_0$ afterward, it could cancel a chosen error in $v_1$. This is why a transcript contract specifies both which bytes are absorbed and when each challenge is drawn.

The transcript layer

Production uses Spongefish's prover and verifier states. Its domain separator includes a backend-specific protocol tag, the caller's length-framed session bytes, and canonical instance bytes. The selected backend is BLAKE2b or Keccak; each has its own protocol tag.

Akita pins Spongefish v0.7.4. Its digest bridge encodes squeeze counters as fixed-width u64 values, so Blake2b transcript bytes do not depend on whether the implementation uses 32-bit or 64-bit pointers. Akita keeps a known-answer vector for this boundary.

Every logical message or challenge has a fixed public diagnostic context record. Proof values use prover emission and verifier receipt, derived or public values use public messages, and verifier challenges use verifier messages. Field atoms are canonical. The one variable-size terminal payload carries a checked length atom before its body.

Production absorbs and squeezes are positional. Context records and callsite labels are diagnostics and do not enter sponge bytes. The backend-specific protocol identifier, length-framed session, canonical instance descriptor, messages, and replay order do enter the cryptographic state. Renaming a diagnostic label therefore differs from changing any of those bound values.

Prover and verifier must execute the same sequence, including challenge lengths and canonical ordering within a batch. Equal proof objects alone do not establish that agreement.

Sparse fold challenges

A fold needs one sparse ring challenge for every (claim, live block) pair. Akita draws them in claim-major order. It performs only one live transcript squeeze per commitment group, while still giving each pair an independently forkable random-oracle coordinate.

The group root

Before the squeeze, the transcript absorbs the complete public draw context:

• group index, number of live blocks, and number of claims;
• total number of challenge coordinates;
• challenge ring dimension;
• counts of coefficients at magnitude 1 and magnitude 2;
• the shared fold-response grinding nonce;
• the coefficient-packing method domain and challenge-subring dimension, when coefficient packing is selected; and
• the operator-norm rejection policy, when the selected L2 route requires it.

The transcript then squeezes one 32-byte group root. Evaluation trace preserves its established domain encoding. Coefficient packing adds a distinct method domain so the same transcript state cannot reinterpret a draw under the two opening methods.

One indexed stream per coordinate

For coordinate index $i$, the sampler initializes a fresh SHAKE256 reader from

group_root || little_endian_u64(i).

Coordinate $i$ is claim * num_live_blocks + block. Expanding one coordinate does not mutate either the live transcript or another coordinate's reader. This gives the extraction argument the required fork: one challenge can change while every other challenge and the surrounding transcript remain fixed.

Expanding the whole challenge vector from one shared cursor would give a different oracle dependency. Each accepted nonce has one canonical unsigned LEB128 representation: those exact proof bytes are absorbed into the live transcript before the challenge context is derived. There is no second compact nonce representation or separate nonce absorption.

The indexed readers are an expansion of one transcript root, not additional Fiat--Shamir squeezes and not additional proof data.

Positions, magnitudes, and signs

Suppose the challenge ring has dimension $D$. A configured challenge has count_pm1 coefficients at magnitude 1 and count_pm2 coefficients at magnitude 2. The sampler first chooses their distinct positions by a partial Fisher--Yates shuffle of 0..D.

When the challenge is very sparse, the implementation stores only the swaps touched by that partial shuffle, using $O(w)$ scratch for Hamming weight $w$. Denser cases use a fixed stack permutation for better locality. These are two implementations of the same ordered partial shuffle and consume the same random stream.

Every bounded integer draw uses bitmask rejection rather than % D, so the position law has no modulo bias. After positions are fixed, fresh low bits choose independent signs. The first count_pm1 positions receive $\pm 1$; the remainder receive $\pm 2$.

Optional operator-norm rejection

An L2 fold may require a challenge whose negacyclic convolution operator norm is below a scheduled threshold. For supported D64 and D128 challenge families, the sampler tests each indexed candidate against the certified predicate and continues reading the same coordinate stream until one is accepted. The search is capped at 4096 candidates.

This rejection rule is part of the public challenge method. The policy and threshold are bound before the group root is squeezed, and the verifier repeats the same deterministic search. Coefficient-packing folds use the L-infinity security route and reject an operator-norm policy.

Implementation:

• crates/akita-challenges/src/fold_draw.rs binds the group context and owns the single transcript squeeze.
• crates/akita-challenges/src/sampler/xof.rs defines the indexed SHAKE256 stream and unbiased bounded draws.
• crates/akita-challenges/src/sampler/position_sample.rs implements the partial Fisher--Yates paths.
• crates/akita-challenges/src/sampler/signed_sparse.rs assigns magnitudes and signs.
• crates/akita-challenges/src/sampler/op_norm.rs checks the certified operator-norm predicate.

AkitaInstanceDescriptor

Before replay, both parties construct an AkitaInstanceDescriptor from the validated public configuration. The shared bind_transcript_instance_descriptor helper binds its canonical bytes through spongefish's DomainSeparator.instance(...).

The descriptor records the following identities:

The effective schedule includes the level geometry, payload modes, and each nonterminal RingRelationMode. Switching between quotient lifting and reduced evaluation changes the preamble before the ring-switch challenge $\alpha$. The verifier uses the selected mode and rejects a mismatch.

The descriptor fixes the interpretation of the call. Actual commitment payloads, opening-point coordinates, and claimed values are absorbed during the protocol. Binding only the call's shape would not bind those values.

For example, two calls with identical shapes but different opening values have the same shape metadata. Their transcripts diverge when the claimed values are absorbed. Two calls that interpret identical payload bytes under different schedules diverge at the descriptor.

Root and fold replay

At the root, the descriptor fixes the batch shape. Replay binds group commitments in canonical group order, each group's complete opening point, and the per-polynomial claimed values as public messages. The verifier checks commitment geometry before binding the payloads.

A nonterminal fold then follows these dependencies:

1. Prepare the opening claim. If evaluation trace over a proper extension requires extension-opening reduction, replay that reduction first.
2. Absorb the complete opening payload, either compressed $p_H$ or raw ${\mathbf{v}}_D$, then draw the application claim-batching coefficients.
3. Consume the fold-response nonce and draw the sparse fold challenges for each group.
4. Absorb the next-witness binding. It is a recursive commitment payload or, on the last edge, the terminal inner-image state.
5. Draw the ring-switch challenge $\alpha$, followed by the range and row points ${\tau }_0,{\tau }_1$.
6. Replay Stage 1 and Stage 2. Absorb each sumcheck round message before drawing its round challenge. Carry the resulting witness-opening claim to the successor.
7. If the schedule offloads setup, replay Stage 3 and carry its separate setup-prefix opening alongside the witness opening.

This order makes the next witness binding independent of the random points that check its relations. The witness itself can remain prover-only until the terminal. Recursion explains what each binding commits to, and the sumcheck stages derive the carried claims.

A recursive successor uses the commitment and opening claim supplied by the previous fold. If a setup prefix is present, its group precedes the witness group. Neither party may reorder groups based on their payload contents.

Extension-opening reduction and terminal replay

Extension-opening reduction has an earlier batching step of its own. The prover first binds the incoming claimed values and reduction partials. The transcript then produces the tensor-mixing challenge and the early coefficients that batch the reduction claims. Every reduction sumcheck message precedes its round challenge.

The reduction's final claims are absorbed before the fold's complete opening payload. Only after that payload is bound does the application batching in step 2 occur. These two batching steps have different inputs and different challenge positions; they cannot reuse a challenge merely because both form linear combinations. The reduction chapter gives the full sequence.

At the terminal, the verifier checks that the response's inner images match the predecessor's binding. After any required extension-opening reduction, it absorbs the ring opening partials, consumes the fold-response nonce, and draws the sparse challenges. It then absorbs the remaining response and performs the direct checks. There is no outgoing commitment or replay of Stages 1 through 3.

Grinding plan and inline nonces

Each proof has one public GrindingPlan, derived from the selected schedule, normalized opening layout, field tower, and policy. The plan fixes the order and bit width of every proof-of-work query and bounded fold-response search. Its digest is part of the descriptor.

Nonzero proof-of-work sites and every fold-response site carry an inline canonical unsigned LEB128 nonce at the exact protocol position where it is used. A decoder does not obtain a nonce count or policy from proof bytes. The plan cursor checks sites in order and must be exhausted when EOF is checked.

The planner accepts only complete schedules whose expanded grinding query count is less than u32::MAX. If the objective-best candidate exceeds that capacity, planning treats it as an infeasible path and continues among schedules admitted by the planner's existing bounded candidate-generation policies. UnsupportedSchedule means that no feasible schedule was found within this domain; it does not prove that no mathematically valid schedule exists among layouts discarded by those policies.

Proof-of-work and fold-response nonces use distinct message kinds and serve different purposes.

Protected challenge queries

Each field challenge site has a loss $L$. The security argument allows at most $L$ of the $|E|$ possible challenge values to be bad for the verifier, so one attempt at the challenge lands on a bad value with probability at most $L/|E|$. The next subsection shows where a loss comes from for one family of sites.

Grinding makes each attempt cost $2^g$ hash queries on average. The plan chooses the least nonnegative integer $g$ with $L{2}^{128}\le |E|2^g$, which keeps the chance per query at most $2^{-128}$. The calculation uses integers and the actual prime power, including the deficit below a power of two.

At a protected query with grinding target $g>0$, the prover searches a nonce whose accepted value must fit $g+7$ bits. Each attempt absorbs the canonical nonce, then produces a separate 32-byte predicate. Diagnostic metadata records the grinding site without changing the sponge. The predicate passes when its first $g$ low-order bits are zero.

The verifier repeats that predicate check. Only after it passes does replay draw the protocol challenge from the advanced transcript. The predicate is not reused as the challenge. A zero-bit target consumes no proof bits and leaves the transcript unchanged at that site.

The additional seven nonce bits provide room for honest search beyond the expected $2^g$ attempts. Storage is self-delimiting and canonical; the semantic width is still checked from the public plan. Schedule selection adds the per-message maxima, ceil(semantic_nonce_width / 7). This deterministic cost is not the realized LEB128 wire size. The verifier safety bound is derived separately from the complete grammar.

The loss of a claim-batching challenge

The problem. A fold often opens several polynomials at once. The prover states $N$ claimed values $v_1,\dots ,v_N$, one per polynomial, and the verifier checks them together instead of one at a time. It draws coefficients ${\eta }_1,\dots ,{\eta }_N$ from $E$, one fresh value per claim, and the rest of the fold proves the single combined claim ${\sum }_k{\eta }_k{v}_k$. The question is how many bad values this draw has, that is, what loss to price it at.

The tempting answer, $L=1$. Write $u_k$ for the true value of the $k$th polynomial and ${\delta }_k=v_k-u_k$ for the error in its claim. The combined claim is correct exactly when ${\sum }_k{\eta }_k{\delta }_k=0$. If some ${\delta }_k$ is nonzero and the errors are fixed before the coefficients are drawn, this is one nonzero linear equation in the ${\eta }_k$, and a random draw satisfies it with probability at most $1/|E|$. That suggests $L=1$.

Why the security argument cannot use it. Knowledge soundness is proved with an extractor: a procedure that reruns a prover that makes the verifier accept and recovers the committed polynomials from its answers. The true values $u_k$ are evaluations of those recovered polynomials, and the extractor only obtains them from the part of the proof that comes after this challenge. Commitment binding does not help. It says an efficient prover cannot produce two different openings of one commitment; it does not hand the argument a single opening, and hence fixed errors ${\delta }_k$, before the coefficients are drawn. So the argument must work from accepting runs alone.

What the extractor does. It reruns the prover from this challenge with $N+1$ coefficient vectors: a base vector $\eta$, and for each $k$ a vector ${\eta }^{(k)}$ that differs from $\eta$ only in coordinate $k$. The claims $v_k$ were sent before the challenge, so they are the same in every run. Every run also opens the same committed polynomials, or the extractor has found a commitment collision, so every run has the same errors ${\delta }_k$. The base run gives ${\sum }_j{\eta }_j{\delta }_j=0$, and run $k$ gives the same sum with ${\eta }_k$ replaced by ${\eta }_k^{(k)}$. Subtracting the two leaves $({\eta }_k^{(k)}-{\eta }_k){\delta }_k=0$, so ${\delta }_k=0$.

For example, with $N=2$ the extractor uses three runs, with coefficient vectors $(a,b)$, $(a^{\prime },b)$ and $(a,b^{\prime })$ where $a^{\prime }\ne a$ and $b^{\prime }\ne b$. The first two runs give $(a-a^{\prime }){\delta }_1=0$, and the first and third give $(b-b^{\prime }){\delta }_2=0$. Both claims are therefore correct.

The resulting loss. The extractor fails only if, for some coordinate $k$, the prover succeeds with one value of ${\eta }_k$ and with no other value, the other coordinates held fixed. That costs at most one bad value per coordinate, $N$ in all, so the site has loss $L=N$. Other sites in Akita batch claims with powers $1,\gamma ,\dots ,{\gamma }^{N-1}$ of one scalar. That check is a nonzero polynomial of degree at most $N-1$ in $\gamma$, so those sites have loss $N-1$.

In the production field, $|E|=(2^{64}-59{)}^2$ is slightly below $2^{128}$. One polynomial draws no coefficients and has no site. Nine polynomials give $L=9$, and $9\cdot 2^{128}/|E|$ lies between 8 and 16, so the site needs $g=4$, where $L=1$ would give $g=1$.

Two sites have this form: the evaluation batch of each fold, and the batch of reduction claims in extension-opening reduction. independent_batch_loss_factor in akita-types prices both. The grinding nonce specification records the contract.

Fold-response search

A fold-response entry carries a canonical unsigned LEB128 nonce whose value must fit the 12-bit search domain, shared by all commitment groups in that fold. The prover previews candidates until the resulting response satisfies the scheduled representation and norm bounds. It commits the winning nonce to replay, or returns an error if the bounded search is exhausted.

The verifier reconstructs the challenges for that nonce and enforces the response bounds. This is separate from the proof-of-work predicate. The PCS binding chapter explains why adversarial nonce trials must be included in random-oracle query accounting.

Integration and regression checks

AKITA_INSTANCE_DESCRIPTOR_VERSION is currently 5. Validation rejects other versions. Pin an exact Akita revision and rerun prove and verify integration tests when upgrading; the repository does not promise compatibility across revisions.

Binding an instance initializes the transcript state for that instance. Application code should use the intended session label and let the scheme's shared binding path construct the descriptor before replay. Prepending application messages to a transcript that will then be rebound does not preserve those messages in the new state.

The current descriptor's SetupSection.protocol_features.zk is false. Transcript binding does not add hiding or zero knowledge.

The protocol uses a descriptor-bound positional grammar. Context records capture semantic sites and widths for logging diagnostics without adding production hashing work. Tests cover prover/verifier vectors, tampering, truncation, statement/session binding, and EOF; they do not freeze one proof-byte digest for all future schedules. The grinding grammar and nonce encoding are documented in specs/transcript-grinding.md and specs/grinding-nonce-encoding.md.

Code map

• crates/akita-config/src/transcript_binding.rs constructs and binds the shared descriptor and grinding plan.
• crates/akita-types/src/instance_descriptor/mod.rs owns descriptor fields, canonical serialization, and version validation.
• crates/akita-transcript/src/proof_stream.rs owns state construction, context framing, canonical atom codecs, bounded bytes, and EOF-compatible proof transport.
• crates/akita-params/src/transcript_grinding/plan.rs defines the ordered plan; crates/akita-types/src/transcript_grinding/replay.rs couples nonce transport, predicate checks, challenges, and plan progress.
• crates/akita-challenges/src/sampler/xof.rs derives the indexed sparse challenge streams.
• crates/akita-verifier/src/fold/mod.rs and crates/akita-verifier/src/fold/terminal.rs enforce fold and terminal replay order.
• crates/akita-pcs/tests/transcript_hardening.rs tests ordering and prover/verifier agreement; crates/akita-pcs/tests/fold_linf.rs covers fold-response nonce behavior and proof roundtrips.

The detailed grinding contract is recorded in the transcript grinding specification.

The proving protocol

One Akita fold reduces committed opening claims and the fold relation to an opening claim about a new recursive digit witness. It proves that the new witness comes from the old committed data, satisfies the fold relation, uses bounded digits, and is ready to be opened by the next level.

This compresses the claim carried forward; it does not guarantee that the full next-level witness is smaller than the input witness. The folded response is only one part of that witness. Opening and inner-commitment digits, auxiliary digits, and the scheduled physical representation also contribute to its size. In particular, a root fold may be non-contractive: its outgoing witness may be as large as or larger than the application source.

The root and recursive nonterminal levels use the same fold engine. They differ in the source they consume and the schedule parameters assigned to them. The terminal level is different: it checks the final clear witness directly and does not create another recursive witness.

This chapter is the map for the proving section. Its child chapters derive the relations, physical layouts, opening methods, and sum-checks in detail.

Inputs and output of one fold

A nonterminal fold starts with four kinds of information.

The fold streams:

• one schedule-shaped sequence of commitment payloads and sum-check messages;
• one recursive digit witness for the successor;
• one opening claim that binds that witness at the final Stage 2 challenge; and
• when setup offloading is selected, a separate opening claim for one prepared setup prefix.

The witness claim and setup-prefix claim remain distinct. A successor may open both in one grouped fold, but they keep separate commitments, points, values, and source meanings.

One nonterminal fold in order

The prover follows this sequence.

1. Validate the scheduled geometry

The level reads its group parameters from the resolved schedule. It checks matrix roles, ring dimensions, block counts, digit depths, opening methods, payload modes, and any incoming setup prefix before building large tables.

The proof does not get to override these values. They determine the expected message widths and transcript structure on both prover and verifier paths.

2. Prepare each opening

Each commitment group has one complete opening point shared by the polynomial claims in that group. The scheduled opening method determines how the prover turns those claims into fold inputs.

• Subring coefficient packing contracts selected coefficient coordinates and opens the extension-valued claim directly in a smaller challenge ring.
• Evaluation trace expresses the claim through a field-valued trace. When the opening point lives in a proper extension field, extension-opening reduction first converts it to the base-field relation consumed by the fold.

The method belongs to the level schedule. A proof carries extension-opening data only when evaluation trace and a proper extension field require it.

See Fold path and field geometry, Field-to-ring evaluation reduction, and Extension-opening reduction.

3. Fold the source into a response

Transcript challenges combine the source blocks into a shorter response $\mathbf{z}$. The opening point also produces partial evaluations that will bind the claimed value to those same blocks.

The response, opening values, and inner commitment values are decomposed into small signed digits. Akita stores those digits in one canonical digit-innermost witness layout. Every later range check, matrix evaluation, recursive handoff, and verifier calculation uses that layout.

See Opening points and digit-innermost layout.

4. Build the semantic fold relations

The core fold statement has four ring-valued relation families:

1. the folded response agrees with the source blocks and fold challenges;
2. the inner A matrix agrees with the source digits;
3. the outer B matrix agrees with the public commitment; and
4. the opening D matrix agrees with the opening digits.

The field-valued opening claim is kept conceptually separate, then fused into Stage 2 beside these ring rows.

The basic derivation is in Semantic relations in an Akita fold. Advanced relation layouts extends the same four families to multiple groups, chunks, and role-specific ring dimensions.

5. Choose the physical realization

The semantic B and D commitment values can appear directly as raw payloads, or they can remain hidden behind smaller compressed payloads. Compressed mode adds the two-map commitment chains, their digit witnesses, and their physical rows. It does not change what the four semantic relations mean.

The schedule also selects how to check these ring equations: quotient lifting adds private quotient digits, while reduced evaluation includes ring reduction in public coefficient weights. Each row uses its native ring dimension. Checking ring relations over a field derives both methods and their common handoff to Stage 2.

See Raw and compressed realizations of an Akita fold.

6. Form and commit the successor witness

The relation witness contains the response digits, opening digits, inner commitment digits, and any compression witness required by the payload mode. It also contains quotient digits when the relation mode is QuotientLift. Ring switching lays these values out as the next field-valued witness. The prover commits to that witness with the parameters of the successor level.

At the root, subring coefficient packing also controls how sparse challenge coefficients enter the A ring and how shortened partial evaluations enter the relation. See Root fold and ring switching.

7. Run the sum-check cascade

Every nonterminal fold runs two required stages and one optional stage.

Stage 3 appears only on a scheduled offloaded edge. In direct mode, the verifier evaluates the setup contribution itself and no Stage 3 proof is present.

See Sum-check stages and Setup offloading.

8. Hand the claims to the successor

The Stage 2 challenge and expected witness evaluation become the statement for the next fold. If Stage 3 ran, its setup-prefix point and evaluation enter as a second commitment group. The transcript binds this exact handoff before the successor samples dependent challenges.

The process repeats until the schedule reaches its terminal level.

Root, recursive, and terminal responsibilities

The terminal has no outer B commitment, no opening D commitment, and no sum-check cascade. Its predecessor already binds the terminal witness through the opening claim that enters the final check.

Recursion and proof shape explains how these records are encoded and connected.

Reading the child chapters

The most useful order depends on what you need.

First protocol reading

1. Field-to-ring evaluation reduction
2. Semantic relations in an Akita fold
3. Raw and compressed realizations
4. Checking ring relations over a field
5. Opening points and digit-innermost layout
6. Fold path and field geometry
7. Sum-check stages

Read Root fold and ring switching when you want the complete coefficient-packing derivation. Read Extension-opening reduction for the evaluation-trace path over a proper extension field.

Multi-group or distributed implementation

Advanced relation layouts adds commitment groups, chunks, and different role dimensions to the basic fold. The distributed prover then shows which source, commitment, and sum-check work can stay local to separate machines.

Prover and verifier map

The exact source layout can evolve, so begin with the public core entry points and follow the shared types they call. The Book's Verification child pages provide a value-by-value map of the current verifier calculations.

Review checklist for a fold change

Before accepting a change to this path, check all of the following:

1. The generated schedule and proof shape still describe every message.
2. Prover and verifier absorb public data and proof messages in the same order.
3. Source, witness, relation, and challenge indexes use the same physical layout.
4. Every relation row is interpreted in its scheduled native ring before lifting or batching.
5. Stage 1 output and the incoming opening claim are both bound inside Stage 2.
6. Stage 3 is present exactly on offloaded setup edges.
7. The successor receives the exact witness and setup claims produced by its predecessor.
8. Malformed sizes, encodings, schedules, and terminal values return an error on the verifier path rather than panicking.

A fold is not correct merely because its prover can produce a proof that its verifier accepts. Its schedule, transcript, relation layout, final oracle checks, and independent rejection tests must all describe the same statement.

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

$$f:\{0,1{\}}^n\to F,r\in F^n,\tilde{f}(r)=v.$$

Here both the polynomial table and the opening point are defined over the base field $F$. Akita commits the table through the cyclotomic ring

$$R=F[X]/(X^D+1).$$

The schedule chooses one of two opening methods. EvaluationTrace keeps one full element $E_b(X)\in R$ per live block and finishes the inner contraction with TraceOpen. SubringCoefficientPacking contracts part of the inner axis earlier and keeps a shorter polynomial $e_b(U)$ over the opening field. In both cases the result is a field-valued linear relation on the committed opening digits:

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 $D=2^d$ and a power-of-two number of positions per block. Re-index the polynomial table as

$$f[\ell ,p,b],$$

where:

• $\ell \in [D]$ is an inner index that will become a ring coefficient;
• $p$ is a position inside a block; and
• $b$ is a block index.

Missing entries in a partial final block are public zeros.

Split the opening point in the same order:

$$r=(r_{\mathrm{in}},r_{\mathrm{pos}},r_{\mathrm{blk}}).$$

Write the corresponding interpolation weights as

$$I_{\ell },Q_p,B_b.$$

For a multilinear opening in the Lagrange basis, these are equality weights:

$$I_{\ell }=\mathrm{eq}(r_{\mathrm{in}},\ell ),Q_p=\mathrm{eq}(r_{\mathrm{pos}},p),B_b=\mathrm{eq}(r_{\mathrm{blk}},b).$$

The evaluation claim is therefore

$$\tilde{f}(r)=\sum _{\ell ,p,b}{I}_{\ell }{Q}_p{B}_{b}f[\ell ,p,b].\text{\hspace{1em}(1)}$$

Akita evaluates the three axes in the order

$$\text{position}⟶\text{block}⟶\text{inner}.$$

Reduce to a ring-valued evaluation

Pack the inner axis into ring coefficients

For each position $p$ and block $b$, pack the inner slice into a ring:

$$F_{p,b}(X)=\sum _{\ell =0}^{D-1}f[\ell ,p,b]X^{\ell }\in R.\text{\hspace{1em}(2)}$$

This is only a change of representation. The table entry $f[\ell ,p,b]$ becomes the coefficient of $X^{\ell }$.

Equivalently, the values $F_{p,b}$ form a ring-valued multilinear table

$$f_R:\{0,1{\}}^{n-d}\to R,f_R[p,b]:=F_{p,b}.$$

This is the same underlying table under a lossless coefficient packing, not a new witness. The ring polynomial has $d={\log }_{2}D$ fewer variables and is opened at

$$r_R=(r_{\mathrm{pos}},r_{\mathrm{blk}}),$$

whose base-field coordinates act as constant elements of $R$.

Evaluate the ring polynomial

First evaluate the position coordinate independently inside every block:

$$E_b(X)=\sum _p{Q}_p{F}_{p,b}(X).\text{\hspace{1em}(3)}$$

The coefficient of $X^{\ell }$ in $E_b$ is

$$[E_b{]}_{\ell }=\sum _p{Q}_{p}f[\ell ,p,b].$$

Next evaluate the block coordinate:

$$Y(X)=\sum _b{B}_b{E}_b(X).\text{\hspace{1em}(4)}$$

Thus Equation (4) is the ring-based evaluation claim

$$\boxed{{\tilde{f}}_R(r_R)=Y.}$$

Now

$$[Y{]}_{\ell }=\sum _{p,b}{Q}_p{B}_{b}f[\ell ,p,b].\text{\hspace{1em}(5)}$$

Thus $Y$ contains the polynomial after evaluating the position and block parts of $r$. Only the inner coordinate remains.

Pack the inner opening weights

Pack the remaining weights into a second ring:

$$P(X)=\sum _{\ell =0}^{D-1}{I}_{\ell }{X}^{\ell }.\text{\hspace{1em}(6)}$$

The two rings have different sources:

Using Equation (5), the original evaluation can already be written as

$$\tilde{f}(r)=\sum _{\ell =0}^{D-1}{I}_{\ell }[Y{]}_{\ell }.\text{\hspace{1em}(7)}$$

Recover the evaluation with TraceOpen

Let ${\sigma }_{-1}$ be the ring automorphism

$${\sigma }_{-1}(X)=X^{-1}.$$

For any $Z\in R$, define

$$\boxed{{\mathrm{TraceOpen}}_P(Z):={\left[Z(X){\sigma }_{-1}(P(X))\right]}_0,}\text{\hspace{1em}(8)}$$

where $[\cdot {]}_0$ denotes the constant coefficient in $F[X]/(X^D+1)$.

If

$$Z(X)=\sum _{\ell }[Z{]}_{\ell }{X}^{\ell },$$

then the matching terms in $Z{\sigma }_{-1}(P)$ are

$$[Z{]}_{\ell }{X}^{\ell }\cdot I_{\ell }{X}^{-\ell }=[Z{]}_{\ell }{I}_{\ell }.$$

They contribute to the constant coefficient, giving

$${\mathrm{TraceOpen}}_P(Z)=\sum _{\ell =0}^{D-1}[Z{]}_{\ell }{I}_{\ell }.\text{\hspace{1em}(9)}$$

Applying this definition to $Y$ and using Equation (7),

$${\mathrm{TraceOpen}}_P(Y)=\sum _{\ell }[Y{]}_{\ell }{I}_{\ell }=\tilde{f}(r).\text{\hspace{1em}(10)}$$

Therefore:

$$\boxed{\tilde{f}(r)=v⟺{\mathrm{TraceOpen}}_P(Y)=v.}\text{\hspace{1em}(11)}$$

TraceOpen is a coefficient pairing. It is not the univariate evaluation $Y(\alpha )$ used to reduce ring-valued relations to the field.

Eliminate the intermediate ring evaluation $Y$

Hachi: expose $Y$

The baseline Hachi protocol exposes $Y$ and checks two statements:

$$Y=\sum _b{B}_b{E}_b,\text{\hspace{1em}(12)}$$

and

$${\mathrm{TraceOpen}}_P(Y)=v.\text{\hspace{1em}(13)}$$

The first statement proves that $Y$ is the correct evaluation of the ring-valued polynomial. In this fold, each $E_b(X)$ is digit-decomposed into the committed partial-evaluation witness:

$$E_b(X)=\sum _h{G}_h{\hat{e}}_{b,h}(X),\text{\hspace{1em}(14)}$$

where ${\hat{e}}_{b,h}$ are the digit rings and $G_h$ are public gadget weights. Substituting this decomposition into Equation (12) gives

$$\boxed{Y(X)=\sum _{b,h}{B}_b{G}_h{\hat{e}}_{b,h}(X).}\text{\hspace{1em}(15)}$$

Equation (15) is a relation over the ring that enforces consistency between the ring element $Y$ and the witness polynomials ${\hat{e}}_{b,h}(X)$. Hachi sends $Y$ 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 $Y$ is already determined linearly by the committed partial-evaluation witness and that ${\mathrm{TraceOpen}}_P$ is itself a linear map. Sending $Y$ 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):

$$\begin{array}{rl}v& ={\mathrm{TraceOpen}}_P(Y)\\ & =\sum _{b,h}{B}_b{G}_h{\mathrm{TraceOpen}}_P({\hat{e}}_{b,h}).\end{array}\text{\hspace{1em}(16)}$$

Write each digit ring as

$${\hat{e}}_{b,h}(X)=\sum _{\ell =0}^{D-1}{\hat{e}}_{b,h,\ell }{X}^{\ell }$$

and define the public inner trace weight

$$J_{\ell }:={\mathrm{TraceOpen}}_P(X^{\ell }).\text{\hspace{1em}(17)}$$

By linearity,

$${\mathrm{TraceOpen}}_P({\hat{e}}_{b,h})=\sum _{\ell }{\hat{e}}_{b,h,\ell }{J}_{\ell }.$$

Equation (16) becomes the direct evaluation-consistency relation

$$\boxed{v=\sum _{b,h,\ell }{\hat{e}}_{b,h,\ell }{B}_b{G}_h{J}_{\ell }.}\text{\hspace{1em}(18)}$$

In the base-field setting, Equation (9) gives

$$J_{\ell }={\mathrm{TraceOpen}}_P(X^{\ell })=I_{\ell }.\text{\hspace{1em}(19)}$$

Thus every factor in Equation (18) has a simple role:

• $G_h$ recomposes the digit planes;
• $B_b$ evaluates across blocks; and
• $J_{\ell }=I_{\ell }$ evaluates inside the packed ring.

This row acts on the committed partial-evaluation digits $\hat{e}$. 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 $w$. Flatten the indices $(b,h,\ell )$ into a Boolean address $x$, and define the public weight function

$$T(x)=\{\begin{array}{ll}{B}_b{G}_h{J}_{\ell },& \text{if }x\text{ addresses the coefficient }{\hat{e}}_{b,h,\ell },\\ 0,& \text{if }x\text{ lies outside the }\hat{e}\text{ segment.}\end{array}\text{\hspace{1em}(20)}$$

Then Equation (18) is

$$\boxed{v=\sum _{x\in \{0,1{\}}^{\mu }}w(x)T(x).}\text{\hspace{1em}(21)}$$

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 $\alpha$ 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 $E_b(X)$ retains all $D$ 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 $E$ containing $F$; the interpolation weights $I$, $Q$, and $B$ are then $E$-valued. The case $E=F$ is included. Let

$$k=[E:F].$$

Choose a retained-axis dimension $s$—later also the challenge-subring dimension—and write

$$D=k\eta s.\text{\hspace{1em}(22)}$$

Here $\eta$ is the packing factor. The implementation and specification call this value $h$; this page uses $\eta$ 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

$$\ell =u+k\eta j,u\in [k\eta ],j\in [s].\text{\hspace{1em}(23)}$$

Split the inner opening point in the same order:

$$r_{\mathrm{in}}=(r_{\mathrm{pack}},r_{\mathrm{tail}}).$$

The tensor-product interpolation weight therefore factors as

$$I_{u+k\eta j}=I_u^{\mathrm{pack}}{I}_j^{\mathrm{tail}}.\text{\hspace{1em}(24)}$$

The index $u$ is contracted now; $j$ remains explicit. It helps to see this as a two-dimensional coefficient table rather than one flat list. For a fixed block $b$, first apply the position weights and write

$${\varphi }_{b,j,u}:=\sum _p{Q}_{p}f[u+k\eta j,p,b]\in E.$$

The rows are indexed by the coefficient $j$ that will remain in the packed partial. The columns are indexed by $u$, which is consumed now:

The table is not a new witness. It is only a view of the position-folded source coefficients. Contracting one row gives

$$e_{b,j}=\sum _u{I}_u^{\mathrm{pack}}{\varphi }_{b,j,u}=\sum _{p,u}{Q}_p{I}_u^{\mathrm{pack}}f[u+k\eta j,p,b]\in E.\text{\hspace{1em}(25)}$$

For example, take $D=8$, $k=2$, $\eta =2$, and $s=2$. Then $k\eta =4$, 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 $E$. The packed partial therefore contains two elements of $E$, or four base-field coordinates, instead of all eight source coefficients.

Substituting Equations (24) and (25) into the original multilinear evaluation gives

$$\begin{array}{rl}v& =\sum _{u,j,p,b}{I}_u^{\mathrm{pack}}{I}_j^{\mathrm{tail}}{Q}_p{B}_{b}f[u+k\eta j,p,b]\\ & =\sum _{b,j}{B}_b{I}_j^{\mathrm{tail}}{e}_{b,j}.\end{array}\text{\hspace{1em}(26)}$$

Thus the early contraction loses no part of the claimed evaluation. It only splits the old inner contraction into two stages: $u$ is consumed while the partial is formed, and $j$ is consumed in the final scalar relation.

Package the retained coefficients as

$$e_b(U)=\sum _{j=0}^{s-1}{e}_{b,j}{U}^j\in C:=E[U]/(U^s+1).\text{\hspace{1em}(27)}$$

The ring $C$ has $s$ coefficients in $E$. Fix the canonical $F$-basis ${\beta }_0,\dots ,{\beta }_{k-1}$ of $E$ and write

$$e_{b,j}=\sum _{t=0}^{k-1}{\beta }_t{e}_{b,t,j},e_{b,t,j}\in F.\text{\hspace{1em}(28)}$$

Consequently one packed partial has $ks=D/\eta$ base-field coordinates, rather than the $D$ coordinates of $E_b(X)$. The basis elements ${\beta }_t$ 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 $d$ for the opening-digit index:

$$e_{b,t,j}=\sum _d{G}_d^{\mathrm{open}}{\hat{e}}_{b,d,t,j}.\text{\hspace{1em}(29)}$$

Substituting Equations (28) and (29) into Equation (26) gives the direct packed opening relation

$$\boxed{v=\sum _b{B}_b\sum _j{I}_j^{\mathrm{tail}}\sum _t{\beta }_t\sum _d{G}_d^{\mathrm{open}}{\hat{e}}_{b,d,t,j}.}\text{\hspace{1em}(30)}$$

Read Equation (30) from the inside out. The opening gadget weights rebuild each base-field coordinate $e_{b,t,j}$ from its digits. The basis elements ${\beta }_t$ rebuild the extension-field coefficient $e_{b,j}$. The tail weights consume the retained $j$ rows, and the block weights combine the live blocks. The result is the original scalar opening $v$.

This is an $E$-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 $E_b$ or $e_b$ 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 $\mathbf{z}$. The two method-dependent shapes are

$$\text{EvaluationTrace:}\sum _b{c}_b{E}_b=\mathrm{Eval}(\mathbf{z}),$$

and

$$\text{SubringCoefficientPacking:}\sum _b{c}_b{e}_b=L(\mathbf{z}).$$

Semantic relations in an Akita fold derives both relations. In particular, it explains why the packing challenges must act only on the retained $j$ 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:

1. Prepare the opening weights. prepare_opening_point constructs $Q_p$, $B_b$, and $P$.
2. Evaluate the ring polynomial. evaluate_claims_at_prepared_point returns the position-folded rings $E_b$ and the temporary ring $Y$.
3. Recover the scalar evaluation. scalar_opening_from_folded_ring computes ${\mathrm{TraceOpen}}_P(Y)$.
4. Prepare the trace factors. prepare_evaluation_trace_group_parameters prepares the block point underlying $B_b$, the gadget weights $G_h$, and the inner trace weights $J_{\ell }$.
5. Construct the trace weights. build_evaluation_trace_weights combines those factors with the claim coefficients and physical $\hat{e}$ locations to construct $T(x)$.
6. Fuse the Stage-2 relation. accumulate_fused_relation_linear_signed adds 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 $P$, $Q$, and $B$ 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:

The temporary ring $Y$ is used only to compute $v_{\mathrm{tr}}$; it is not stored in PreparedFold or sent to the verifier. Stage 2 instead proves

$$v_{\mathrm{tr}}=\sum _{x}w(x)T(x)$$

directly from the committed digit witness.

Subring coefficient packing

The implementation follows the same derivation in three stages:

1. Prepare the point. PreparedSubringCoefficientPackingPoint checks $D=k\eta s$ and prepares the packing, tail, position, and block weights.
2. Pack and bind the partials. The prover contracts the $p$ and $u$ axes to obtain the coordinates $e_{b,t,j}$ 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.
3. Fold and verify. fold_coefficient_packing_group folds the packed partials and produces $Q_{\mathrm{pack}}$. Stage 2 then checks both the packing relation and the direct scalar opening, using ${\beta }_t{I}_j^{\mathrm{tail}}$ 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 ${\log }_2[\mathbb{E}:\mathbb{F}]$ 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 $[\mathbb{E}:\mathbb{F}]=1$ 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.

Semantic relations in an Akita fold

This page derives the semantic relations proved by one non-terminal Akita fold. The central question is the second correctness obligation from the previous page: are the method-selected partial evaluations consistent with the same incoming polynomial that is being folded?

The presentation starts with one polynomial group and one opening claim. The commitment relations use the ordinary source ring

$$R=F[X]/(X^D+1).$$

The opening-consistency relation has two method-dependent geometries:

• EvaluationTrace keeps a full ring partial and proves the relation in $R$.
• SubringCoefficientPacking keeps $s$ extension-field coefficients, proves the corresponding relation in the challenge subring, and embeds the same sparse challenge into $R$ for the source fold.

The other three semantic roles—inner-commitment, outer-commitment, and opening-commitment consistency—are unchanged by that choice.

The current implementation also supports more elaborate physical layouts. These include commitment groups, witness chunks, and different ordinary $\mathbf{A}$, $\mathbf{B}$, and $\mathbf{D}$ ring dimensions. These extensions do not change the four core relations developed below. This page establishes only the basic case; advanced layouts are outside its scope. The advanced relation layouts page develops the multi-group case. The raw and compressed realizations use the same semantic relations; the compression realization introduces its own smaller ring dimensions.

The four families below are the semantic source relations. The current implementation realizes the $\mathbf{B}$ and $\mathbf{D}$ commitment relations either by transmitting their semantic commitments as raw payloads or by binding those commitments to smaller terminal payloads through compression relations. This choice changes their physical realization, not the four semantic constraints derived here.

The goal of the fold is to reduce the claims about the current polynomial blocks to an opening claim about a new digit witness. This is a reduction of the statement carried forward, not a guarantee that the complete next-level witness is smaller. The fold proves that the new witness is consistent with:

1. the opening data computed from the old polynomial;
2. the inner and outer commitments; and
3. the random fold of the old polynomial blocks.

These statements form the semantic core of the physical ring relation. The scalar evaluation claim from Field-to-ring evaluation reduction is a separate field-valued relation. Each opening method supplies its own public linear map from opening digits to that scalar. This page instead proves the source-consistency relation that justifies those digits. The scalar row and physical rows are fused later.

Contents

• Inputs and objects derived in the fold
  • The committed polynomial and opening query
  • Balanced digit representations
  • Polynomial blocks and commitment hint
  • Partial evaluations and opening digits
  • The folded response and its digitization
• The four semantic relation families
  • Fold-evaluation consistency
  • Inner-commitment consistency
  • Outer-commitment consistency
  • Opening-commitment consistency