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.