Add an opt-in benchmarkable API for same-shape related virtual claims to share GKR rounds and one final opening. This issue owns structured claim planning and its protocol composition; baseline GKR already batches tree/output indices, so it is not a second generic forest implementation.
Sources
BitZ proof-to-opening contract and PCS statement binding is normative for the target contract. PoC multi-claim forest and canonical tap-collapse plan is implementation reference only; preserve target field, layout, transcript and security requirements unless this issue explicitly introduces a versioned protocol.
Relation and eligibility
Represent public tap operations explicitly: selected committed columns, XOR sets, rotation/shift widths, offsets, dropout boundaries, row/column weights and claimed values. Define canonical XOR cancellation and ordering. Validate transform eligibility against the physical/logical layout, including the reference's low-bit fold restrictions; do not assume arbitrary permutations preserve a tensor split. Integer claims retain the target q/no-wrap checks; tap actions are F2-linear, and GKR/PCS arithmetic is in K.
Proposed normative flow
Bind a fresh version, ordered roots, complete tap descriptors, both geometries, weights/claims and profile before challenges; retain required initial OOD via PR #76. Derive a deterministic public plan of unique source sets and carry/dropout branches. After binding that plan, draw claim-combination challenges in the specified field. Produce range-checked folds in canonical branch order. Prove compatible claims through one merged forest with a bound claim-index dimension; absorb its roots before the shared point, each sumcheck message before its challenge and child values before line challenges. Reduce terminal tap claims through the explicit adjoint transforms to original committed columns. Absorb all ring/closure messages before batching draws and execute one final opening carrying every residual and required OOD term.
Ordered verifier
Validate descriptors/profile; reconstruct the canonical plan and reject ineligible transforms or wrong branch counts; replay OOD and batching; check integer folds and merged GKR; verify every carry/dropout relation and transformed terminal claim; replay ring batching; authenticate the complete combined PCS claim to the original roots; reject leftover/missing proof data. Collapsing a source set must never discard a boundary or constant contribution.
Impact and done when
Potential savings are shared transcript/round overhead and repeated source preparation, not sublinear leaf work. Compare to separate complete proofs, including any additional closure cost. Require positive direct-versus-collapsed relations, randomized transform tests, negative wrong-offset/dropout/set/root/claim/OOD tests and golden vectors for the new mode. Start with a bounded documented operation subset; unsupported claims use existing APIs. Keep opt-in unless matched workload results justify promotion; hybrid and RLC case-weight protocols belong to #132 and #131.
Dependencies and coordination
Requires #107, #120. Coordinate with #8, #76.
Add an opt-in benchmarkable API for same-shape related virtual claims to share GKR rounds and one final opening. This issue owns structured claim planning and its protocol composition; baseline GKR already batches tree/output indices, so it is not a second generic forest implementation.
Sources
BitZ proof-to-opening contract and PCS statement binding is normative for the target contract. PoC multi-claim forest and canonical tap-collapse plan is implementation reference only; preserve target field, layout, transcript and security requirements unless this issue explicitly introduces a versioned protocol.
Relation and eligibility
Represent public tap operations explicitly: selected committed columns, XOR sets, rotation/shift widths, offsets, dropout boundaries, row/column weights and claimed values. Define canonical XOR cancellation and ordering. Validate transform eligibility against the physical/logical layout, including the reference's low-bit fold restrictions; do not assume arbitrary permutations preserve a tensor split. Integer claims retain the target q/no-wrap checks; tap actions are F2-linear, and GKR/PCS arithmetic is in K.
Proposed normative flow
Bind a fresh version, ordered roots, complete tap descriptors, both geometries, weights/claims and profile before challenges; retain required initial OOD via PR #76. Derive a deterministic public plan of unique source sets and carry/dropout branches. After binding that plan, draw claim-combination challenges in the specified field. Produce range-checked folds in canonical branch order. Prove compatible claims through one merged forest with a bound claim-index dimension; absorb its roots before the shared point, each sumcheck message before its challenge and child values before line challenges. Reduce terminal tap claims through the explicit adjoint transforms to original committed columns. Absorb all ring/closure messages before batching draws and execute one final opening carrying every residual and required OOD term.
Ordered verifier
Validate descriptors/profile; reconstruct the canonical plan and reject ineligible transforms or wrong branch counts; replay OOD and batching; check integer folds and merged GKR; verify every carry/dropout relation and transformed terminal claim; replay ring batching; authenticate the complete combined PCS claim to the original roots; reject leftover/missing proof data. Collapsing a source set must never discard a boundary or constant contribution.
Impact and done when
Potential savings are shared transcript/round overhead and repeated source preparation, not sublinear leaf work. Compare to separate complete proofs, including any additional closure cost. Require positive direct-versus-collapsed relations, randomized transform tests, negative wrong-offset/dropout/set/root/claim/OOD tests and golden vectors for the new mode. Start with a bounded documented operation subset; unsupported claims use existing APIs. Keep opt-in unless matched workload results justify promotion; hybrid and RLC case-weight protocols belong to #132 and #131.
Dependencies and coordination
Requires #107, #120. Coordinate with #8, #76.