Skip to content

PCS: add a versioned dual-basis opening for virtual claims #121

Description

@wu-s-john

Add an explicit virtual-claim opening mode that bypasses the dense bit inner-product sumcheck by reducing public virtual-map weights directly to one packed Ligerito claim. Preserve the arbitrary-row/column LinearClaim -> MleClaim API and fallback being improved in #54 and PR #69; this is a separate versioned integration, not their replacement.

Sources

BitZ general linear-claim contract and opening orchestration is normative for the target contract. PoC dual-basis protocol and verifier is implementation reference only; preserve target field, layout, transcript and security requirements unless this issue explicitly introduces a versioned protocol.

Relation and layout

Let f be the committed bit vector, M the public F2-linear virtual map, and h=M(1 || f), including the target's logical constant-one coordinate. Keep the target's mod-q evaluation and no-wrap exponent checks. Use K=GF(2^128) with the target GHASH polynomial and monomial packing P[y]=Σ_v f[128y+v]X^v; q-values and K-values are not interchangeable. Define dual elements A(e_v) by c0(X^u A(e_v))=δ_uv. Public data includes both geometries, M's canonical digest, claim weights/values, q, generator, PCS profile and root.

Proposed normative protocol

  1. Bind a fresh virtual-opening version and the complete statement before any claim-dependent draw. Preserve the initial OOD/grinding flow owned by PR feat: add initial OOD sampling to BitZ commitments #76 when the profile requires it.
  2. Run the existing integer folds/GKR and required residual reductions on h, obtaining authenticated-pending K-linear claims (E_l, μ_l). After those messages, draw batching scalars η_l and derive (w0,W)=Mᵀ(Σ_l η_l E_l), separating the constant-column weight w0 from weights W on f. Open against adjusted target μ′=Σ_l η_l μ_l−w0 in K. Drop weights on virtual zero padding and zero-pad W to the committed shape, preserving the target transpose contract.
  3. Prover sends exactly 128 K elements h_i=⟨P,A(bitplane_i(W))⟩. Check Σ_i c0(h_i)X^i=μ′; absorb the entire ordered vector, then squeeze seven K challenges and expand their equality tensor to ρ_i.
  4. Derive packed basis a'=Σ_i ρ_i A(bitplane_i(W)) and target h'=Σ_i ρ_i h_i. Incorporate the required OOD claim in the same opening under its post-message batching challenge. Run the target Ligerito protocol against f's original commitment.

The serialized proof must distinguish this mode. Specify field encodings, all new domains and exact absorb/squeeze order in the implementation spec; account for both η and equality-tensor batching errors in the existing security budget.

Ordered verifier and acceptance

Validate mode, shapes, map digest, modulus/profile and counts; replay initial OOD; verify integer range/no-wrap and GKR/residual chains; derive η, separate w0 and W, and adjust the target to μ′; read/check/absorb h_i; derive ρ and the public packed-basis residual; verify the complete Ligerito opening and OOD term; accept only after all authentication, terminal checks and proof-consumption checks pass. Never accept merely because the dual-basis reconstruction matches.

Impact and done when

Remove the N-element expanded field witness and bridge sumcheck; the packed basis has N/128 entries, but plane/weight memory remains. Require matched phase/RSS measurements, positive generic/structured-map round trips with nonzero constant-column weights and virtual/committed padding, arbitrary-weight fallback coverage, negative root/map/geometry/claim/plane/order/OOD/truncation tests, and protocol golden vectors. No change to #54's general API contract or duplicate initial-OOD implementation is in scope.

Dependencies and coordination

No prerequisite optimization port. Coordinate with #54, #69, #76.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    difficulty: hardProtocol, architecture, or cross-layer correctness work.enhancementNew feature or requestoptimization-portSeptember 2026 audited optimization backlog from BitZ-PoC.pcsOptimization area: pcs.ring-switchOptimization area: ring switch.urgency: highMajor prover bottleneck or prerequisite for valuable follow-on work.virtual-openingOptimization area: virtual opening.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions