aere-research/pq-stark/spec-fri-babybear.md

FRI verifier over BabyBear: config + fold/opening relation + conformance KAT (component (d), 0x0AE8)

Scope caveat (2026-07-19 finding). "Plonky3/SP1" wording below means Plonky3 0.4.3-succinct (Aere's OWN BabyBear + FRI STARK stack). It does NOT mean the pinned SP1 6.1.0, which is a Hypercube release whose inner recursion proof uses BaseFold, NOT FRI. This FRI low-degree test does not apply to SP1 6.1.0 at all; it is conformance-confirmed for a BabyBear + FRI STARK verifier (Aere's own Plonky3 circuits), not for an SP1 6.1.0 verifier. See ../../docs/AERE-STARK-SP1-RECURSION-AIR-PORT-SPEC-SUMMARY.md.

Date: 2026-07-19. Status: FRI config CONFIRMED-FROM-SOURCE; fold + opening relation (verify_query) IMPLEMENTED; real conformance KAT PASSED (accept genuine + reject tampered).

This records the exact FRI low-degree test Plonky3/SP1 use over BabyBear, traced from the pinned p3-fri source, the fold + opening relation the verifier checks, and the real known-answer test that confirms conformance. The top-level precompile 0x0AE8 stays FAIL-CLOSED (returns EMPTY for every input) regardless: this component being confirmed does not port the duplex-sponge Fiat-Shamir challenger (component (f)) that binds the transcript, nor the SP1 recursion-AIR (component (e)).

Pinned target (exact, checksum-matched)

The FRI verifier is p3_fri::verifier from p3-fri, its commit-phase MMCS is ExtensionMmcs from p3-commit wrapping the CONFIRMED FieldMerkleTreeMmcs (component (c)), and the challenger used to emit the ground truth is DuplexChallenger from p3-challenger. All crates.io version 0.4.3-succinct (the Succinct Plonky3 fork), the revision pinned in the repo's Cargo.lock files:

• p3-fri 0.4.3-succinct, sha256 5cbc4965ee488f3247867b7ec4bb005b8afa72cb0d461a4dcb1387ecab6426d5
• p3-challenger 0.4.3-succinct, sha256 b6a908924d43e4cfb93fb41c8346cac211b70314385a9037e9241f5b7f3eaf77
• p3-dft 0.4.3-succinct, sha256 be6408b10a2c27eb13a7d5580c546c2179a8dc7dbc10a990657311891f9b41c0
• p3-commit 0.4.3-succinct, sha256 50acacc7219fce6c01db938f82c1b21b5e7133990b7fff861f91534aeb569419

Found in aerenew/zk-circuits/*/Cargo.lock and aerenew/rollup-evm-validity/*/Cargo.lock. A fresh cargo build of the extractor (below) resolved the SAME checksums, so the crates executed are byte-identical to the ones the AERE prover pins.

The confirmed FRI config (traced from p3-fri source)

FriConfig (p3-fri config.rs) has exactly four fields: { log_blowup, num_queries, proof_of_work_bits, mmcs }. Traced from verifier.rs:

