The full sumcheck proof includes the entire HashPC opening (the witness truth table) and is ~240 KiB. The slim proof strips this opening, keeping only the sumcheck protocol data, yielding a ~0.4–2.5 KiB on-chain payload (depending on $k = \log_2 n_{constraints}$) that is independent of the commitment scheme and its security parameter.

Do we lose security? The slim proof preserves knowledge soundness in the batch-proving model where the prover is trusted during folding. The level-1 verifier (verify_slim_level1/verify_full) closes two of the earlier gaps: it asserts the final residual vanishes (no more all-zeros free-E transcript), and it verifies the circuit-backed PCS openings, binding the final instance to a committed short witness. The remaining folding gap is closed at the commitment level by fold re-verification (FV): with a fold log carrying the pre-fold committed instances and cross-term commitments com(T), the verifier recomputes the per-step Fiat-Shamir challenges and re-checks the homomorphic fold relation Ē' = Ē_acc + r·Ē_step + r·com(T) (+ x', u', W̄') for every fold step from committed data, binding the chain to the bundle's final instance and transcript. FV does not re-open every per-step witness to check each com(T) against the R1CS cross-term relation — that would be full recursive verification. Acceptance therefore attests honest pipeline execution plus a commitment-level-checked fold chain; under a fully untrusted prover the per-step witness re-opening remains the residual (small) assumption.

Honest sizing. The headline ~0.4–2.5 KiB omits the parts a sound system must carry:

1. PCS openings (~1–4 KiB if succinct),
2. Fold verification log (in the fold-log design: the per-fold-pre-instance commitments + com(T) entries, ~3–5 KiB amortised for typical fold counts),
3. Norm proofs (~20–80 KiB for SIS/Hash post-quantum).

Closing these gaps yields estimated honest sizes of ~5–12 KiB (classical) and ~30–100+ KiB (post-quantum).

The audit trail is preserved by construction: the prover can publish the full proof off-chain; anyone can verify that its commitment hashes match the slim proof, confirming both refer to the same witness. The full proof serves as a legally binding audit record, while the slim proof serves as the transaction payload.

Positioning. Because the verifier gap remains open, NovaSlim is best positioned as a fund-recovery mechanism — verified by a Plutus contract once classical signatures are disabled on Cardano — rather than as a day-to-day signing scheme.

Step circuits are bundled in circom/:

• Ed25519Verify/ — Ed25519 signature verification (~7.7K constraints)
• PoseidonSponge/ — Poseidon hash chain (~633 constraints, comparable to Sonobe)
• Sha256Step/ — SHA-256 hash chain (~29K–59K constraints, small/medium/big)
• VRF/ — VRF ladder step (~9 constraints)
• PoseidonMerkle/ — Merkle path verification (~639 constraints)
• PoseidonPreimage/ — Poseidon hash pre-image (secret → public commitment)

All proof modes are produced by nova-slim compress and consumed by nova-slim verify. The guarantees they carry differ substantially.

What each proves (and does not):

• slim (level-0, on-chain). Checks the sumcheck transcript over the relaxed R1CS; it does not open the committed witness/error, evaluate the MLEs at the random point, or verify the fold. An all-zero polynomial transcript passes against any bundle, because relaxed R1CS has a free error vector E. Accepting a slim proof therefore attests honest pipeline execution, not knowledge of a valid witness against an untrusted prover. Adversary risk: a malicious prover can pick a free E and pass trivially; sound only in the batch-proving model (verifier trusts the prover during folding). PQ: commitment scheme may be Pedersen (classical, DLP-based), SIS/Ajtai, or Hash.

• full sumcheck (off-chain audit). Adds the HashPC opening proofs and commitment checks, so it binds the transcript to a witness. It is the legacy verify_sumcheck_compression path that relies on claimed_product_at_r alone; it is auditable but not the preferred sound verifier.

• level-1 — the sound verifier. Runs the complete verifier: the degree-2 sumcheck, the final-claim-zero check on the MLE-of-product residual (fr_r − u·cz_r − er_r == 0), commitment consistency, and — when a circuit is supplied — the circuit-backed PCS opening predicate (recompute AZ/BZ/CZ/fr from the opened truth table and check MLE(tt_E)(r) == er_r). This closes the free-E attack that breaks slim at level-0. Adversary risk: without --circuit, the OP (opening) check is skipped; pass --circuit on verify (or use verify_full with a circuit) for the full OP-backed guarantees. PQ: as with slim; commitment scheme dependent.

• level-1 + norm-range / norm-jl. Adds an audit-only norm certificate that each fold step's pre-fold witness satisfies ∥Z_j∥_∞, ∥E_j∥_∞ ≤ 2^B. Verification re-folds --circuit --steps and cross-checks the carried record. PQ: this is what moves the SIS/Hash instantiations toward a fully sound post-quantum guarantee, at 34–42 KiB. It is audit-only: it does not change the on-chain verifier.

PQ note. None of the modes changes the fundamental status:

