Feat: jagged pcs

[kunxian-xia]

Summary

This PR includes works in several separate PRs.

PR/Commit	Note
#31	compute q(b) from the input row major matrices
#32	run the jagged sumcheck $v = \sum_b q(b) * f(b)$ in a memory constrained device (note that both q and f have around 30 ~ 32 variables)
#39	evaluator for indicator function $g(z_1, z_2, z_3, z_4)$
4c3a23f	verifier for $f(z) = \sum_c \textrm{eq}(z_c, c) * g(z_r, z, t_c, t_{c+1})$
#42	jagged assist sumcheck
#48	stacked pcs (reshape q(b) as several smaller multilinear polynomials)
#47	batch open multiple sets of matrices

Key difference from SP1's Jagged PCS

Unlike SP1's jagged PCS (eprint 2025/917) which uses raw heights $h_i$ as block sizes in the packed polynomial $q'$, our implementation uses $2^{s_i}$ (where $s_i = \lceil \log_2 h_i \rceil$). This is because Ceno's main sumcheck evaluates polynomials at a suffix of the challenge point, requiring a bit-reversal permutation (suffix-to-prefix transformation) to make the jagged sumcheck work with prefix-aligned points.

Before bit-reversal, each polynomial $p_i$ is zero-padded from $h_i$ to $2^{s_i}$ entries. After bit-reversal, these zeros are scattered throughout the block (not contiguous at the end), so each polynomial must occupy a full $2^{s_i}$-entry block in $q'$. This means $q'$ contains $\sum_i (2^{s_i} - h_i)$ extra zeros compared to SP1's approach.

Integration Tests

The main integration test (test_jagged_batch_open_verify_small and variants) exercises the full protocol pipeline end-to-end:

1. Commit — builds matrices, calls jagged_commit (bit-reversal, transpose, concatenation, inner PCS commit)
2. Evaluate — computes true column polynomial evaluations at random points (ground truth, independent of the jagged machinery)
3. Batch Open — calls jagged_batch_open (transcript setup, jagged sumcheck, inner PCS open)
4. Batch Verify — calls jagged_batch_verify (transcript replay, sumcheck verify, ROBP ĝ evaluation, inner PCS verify)

This touches every submodule: types (structs), sumcheck (streaming prover), evaluator (ROBP ĝ), and mod.rs (commit/open/verify).

Three variants cover different scenarios:

• _small — 3 matrices with different heights ($2^{10}$, $2^{11}$, $2^{9}$), each with 1 column: exercises different-height polynomial handling with correction factors $C_i = \textrm{eq}(z_r[s_i..], 0)$
• _single_poly — 1 column: edge case where num_polys = 1
• _soundness — tampers evals[1] += 1 and asserts the verifier rejects: confirms the protocol actually catches cheating

[kunxian-xia]

@copilot Let $T$ denote the number of total evaluations in the giga mle $q(x)$ (we pad it to next power of 2 s.t. $n = \lceil \log T \rceil$). Please run a careful check to see if we have the following checks:

1. In the ROBP based evaluator for $g(z_{\textrm{row}}, z_\rho, t_{i}, t_{i+1})$: $z_{\textrm{row}}, z_\rho$ are padded to have length $n+1$.
2. The final evaluated point in jagged assist sumcheck has length $2*(n+1)$, the jagged assist sumcheck has $2*(n+1)$ rounds.

Please think with highest scrutiny. Correct me if I'm wrong about the above checks.

[Copilot]

@copilot Let $T$ denote the number of total evaluations in the giga mle $q(x)$ (we pad it to next power of 2 s.t. $n = \lceil \log T \rceil$). Please run a careful check to see if we have the followi...

The checks are only partially correct — both depend on whether total_evals is a power of 2.

Let n = num_giga_vars = ⌈log₂(total_evals)⌉. The ROBP needs to represent cumulative heights t_i ∈ [0, total_evals]. The key constraint is whether total_evals itself fits in n bits:

• total_evals < 2^n (not a power of 2): total_evals ≤ 2^n − 1, fits in n bits → n_robp = n
• total_evals = 2^n (is a power of 2): total_evals = 2^n requires n+1 bits → n_robp = n + 1

The code captures this correctly:

let n_robp = num_giga_vars + if total_evals.is_power_of_two() { 1 } else { 0 };

Check 1 — "z_row, z_ρ are padded to length n+1": Only true when total_evals = 2^n. Otherwise they have length n. The current code pads to n_robp (n or n+1).

Check 2 — "assist sumcheck has 2*(n+1) rounds": Same condition. Rounds = 2 * n_robp = 2n or 2(n+1).

So your checks are too strong in general — they hold only for the power-of-two case. The conditional n_robp logic is the correct and efficient approach.

[kunxian-xia]

@copilot read this issue scroll-tech/ceno#1334, give me a plan to revise the fn jagged_batch_open() to support at least two sets of (point, evals). Create a new PR on top of this PR that contains the initial design / plan in markdown. Do not start the implementation before we're aligned on the design.

[Copilot]

@kunxian-xia I've opened a new pull request, #47, to work on those changes. Once the pull request is ready, I'll request review from you.

[hero78119]

Awesome great job 🔥 👍