p3-commit

A framework for cryptographic commitment schemes, including non-hiding variants. This crate defines the traits that connect proof systems to their commitment backends.

Key items:

• Pcs / MultilinearPcs — polynomial commitment scheme interfaces used by the STARK provers and verifiers
• Mmcs — "Mixed Matrix Commitment Scheme", a vector-commitment abstraction over batches of matrices of differing heights
• PolynomialSpace and TwoAdicMultiplicativeCoset — evaluation-domain abstractions
• periodic — periodic-column evaluation helpers
• testing (the opt-in test-utils feature) — mock instantiations and shared PCS contract checks for downstream tests

Implementations live in p3-merkle-tree (Mmcs), p3-fri, p3-circle and p3-whir (Pcs).

testing::assert_pcs_opening_contract exercises real transparent backends with caller-supplied matrices and independently computed expected values. It checks batched opening order, honest verification, transcript agreement, and rejection of swapped point fields, modified values and missing matrix/column claims. Fixtures must include a multi-matrix commitment and point-dependent expected values. FRI, Circle, and STIR use this helper alongside their backend-specific tests.

Part of Plonky3, dual-licensed under MIT and Apache 2.0.

Univariate PCS API migration

Pcs covers domains, commitments, prover data, and opening/verification. Implementers that serve univariate STARKs also implement UnivariateStarkPcs: move EvaluationsOnDomain, ZK, LDE/evaluation/quotient/periodic helpers and preprocessing adaptation to that implementation. Generic commitment clients can continue to bound only Pcs; STARK configurations require UnivariateStarkPcs. Import both traits when calling both sets of methods, and change qualified references to moved members to UnivariateStarkPcs. MultilinearPcs is unchanged.

Opening batches now use named requests and claims:

let requests = vec![OpeningRequest {
    prover_data: &data,
    points: vec![vec![zeta]], // one point vector per committed matrix
}];
let claims = vec![CommitmentOpening {
    commitment,
    matrices: vec![MatrixOpening {
        domain,
        points: vec![PointOpening { point: zeta, values }],
    }],
}];

Requests borrow prover data and own their point vectors. Claims own commitments, matrices and column values, as before. All ordering remains significant: requests, matrices, points and columns are used in caller order. The existing CommitmentWithOpeningPoints name aliases CommitmentOpening. Explicit From conversions accept the former tuples, including nested matrix/point claims, so a caller can migrate a batch with old_batch.into_iter().map(Into::into).collect(). The FRI ProverDataWithOpeningPoints alias likewise names OpeningRequest.

PCS traits no longer define trace, quotient or preprocessing commitment indices. Univariate STARK owns these positions in p3_uni_stark::StarkOpeningLayout. open_with_preprocessing now takes Option<usize> identifying the preprocessing commitment request, replacing the old boolean. Use None for no preprocessing; STARK callers pass Some(layout.preprocessed) when it is present. Other clients may place preprocessing at any commitment index.

This is a Rust API change only; commitment/proof serialization, transcript absorption order and evaluation-view ownership remain unchanged. No version bump is included.