• Protocol-level QROM security is proven (Fiat–Shamir under a quantum random oracle, thm:qrom-fs; quantum extraction via commitment collapsing, thm:qrom-2), conditional on flagged ideal-primitive and norm-enforcement assumptions.
• Concrete bit-security for the post-quantum (SIS/Hash) instantiations is conjectured: it composes (SIS/Hash hardness) × (heuristic BKZ/sieving cost model) × (non-tight reduction margin Δκ ≈ 2k·log₂q). Norm enforcement narrows but does not fully close this conjectured label.
• Pedersen (classical) is secure against classical adversaries under the DLP assumption; it is not post-quantum.

Prerequisites: Rust, circom (only if the .r1cs is not compiled yet), snarkjs (witness generation), Node.js.

# 1. Build the CLI
cargo build --release --manifest-path cli/Cargo.toml
NOVA=cli/target/release/nova-slim

# 2. Compile the step circuit (.r1cs is git-ignored, so it must be compiled
#    from source; the .wasm witness calculator is needed for step 3)
#    circom prime ↔ CLI curve:
#      bls12381 ↔ bls12-381   bn128 ↔ bn254   pallas ↔ pallas   vesta ↔ vesta
cd circom/Ed25519Verify
circom --prime bn128 -l node_modules/circomlib/circuits \
    ed25519_verify_nova.circom --r1cs --wasm --sym
cd -

# 3. Generate 255 chained step witnesses (snarkjs-driven, resumable):
#    python3 benchmarks/gen_step_witnesses.py --wasm \
#      circom/Ed25519Verify/ed25519_verify_nova_js/ed25519_verify_nova.wasm \
#      --initial <input.json> --outputs <in_sig=out_sig,...> \
#      --steps 255 --dir <witness-dir>

# 4. Inspect the step circuit — must report n_pub_in == n_pub_out == 24
$NOVA params --curve bn254 --circuit circom/Ed25519Verify/ed25519_verify_nova.r1cs

# 5. Fold 255 steps into one transparent bundle (~1–2 min)
#    Use --commitment pedersen (default), --commitment sis (lattice-based,
#    faster folding), or --commitment hash (zero-param, on-the-fly derivation)
$NOVA fold --curve bn254 --circuit circom/Ed25519Verify/ed25519_verify_nova.r1cs \
    --steps <witness-dir> --out ed25519.ivc.cbor

# 6a. On-chain path: slim proof (~1.5 KiB CBOR for Ed25519, no openings)
$NOVA compress --slim --curve bn254 \
    --circuit circom/Ed25519Verify/ed25519_verify_nova.r1cs \
    --steps <witness-dir> --out ed25519_slim.proof.cbor
$NOVA verify --curve bn254 --ivc ed25519.ivc.cbor --slim-proof ed25519_slim.proof.cbor

# 6b. Audit path: full sumcheck proof (~240 KiB, includes HashPC openings)
$NOVA compress --curve bn254 \
    --circuit circom/Ed25519Verify/ed25519_verify_nova.r1cs \
    --steps <witness-dir> --out ed25519_full.proof.cbor
$NOVA verify --curve bn254 --ivc ed25519.ivc.cbor --sumcheck-proof ed25519_full.proof.cbor

# Library tests (97 tests)
cargo test --release --manifest-path prover/Cargo.toml

# CLI integration tests (25 tests; includes real-circuit end-to-end flows)
cargo test --release --manifest-path cli/Cargo.toml

Notes:

• Use --release — debug builds are impractically slow on the real 7,724-constraint step circuits (>10 min vs ~90 s).
• Witness generation inside tests uses snarkjs; without it only the synthetic-circuit tests run.

Make sure the RELEASE_TOKEN secret exists in GitHub (Settings → Secrets and variables → Actions). It must be a fine-grained PAT with Workflows (read+write) and Contents (read+write) permissions on this repo — GitHub's hardened Releases API rejects the default GITHUB_TOKEN for releases whose target commit touches .github/workflows/.

Update these files from the old version to the new one:

• cli/Cargo.toml → version
• prover/Cargo.toml → version
• cardano/nova-slim-verifier/aiken.toml → version
• cli/tests/cli.rs → the --version test assertion (lines ~630 & ~646)

Also add a matching ## [X.Y.Z] section in ChangeLog.txt. Merge to master. (The release workflow has no separate version setting — the release body and tag come from the tag you push in Step 2.)

git tag v0.3.0 && git push origin v0.3.0

Pushing the tag triggers the release workflow, which builds nova-slim and creates a draft release with the binary (tar.gz + sha256sums) attached and the ChangeLog.txt section as release notes.

Open the draft release in GitHub → inspect it → click Publish release.

Unless a figure is explicitly labelled prior reference, the numbers below were freshly measured on this machine (4 logical cores, Intel i7-7500U @ 2.7 GHz, 31 GiB RAM) with release builds. Two harnesses are provided:

1. benchmark_nova — real circom step circuits (.r1cs compiled from circom/, chained witnesses via snarkjs). Supports BLS12-381, BN254, Grumpkin, Pallas, Vesta.
2. benchmark_synthetic — random in-memory witnesses, no circom/snarkjs. Supports all six curves; Bandersnatch is available here only (circom has no Bandersnatch scalar-field prime).

