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.

Keyboard shortcuts

Akita Book