• Folding arity is 2 (hard-coded): each layer opens the sibling pair (index, index ^ 1) and folds index_pair = index >> 1. The comment in proof.rs says a non-2 arity would need multiple siblings; this pinned version is arity 2.
• log_max_height = commit_phase_commits.len() + log_blowup. The commit phase runs for log_max_height - log_blowup layers (for log_folded_height in (log_blowup..log_max_height).rev() in prover.rs commit_phase), so num_fold_rounds = log_max_height - log_blowup.
• The FINAL polynomial is a single CONSTANT final_poly: F (F = the challenge field EF). Folding runs all the way down; after the last fold the remaining blowup() evaluations are all equal, and the verifier checks folded_eval == final_poly for EVERY query (verify_challenges). (The source comment notes it "could become Vec<...> if generalized to support non-constant final polynomials"; in this pinned version it is a constant, so log_final_poly_len = 0.)
• The commit-phase MMCS is ExtensionMmcs<Val, Challenge, ValMmcs> (the FRI codewords live in the degree-4 extension EF = BinomialExtensionField<BabyBear, 4>). Each commit-phase leaf is a PAIR of EF evaluations; ExtensionMmcs::verify_batch flattens each EF element to its 4 base coords (as_base_slice) and concatenates, so a leaf is 8 BabyBear coords, a single width-8 row of a height-2^log_folded_height tree, checked by the CONFIRMED base FieldMerkleTreeMmcs::verify_batch (component (c)).
• Proof-of-work / grinding (proof_of_work_bits, check_witness) is part of the transcript phase (verify_shape_and_sample_challenges), i.e. component (f); it is NOT part of the per-query fold + opening relation this component ports.
• num_queries, log_blowup, proof_of_work_bits are proximity/soundness parameters read from the frozen SP1 config; the values are a [MEASURE] against a real exported proof (see the port spec). The KAT here exercises several (log_blowup, log_max_height, num_queries) shapes to validate the relation independently of the exact frozen numbers.

The fold + opening relation (p3-fri verify_query, ported)

For one query at index (from verifier.rs verify_query, reproduced exactly by the references and by Fri.verifyQuery in the precompile):

folded_eval = 0 in EF
x = two_adic_generator(log_max_height)^reverse_bits_len(index, log_max_height)   # coset point, in EF
for each layer (log_folded_height = log_max_height-1 down to log_blowup):
    folded_eval += reduced_openings[log_folded_height + 1]     # the injected input opening at this height
    index_sibling = index ^ 1;  index_pair = index >> 1
    evals = [folded_eval, folded_eval];  evals[index_sibling % 2] = sibling_value   # the opened sibling
    MMCS.verify_batch(commit_layer, dims={width:2(EF)->8(base), height:2^log_folded_height},
                      index_pair, [evals flattened to 8 base coords], opening_proof)   # component (c)
    xs = [x, x];  xs[index_sibling % 2] *= two_adic_generator(1)   # the sibling point is -x
    folded_eval = evals[0] + (beta - xs[0]) * (evals[1] - evals[0]) / (xs[1] - xs[0])   # interpolate at beta
    index = index_pair;  x = x^2
return folded_eval    # verify_challenges checks this == final_poly for every query

• two_adic_generator(bits) for bits <= 27 is the BabyBear base generator embedded in EF (confirmed from p3-baby-bear extension.rs ext_two_adic_generator), so x is a base-field element embedded in EF; two_adic_generator(1) = -1 (the order-2 root). The arithmetic uses F_{p^4} (component (a)).
• The reduced openings come from the input polynomials in a full STARK (component (e)); for a standalone single-codeword low-degree test they are zero except reduced_openings[log_max_height] = codeword_value_at_index, which the extractor emits as ro_top.

Montgomery / canonical note

Field elements are serialized as canonical u32 (PrimeField32::as_canonical_u32 for base coords). The F_{p^4} fold arithmetic is canonical (component (a)); the Montgomery R^{-1} factor lives entirely inside the Poseidon2 internal layer (component (b), resolved there) and does not surface in the FRI or MMCS layers. As a cross-check, the extractor's permute([0;16]) (emitted as perm_zeros) equals the confirmed Poseidon2 "zeros" vector, and the extractor's two_adic_generator(bits) for bits 0..=27 equals component (a)'s twoAdicGenerator(bits) (this is what makes the fold's coset points come out right, closing the old [VERIFY] on the generator).

How the KAT vectors were obtained (primary source)