1. All circuit families in one shot (compiles circuits if needed, generates or resumes witnesses, runs baseline + --opt-parallel passes, writes raw logs and a markdown summary under benchmarks/results/):

   python3 benchmarks/run_benchmarks.py                     # all families, default steps
   python3 benchmarks/run_benchmarks.py --curve grumpkin    # filter by curve
   python3 benchmarks/run_benchmarks.py --family ed25519_verify_nova_bls12_381
   python3 benchmarks/run_benchmarks.py --steps 32 --commitment sis --sis-param 4

2. One real circuit directly (benchmark_nova; needs the compiled .r1cs and a directory of step witnesses):

   cargo run --release --manifest-path prover/Cargo.toml --bin benchmark_nova -- \
     --curve bls12-381 --commitment pedersen \
     --circuit circom/Ed25519Verify/ed25519_verify_nova.r1cs --steps /tmp/steps/

3. Synthetic circuit on any curve (benchmark_synthetic; no snarkjs):

   cargo run --release --manifest-path prover/Cargo.toml --bin benchmark_synthetic -- \
     --curve bandersnatch --state-width 24 --steps 255

0. All verifications OK. Every run — full sumcheck, slim, Level-1 (final-claim-zero residual), and both norm certificates (Option A range / Option B JL) — reports all verifications OK. This includes the real VRF circuit, the smallest possible step circuit (9 constraints), which exercises the full Level-1 + norm path end to end.

1. Proof sizes. The slim/on-chain proof depends only on k = log2 n_constraints — not on step count nor step width:

• The bundle is O(1) in step count and circuit size (≤ 2.5 KiB everywhere).
• Level-1 adds the commitment openings + final-claim-zero residual check (1.4 KiB for VRF), keeping the proof well within on-chain budgets.

2. End-to-end timing — real VRF circuit (bls12-381, Pedersen, 254 steps):

• The 9-constraint VRF circuit isolates protocol overhead; it shows the slim verifier is sub-millisecond and independent of step count.
• Norm certificates carry one entry per fold step (254 here), so their proofs (33–41 KiB) grow with step count — they are an off-chain/audit payload, not the on-chain slim proof.

3. Commitment-scheme modularity (synthetic, bls12-381, 254 steps, state-width 24). The commitment scheme is swappable at runtime without changing the proof format:

• Pedersen — 4.1 ms/step fold, slim 0.4 KiB (0.2 ms verify).
• SIS (m=4) — 0.53 ms/step fold (~8× faster than Pedersen): MSM is replaced by matrix–vector products over the scalar field.
• Hash — 4.8 ms/step fold (Blake2b coefficients derived on the fly), simplest to audit.
• SIS (m=128) — 3.3 ms/step fold (cryptographic parameters).
• Slim proof is ~0.4 KiB for all three — independent of the scheme.

4. Curve comparison (synthetic, Pedersen, state-width 24, 254 steps. Fold ms/step):

• The slim proof size is identical across curves — the sumcheck protocol is field-agnostic.

5. Parallel speedup. Visible mainly in the compress step (sumcheck processes n_constraints rows in parallel). At small sizes (≤7K constraints) thread overhead dominates and parallel mode is neutral to slightly slower; for state-width-24 synthetic circuits the fold scales with available cores.

6. Memory. Prover memory is O(1) in step count — only the current witness is kept in memory; R1CS matrices are loaded once (synthetic runs peak ~5 MiB; well under 100 MiB even for 59K-constraint circuits).

7. Batch-fold with checkpoints (P2b, synthetic, bls12-381, 255 steps, state-width 24). Using --batch-size with batch_fold_with_checkpoints amortizes commitment work across steps and can improve fold throughput:

• Pedersen benefits most because batching amortizes the expensive MSM across multiple steps. The cross-term commitment is computed once per batch rather than once per step.
• Hash benefits modestly: coefficient derivation is cheaper per batch.
• SIS is already so fast (matrix–vector product) that the batch overhead (norm checks, checkpoint bookkeeping) dominates; batching is neutral to slightly slower.
• The slim proof size is unchanged (~0.4 KiB) because the final accumulator is identical regardless of fold path.
• CLI usage: nova-slim fold --batch-size 127 --bound-bits 256 and nova-slim compress --batch-size 127 --bound-bits 256.

Prior reference — original 16-core / 64 GiB machine. These heavier circuits were not re-measured on this box (they take tens of minutes to hours on 4 cores); the figures below are retained from the original 16-core machine for continuity and should not be read as current:

• Versus Sonobe (PoseidonSponge, 633 cstr, 32 steps, prior reference): fold ~14.7× faster than Nova+CycleFold+Groth16, verify ~7,700× faster (0.7 ms slim vs 5.4 s), with no preprocessing / no keygen.
• A full 32-step SHA-256-big fold was ~30 min on the 16-core machine (~3 min with parallel compression).