Type Alias KimchiProverProof 

type KimchiProverProof = ProverProof<Vesta, OpeningProof<Vesta, FULL_ROUNDS>, FULL_ROUNDS>;

Aliased Type

struct KimchiProverProof {
    pub commitments: ProverCommitments<Affine<VestaParameters>>,
    pub proof: OpeningProof<Affine<VestaParameters>, 55>,
    pub evals: ProofEvaluations<PointEvaluations<Vec<Fp<MontBackend<FqConfig, 4>, 4>>>>,
    pub ft_eval1: Fp<MontBackend<FqConfig, 4>, 4>,
    pub prev_challenges: Vec<RecursionChallenge<Affine<VestaParameters>>>,
}

Fields

commitments: ProverCommitments<Affine<VestaParameters>>

All the polynomial commitments required in the proof

proof: OpeningProof<Affine<VestaParameters>, 55>

batched commitment opening proof

evals: ProofEvaluations<PointEvaluations<Vec<Fp<MontBackend<FqConfig, 4>, 4>>>>

Two evaluations over a number of committed polynomials

ft_eval1: Fp<MontBackend<FqConfig, 4>, 4>

Required evaluation for Maller’s optimization

prev_challenges: Vec<RecursionChallenge<Affine<VestaParameters>>>

Accumulators from previously verified proofs in the recursion chain.

Each [RecursionChallenge] stores the IPA folding challenges and accumulated commitment from verifying a previous proof. Instead of checking the IPA immediately (which requires an expensive MSM <s, G> where s has 2^k elements), we defer this check by storing the accumulator.

During verification, these accumulators are processed as follows:

1. The commitments are absorbed into the Fiat-Shamir sponge
2. The challenges are used to compute evaluations of b(X) at zeta and zeta * omega (see [RecursionChallenge::evals])
3. These evaluations are paired with the commitments and included in the batched polynomial commitment check

The actual MSM verification happens in SRS::verify (see poly-commitment/src/ipa.rs), where b_poly_coefficients computes the 2^k coefficients and they are batched into a single large MSM with all other verification checks.

This design enables efficient recursive proof composition as described in Section 3.2 of the Halo paper.