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.