A small Rust extractor (pq-stark/fri-extractor, main.rs + Cargo.toml + Cargo.lock) depending on the pinned crates was compiled and run (cargo 1.97.0). It builds the exact SP1 inner FRI config (BabyBear + BinomialExtensionField<_,4> + the seed_from_u64(1) Poseidon2 permutation + FieldMerkleTreeMmcs + ExtensionMmcs + DuplexChallenger<_,_,16,8>), constructs genuinely low-degree codewords (an RS/LDE of a random low-degree polynomial via Radix2Dit, bit-reversed), runs p3_fri::prover::prove to emit a real FriProof, then runs p3_fri::verifier::{verify_shape_and_sample_challenges, verify_challenges} to confirm the pinned LIBRARY itself accepts. It emits everything the reference verifier needs (commit-phase roots, betas, query indices, reduced openings, per-query per-layer sibling values + MMCS opening proofs, final poly), each field element as canonical u32. The output (pq-stark/fri_ground_truth.json) is the authoritative source. Three FRI cases are emitted:

case	log_blowup	log_max_height	num_queries	fold layers
blowup1_h6_q4	1	6	4	5
blowup2_h7_q5	2	7	5	5
blowup1_h8_q6	1	8	6	7

Conformance KAT (real known-answer test, executed from the pinned crates)

The reference (fri_verify_reference.py, .mjs, standalone FriVerifySelfTest.java, and Fri.verifyQuery in the precompile) re-verifies each emitted proof:

• ACCEPT: every query's MMCS openings pass AND every query's folded constant equals final_poly.
• REJECT (four tamper variants per case): a corrupted opened value (breaks the MMCS opening), a corrupted MMCS sibling digest (breaks the opening), a wrong fold challenge beta (breaks the interpolation so folded != final_poly, i.e. a wrong fold), and a non-matching final_poly (the final-poly check, the mechanism that catches a non-low-degree witness).

Result (ran 2026-07-19):

• python test_fri_verify.py -> PASS=55 FAIL=0 (sanity perm + 28 generators; 3 cases x (accept + 4 rejects); Python + Node + Java byte-identical per-query folded values; recorded in ../results/kat-results-fri-verify.json).
• java FriVerifySelfTest fri_ground_truth.json -> PASS=44 FAIL=0.
• The PRECOMPILE's own Sp1StarkVerifierPrecompiledContract.Fri.verifyQuery (driven directly) reproduces accept + reject for all 3 cases (15/15), so the wired code, not just the parallel references, is conformant.

Status summary

• FRI config: CONFIRMED-FROM-SOURCE (arity 2; num_fold_rounds = log_max_height - log_blowup; constant final poly; ExtensionMmcs-over-FieldMerkleTreeMmcs commit phase; traced from p3-fri 0.4.3-succinct; checksums matched Cargo.lock).
• Fold + opening relation (verify_query): IMPLEMENTED (Python/Node/Java + Fri.verifyQuery).
• Conformance KAT: PASSED (3 real FRI proofs accepted, 4 tamper variants each rejected; three-language byte-identical; the precompile's own method also conformant).
• Closed by this KAT (were [VERIFY]): arity-2 fold, num_fold_rounds, reverse-bits index-to-coset-point mapping, two_adic_generator(bits) = Plonky3's, and the F_{p^4} non-residue W = 11 = Plonky3's (the EF fold arithmetic reproduces the interpolation).
• Fri.foldRelationConfirmed = true (the fold + opening relation is confirmed conformant).
• [MEASURE] remaining: conformance against a REAL exported SP1 v6.1.0 inner proof's FRI section (needs the exported proof + the challenger, component (f)) and the AIR reduced openings (component (e)).
• Top-level 0x0AE8: still FAIL-CLOSED (EMPTY for every input). The duplex-sponge challenger (Challenger.spongePorted = false, component (f)) that derives the betas/indices/grinding, and the SP1 recursion-AIR (StarkConstraints = UNAVAILABLE, component (e)) that supplies the reduced openings, are un-ported, so Fri.checkQuery cannot be driven and returns UNAVAILABLE. ACCEPT is unreachable. DO NOT ACTIVATE.