Where Part 1 left us
Part 1 ended with an API, not a SNARK. The three-step PIOR reduced UCS satisfiability to an equation that a standard sumcheck-shaped PIOP can handle, but the verifier’s hooks into the witness — the projected polynomial oracles — were left as a contract:
Given a commitment to a multilinear with coefficients in , a verifier-sampled random prime , and a random , the oracle returns for any query point — or when the partial projection isn’t defined.
A commitment scheme has to deliver that interface. And not loosely — the contract has three teeth:
- Proximity. The committed object has to be (close to) the encoding of an honest witness, in some Brakedown-style sense.
- Bit-size enforcement. The extracted coefficients must have bit-size , or Lemma 2.1’s random-prime soundness from Zinc Part 1 doesn’t bite. A generic -PCS gives unbounded extraction; that kills soundness.
- Well-definedness. The committed witness must have defined everywhere — no entry of whose denominator is divisible by the sampled .
The scheme that delivers all three is Zip+. It’s the successor to Zinc Part 2’s Zip, and the paper highlights exactly three changes:
- List-decoding regime via MCA. Zip lived in unique decoding; Zip+ pushes the proximity radius up to the Mutual Correlated Agreement bound. Smaller proofs, lower verifier work.
- Merged test and evaluation phases. Zip had two distinct random-linear-combination rounds — one for codeword-proximity, one for the tensor-identity eval. MCA’s structure lets a single combo carry both.
- IPRS codes instead of JEA. A new linear code over with MDS-optimal distance, FFT-style encoding, and bounded norm growth — three properties JEA could not give simultaneously.
End-to-end, the paper reports proving 7 SHA-256 compressions followed by the multi-scalar-multiplication portion of ECDSA verification in 40.6 ms prover time, 7.0 ms verifier time, 198 KB proof on a MacBook Air M4, at 100 bits of security (same numbers as Part 1 — the headline benchmark for the full stack).
This Part 2 covers Zip+ and IPRS. We restate the contract precisely, walk the three deltas, build IPRS from “lift the FFT not the polynomial,” sketch MCA operationally, layer the Zip+ IOPP construction, and close with the BCS-style compilation that turns the PIOR + PCS stack into a hash-only succinct argument.
Prerequisites. Zinc+ Part 1 — UCS, the three-step PIOR, the projected-oracle interface, Lemma 2.10. Zinc Part 2 — Brakedown skeleton, the tensor identity, commit/test/eval phases over , the IOPP-to- idea, the bit-size lemma chain. Comfort with multilinear extensions, Reed–Solomon codes, the FFT structure of RS encoders, and the localization .
What we won’t cover. The full round-by-round knowledge soundness reduction (paper §3.2 + Appendix A.2). The general-radix IPRS encoder and full distance proof (§7). All of the batching wrappers around the core Zip+ IOPP (§6). These are load-bearing for the soundness argument but not the conceptual story.
A glossary for the rest of the article
A few symbols recur — worth pinning down up front.
- — a linear code over a field , dimension , blocklength , relative distance .
- — the -wise interleaving of . A codeword in is a tuple of codewords from , arranged as rows of a matrix.
- with — the matrix dimensions Zip+ uses internally. Witness of length gets reshaped to .
- — the purported interleaved encoding of that the verifier holds an oracle on.
- — the equality vectors built from the query point for the tensor reformulation of the MLE eval claim.
- , — relative minimum distance of the code; proximity parameter the IOPP runs at. Zip+ pushes up to (close to) , vs. Zip’s .
- MCA — Mutual Correlated Agreement, the property of the code that lets soundness survive past unique decoding.
- — the new code over , parameterized by a base field , evaluation domain , and dimension . Lives in where .
- — a second-prime projection , , used inside Zip+‘s Layer-3 reduction when the target is a high-extension finite field.
- vs — the completeness-vs-soundness bit-size gap. Honest provers use entries of bit-size ; soundness only guarantees rejection at bit-size . The slack is fine — the PIOR’s soundness analysis tolerates a bound (Remark 2.17 of the paper).
What Zip+ has to deliver
Before construction, the contract. The witness is reshaped as a matrix with entries in , where are both powers of . Let be a generator matrix for a linear code over with relative distance . The honest commitment is the interleaved encoding obtained by encoding each row of independently under .
The verifier holds oracle access to . The claim to be checked: for some query point , , target , and finite field obtained from via the projection .
Completeness. If is the honest interleaved encoding of some satisfying — and, when , the projection is well-defined — the verifier accepts with probability .
Soundness. The verifier rejects with high probability if any of:
- is -far from every interleaved encoding of a with , for proximity parameter up to the MCA bound; or
- and has an entry of bit-size above ; or
- and has an entry whose -projection is not well-defined.
The bit-size gap. Honest provers use witnesses with entries in . Soundness only catches cheaters at bit-size for some . This gap is real and fine — paper §2.4 footnote 8 makes the call explicitly: “it is enough for our compilation purposes to guarantee bit-size bound below , not exactly below .” The slack gets absorbed by the PIOR’s downstream Lemma-2.1-style counting argument, which already runs on -bit bounds.
That’s the contract Zip+ implements.
Three changes vs. Zip
Zip+ is Zip with three surgical changes. Pin them down before the construction.
Delta 1 — list-decoding regime, MCA-bounded. Zip’s soundness analysis (Zinc Part 2’s §Testing Phase) ran in the unique decoding regime: the proximity parameter stayed strictly below , so that ” is within distance of some codeword” identified that codeword uniquely. Zip+ pushes all the way up to the Mutual Correlated Agreement (MCA) bound of the code — for any linear code over or any finite field, , the so-called 1.5 Johnson bound [Zei24, [BCFW25]]. Larger means fewer column opens needed to hit bits of soundness, which means smaller proofs and faster verification.
The cost is the soundness analysis. Past unique decoding, ” is close to a unique codeword” is no longer true — there’s a list of nearby codewords, and the analysis has to argue that none of them is a successful cheat. That’s where round-by-round knowledge soundness from [BCFW25] enters — we’ll come back to it in the BCS section below.
Delta 2 — merged test and evaluation phases. Zip’s IOPP had two distinct phases. The testing phase asked “are these rows really codewords?” via one random linear combination across rows; the evaluation phase asked “and does that combination give the claimed evaluation?” via a second random linear combination. Two rounds, two batches of column opens. Zip+ does it in one: the same random combination used to check codeword proximity also implements the row-combine that drives the tensor identity. MCA is what makes this safe — the merged combo’s soundness is exactly the MCA condition on the code.
Delta 3 — IPRS instead of JEA. Zip was instantiated with JEA (Juxtaposed Expand-Accumulate) codes — small entries and linear-time encoding, but suboptimal minimum distance, which dominated the proof-size term. IPRS is a new code with MDS-optimal distance (), FFT-style encoding, and bounded norm growth (relative norm increase of – bits in target configurations, comparable to what 64-bit-field schemes achieve). Three properties simultaneously. JEA could not.
The next three sections take these deltas in order: IPRS first (the new linear-code primitive), then MCA (the soundness primitive that supports Deltas 1 and 2), then the layered IOPP construction.
IPRS: lift the FFT, not the polynomial
Every code-based PCS over runs into a trilemma. The code needs good minimum distance (so the IOPP needs few queries per soundness bit), efficient encoding (so the prover’s commit step doesn’t blow up), and bounded codeword norm growth (so committing rationals doesn’t produce kilobit-per-entry codewords). Naive constructions get two of the three. IPRS gets all three.
Walk through the naive attempts first — they make the trick clear.
Naive attempt 1: RS over . Define the code as evaluations of rational-coefficient polynomials on a fixed integer subset :
Minimum distance is fine — it’s the standard RS bound. Encoding is fine — same FFT-shaped algorithm as RS, just executed over instead of . Norm is catastrophic. A degree- polynomial evaluated at gives entries of order . For practical (say ) and any , codeword entries blow up to hundreds of thousands or millions of bits. The committer has to Merkle-hash all of it. Dead.
Naive attempt 2: lift the Vandermonde matrix. Take a standard RS code over a small finite field. It has a Vandermonde generator matrix with entries in . View as an integer matrix, then define the lift:
Norm growth is now fine — entries are bounded by , so bits per entry. Lemma 2.12 in the paper shows that lifted codes preserve both dimension and minimum distance, so the MDS property of RS survives. But encoding has no FFT structure. The radix- butterfly that gives RS its encoding relies on the fact that squaring an -th root of unity gives an -th root of unity — an identity that holds in but is destroyed when you lift the twiddle factors to and stop reducing modulo . Encoding collapses to naive matrix-vector multiplication. For , that’s rational multiplications per commit. Dead.
The IPRS trick: lift the algorithm, not the algebra. Pick an FFT encoder for the finite-field RS code — fix the radix (say ), the twiddle factors for the chosen primitive -th root of unity , the recursion depth. Now identify each element with its centered integer representative via . Execute the same FFT recursion — same butterfly equation — but with every twiddle factor replaced by and every operation performed over (or , for rational messages) with no modular reduction.
The output is no longer the evaluation vector of any polynomial. Squaring over does not give . The “evaluations” of the recursive subproblems aren’t really evaluations of anything. And that’s fine. The IOPP doesn’t need the polynomial-evaluation semantics — it needs a linear code with good distance, fast encoding, and bounded entries. The semantics was scaffolding.
Definition (paper Definition 2.13). Given a prime , a multiplicative subgroup , a dimension , and a fixed FFT algorithm for :
Properties (paper Theorem 2.14). is a linear code over of dimension , blocklength , and minimum relative distance — MDS-optimal, same as RS. The norm bound:
In the paper’s target configurations ( to , , depth –, radix ), this works out to a relative norm increase of roughly 40–60 bits. Comparable to what field-native schemes achieve over -bit fields when encoding small-norm messages. Far below the thousands of bits naive RS over would produce. The proof (paper §7.2) is a corollary of Lemma 2.12: IPRS is a lift of an RS code under a specific generator matrix (not Vandermonde), so it inherits both dimension and minimum distance.
The trilemma resolved:
| Construction | Relative norm growth | FFT structure |
|---|---|---|
| Naive RS over | yes (but moot) | |
| Lifted Vandermonde | no | |
| IPRS | yes |
Concrete encoding cost: encoding a vector of length with entries in takes ms multithreaded on M4 with the paper’s radix- IPRS implementation (Table 2 of the paper). Vectors of -bit integers at the same length: ms. These are the costs upstream of the IOPP — the per-commit hash work and the per-row Merkle structure run on top.
One open question (paper §2.3.4). Whether IPRS codes have MCA up to the standard Johnson bound (better than the 1.5 Johnson bound that is known to hold for all linear codes), as RS codes do. The paper proves the 1.5 Johnson bound for IPRS via the general result on -codes; the Johnson-bound version would directly tighten Zinc+‘s proof sizes. Open at time of writing.
MCA: living past unique decoding
Brakedown’s classical soundness needed proximity within unique decoding — — because the analysis turned on “if is -close to a codeword , then is unique.” Zip+ pushes proximity up to the 1.5 Johnson bound , well past unique decoding. The fix is MCA.
Mutual Correlated Agreement, operationally. For two vectors , consider the random linear combination for random . Each has an agreement domain — the set of coordinate subsets of relative size on which matches some codeword. The MCA property of at distance says: with high probability over , every agreement domain of the combination is contained in the intersection of the agreement domains of the individual ‘s. (This is the "" version; the paper states a -fold generalization.)
Operationally: if you take a random linear combination of purported codewords and it lands close to a codeword on some subset , then every individual purported codeword had to be close to a codeword on the same subset . The combination doesn’t gain agreement that wasn’t already there.
Theorem 3.4 (paper, paraphrased). Any linear code over any field — including — satisfies MCA up to the 1.5 Johnson bound , with error over the choice of random coefficients drawn from a finite subset . The proof for the finite-field case is from [Zei24]; the paper adapts it to linear codes over (Remark 2.16). We won’t reproduce the proof — see Zei24 for the original and paper §3.2 for the adaptation.
Why this matters operationally. In the Brakedown / Zip family, the IOPP’s per-query soundness error scales as , where is the number of columns the verifier opens. To hit bits of soundness, you need opens. Pushing from (unique decoding) up to (1.5 Johnson) directly reduces — fewer columns, smaller proofs, less verifier work. This is the “list-decoding regime” win.
The merging of test and evaluation phases is a downstream consequence: MCA’s “agreement doesn’t leak from combinations” property is exactly what lets a single random-combo step do both proximity testing and tensor-identity evaluation safely.
A caveat on what the implementation actually does. The paper is slightly self-contradictory on the benchmark parameters: §2.5 says the Table 4 numbers use rate at the 1.5 Johnson bound, while Remark 2.16 footnote 9 says “in our experiments we use a rate of and the Unique Decoding Radius, since in this parameter regime the UDR leads to better performance than the 1.5 Johnson bound.” Take the §2.5 statement as the headline (it’s the paragraph attached to Table 4) and the footnote as evidence that the MCA-bound vs UDR choice is workload-dependent — the implementation picks whichever wins for the configuration in front of it.
The Zip+ IOPP, in three layers
The Zip+ construction is layered: a non-projected scalar core, a polynomial-witness wrapper, and a projected-evaluation outer layer. We follow the paper’s §2.4 layering — it’s also how the implementation is organized.
Layer 1 — non-projected, scalar witness
Same shape as Zinc Part 2’s eval phase. The witness , the interleaved encoding , the constraint for and . Build the equality vectors
The MLE-evaluation constraint rewrites as the tensor constraint
Protocol: the prover sends claimed to equal . The verifier checks . If that passes, prover and verifier reduce the remaining claim (” is close to an encoding of some with ”) to a single proximity claim via the merged random-combo step — the same combination that tests codeword proximity also computes .
The adaptations. When , two things change.
(a) Projected check at the scalar level. The constraint form becomes in for a large random prime — exactly the Zinc-Part-1 random-prime trick, here at the inner-IOPP layer. The prover sends ; the check runs . The final proximity claim is still taken over — the random linear combination is analyzed over , which is what requires the MCA-for- result from Remark 2.16.
(b) Bit-size enforcement. Per Remark 2.17, the final move in any Brakedown-style IOPP over is the prover sending the random linear combination of witness rows, . If the honest prover’s witness has bit-size , then (a combination with -bit random coefficients) has bit-size , all polynomial in and . The verifier rejects if ‘s bit-size exceeds the threshold. Soundness against bit-size cheats then reduces to the Zinc-Part-2 lemma chain (Lemmas 2.4, 2.5 of that paper) on random linear combinations of large rationals — random combos of large entries stay large, random combos of fractions rarely collapse to integers.
Layer 2 — non-projected, polynomial witnesses
Now and have entries in , and the target also lives there. Split everything by -degree:
The polynomial constraint decomposes into independent scalar constraints over . Each fires a Layer-1 IOPP on . Standard random-linear-combination batching collapses the parallel proximity claims into one.
For commits, this is exactly the interleaved commitment from Part 1’s add-on path: a polynomial-witness commit is just scalar-witness commits, batched. When , this is the entire PCS story — any existing multilinear PCS, wrapped with the -layer interleaving, handles the Zinc+ add-on regime. No new code, no new lemmas.
Layer 3 — projected constraints
This is where Zip+ does new work. The PIOR delivers a claim of the form over a finite field , where is one of the projections from Part 1’s §2.2.1 — either (when ) or eval-at- (when ). Reduce to a Layer-2 non-projected claim.
Easy case: , evaluates at . The tensor reformulation lifts straight up: . The prover sends claimed equal to over , the verifier checks , and the remaining proximity-plus-tensor-constraint claim hands off to Layer 2. One non-projected polynomial IOPP, done.
Hard case: , with large. This case arises when the inner PIOP runs over a high-extension finite field — e.g., for arithmetizations that start over . The naive lift “evaluate at the lifted query point ” produces a result whose -degree is — prohibitive when is, say, and is .
The fix: lift only the equality vectors , not the witness. Reduce first to the tensor constraint over . Then take a fixed lift of — a section — and apply it coefficient-wise to to get with polynomial entries of -degree . The lifted tensor product over now has -degree — manageable for any reasonable and , not blown up by .
The prover then sends claimed equal to that lifted tensor product. The verifier checks over . If that passes, the residual claim is ” is close to an encoding of some with over ” — almost a Layer-2 claim, except the constraint vectors have polynomial entries of degree .
The second-prime detour. To avoid running scalar IOPPs to handle the polynomial constraint vectors, Zip+ projects once more. The verifier samples a fresh large random prime and a fresh random . The map first localizes coefficients to , then evaluates at . Replace the strict constraint
with its -image:
If the original held strictly, the projected version holds too. If the original failed, Schwartz–Zippel-plus-random-prime gives the standard soundness bound — negligible for . The honest prover’s witness has no entry whose denominator is divisible by by the same bit-size counting from Part 1, so well-definedness holds for free.
The residual claim ” is close to encoding of some with ” is now a Layer-2 polynomial-witness tensor constraint over (since still has polynomial entries in , of degree ) — handed off to the batched scalar IOPPs of Layer 2.
What the layers buy
The cleanest way to read the layering is degree on the constraint, not on the witness. Layer 1 handles scalar constraints with the merged Brakedown core. Layer 2 lifts to polynomial witnesses by paying a factor in scalar IOPPs (batched). Layer 3 absorbs the projection — easy when , requiring the second-prime trick when is a high-extension of a different characteristic.
The whole thing composes with the IPRS code as the underlying -linear code (or with any -linear code in the -only regime).
Soft range checks: bit-size at the commitment layer
Part 1’s PIOR assumed bit-size-bounded witnesses. Lemma 2.1’s random-prime soundness analysis required it. The PCS is what makes that assumption a guarantee.
Where the check lives. Per Remark 2.17 of the paper, every Brakedown-style IOPP over ends with the prover sending the random linear combination of witness rows, , which the verifier then encodes and checks against the committed via column opens. The bit-size check piggy-backs on :
- Honest case. Witness entries have bit-size . The combination uses -bit random coefficients across rows. Standard arithmetic: , so ‘s entries have bit-size . Verifier checks against this bound.
- Cheating case. If has entries of bit-size for some , the Zinc-Part-2 Lemmas 2.4–2.5 chain (random combinations of large rationals stay large with overwhelming probability) forces above the threshold too. Verifier rejects.
The completeness-soundness gap. Honest provers are guaranteed ; soundness only catches at . The slack is real — there’s a band in where the verifier can’t distinguish — but it’s harmless: the PIOR’s Lemma-2.1-style analysis only needed a bound, not a tight . Paper §2.4 footnote 8 makes this call explicitly: “it is enough for our compilation purposes to guarantee bit-size bound below , and not exactly below .” The constants get absorbed downstream.
Well-definedness. Runs the same way as Zinc Part 2’s bad-denominator branch. Honest prover’s witness has no entry whose denominator is divisible by the random prime — bit-size counting (Lemma 2.1) gives this with overwhelming probability. The oracle returns on ill-defined queries; the verifier rejects on any .
The upshot: the commitment scheme enforces typing. The narrower types — , , — are enforced by lookup constraints at the PIOP layer, exactly as in Part 1.
From IOPP to hash-only SNARK: BCS compilation
Stack so far: UCS arithmetization → three-step PIOR (Part 1) → Zip+ IOPP with IPRS codes (this article). Final arrow: from the interactive IOP to a hash-only non-interactive succinct argument. That’s done via the standard BCS-style compilation [BCS16] — Merkle-commit each oracle, answer queries via Merkle paths, Fiat–Shamir the verifier randomness from a transcript hash.
Zinc Part 2 stopped one step earlier. Its analog scheme iCOS delivered an interactive succinct argument because Zip’s soundness analysis was not round-by-round — proving the standard “this scheme survives Fiat-Shamir” lemma required a state-restoration soundness argument that the unique-decoding-regime analysis didn’t yield.
Zip+ proves round-by-round knowledge soundness. From paper §1.1: “We prove round-by-round knowledge soundness, allowing for Fiat-Shamir compilation.” The proof uses a recent definition from [BCFW25] that handles soundness in the list-decoding regime — the same regime that gives the smaller proofs. Past unique decoding, the standard knowledge-soundness extractor (find the unique nearby codeword, decode it) doesn’t apply; the BCFW25 framework provides the list-aware extractor.
The result: the Fiat-Shamir transform applies cleanly. The final SNARK is hash-only — no hidden-order groups, no trusted setup, plausibly post-quantum (modulo the standard ROM-vs-QROM caveats for hash-based schemes). Proof size and verifier time match what the IOPP reports, plus Merkle-path overhead.
We won’t reproduce the BCS construction here — see BCS16 for the canonical version, and Zinc Part 2’s §Compilation for the iCOS predecessor and the gap that Zip+‘s RBR-KS analysis closes.
What this buys: the benchmark
End-to-end on MacBook Air M4, 100 bits of security, 7 SHA-256 compressions followed by the multi-scalar-multiplication portion of ECDSA verification:
| Component | Prover | Verifier | Proof size |
|---|---|---|---|
| Zip+ IOPP — commit | 8.4 ms | — | — |
| Zip+ IOPP — open | 4.7 ms | 4.2 ms | 0.06 KB |
| Zip+ IOPP subtotal | 13.1 ms | 4.2 ms | 162 KB |
| Zinc+ PIOR (ring proj, ideal batch, eval proj) | 5.5 ms | 0.2 ms | 9 KB |
| Finite-field PIOP (HyperPlonk-like) | 21.4 ms | 2.0 ms | 27 KB |
| zstd-3 compression | 0.6 ms | 0.6 ms | — |
| Total | 40.6 ms | 7.0 ms | 198 KB |
A few things worth pulling out:
- The PIOR is cheap. Steps 1–3 from Part 1 take ms — about of prover time. Most of the work is the inner finite-field PIOP ( ms) and the Zip+ commit/open ( ms).
- Proof size is dominated by Zip+ ( KB out of KB total). The paper notes this is inherent to Brakedown/Ligero-style PCSs; ongoing work on a WHIR-based [ACFY25b] replacement is expected to compress this substantially.
- The implementation is suboptimal on purpose. Paper line 1766: it arithmetizes entirely over , not the optimal mix from §8. So these numbers are pessimistic — multi-domain support is on the roadmap.
- Parameters. IPRS code with rate , radix , base field of size . Random prime is bits. Proximity parameter set to the 1.5 Johnson bound. (Paper Remark 2.16 footnote 9 notes that at the alternative rate , the UDR empirically outperforms the 1.5 Johnson bound — workload-dependent.)
What we didn’t cover
A few load-bearing pieces deferred for length:
- Full MCA-to-RBR-KS reduction (paper §3.2 + Appendix A.2). The list-aware knowledge extractor that BCFW25 provides, and its instantiation for the Zip+ IOPP.
- General-radix IPRS encoder and full distance proof (paper §7). Above we fixed radix- for the explanation; the implementation uses radix- for performance.
- Full Zip+ IOPP construction with all batching wrappers (paper §6). The §2.4 sketch we followed gives the conceptual structure; the implementation layers in column batching, query batching, and merged Merkle-path verification.
- Qāren [SSPP26]. Concurrent work compiling any multilinear PCS to a relaxed mod-PCS over . The paper flags it as a possibly-better fit for committing vectors (the SHA-256 use case), but defers the integration.
- The -only “Zinc+ add-on” PCS path. Covered in Part 1 — any existing multilinear PCS wrapped with interleaved commits handles it. No new PCS needed.
Conclusion
The core ideas, in order:
- Zip+ implements the projected-oracle interface that Part 1’s PIOR left as a contract — proximity, bit-size enforcement, and well-definedness under , all at the commitment layer.
- Three deltas vs. Zip: list-decoding regime via MCA (smaller proofs), merged test + evaluation phase (one round less), IPRS codes instead of JEA (MDS distance + FFT encoding + bounded norms simultaneously).
- IPRS — lift the FFT, not the polynomial. Throwing away the polynomial-evaluation semantics of RS while keeping the FFT algorithmic structure resolves the distance/encoding/norm trilemma that has blocked code-based PCSs over .
- MCA + round-by-round knowledge soundness unblocks Fiat-Shamir. Zinc Part 2’s iCOS stopped at interactive succinctness because the unique-decoding analysis didn’t survive state-restoration; Zip+‘s RBR-KS proof in the list-decoding regime is what makes BCS compilation kosher.
- Soft range checks fold into the existing random-linear-combo step. Bit-size enforcement piggy-backs on the prover’s final message; the -vs- completeness-soundness gap is real but absorbed downstream.
The result is the first hash-only SNARK with native integer + bitwise arithmetization, no hidden-order groups, plausibly post-quantum, delivering 7 SHA-256 compressions + ECDSA MSM at ms prover / ms verifier / KB proof on a laptop. End-to-end, with measured benchmarks.
What’s next: IPRS-MCA at the standard Johnson bound (open in the paper, would directly tighten proofs); a WHIR-based replacement for the Brakedown-flavored proof-size term; integration with Qāren for commits.
References
- Zinc+: SNARKs for Polynomial Rings. Alexander Abdugafarov, Albert Garreta, Amit Kumar, Michał Osadnik, Psi Vesely, Ilia Vlasov, Kai Zhe Zheng. Nethermind Research et al., May 2026. PDF
- Zinc+ Part 1. Walkthrough on this blog.
- Zinc Part 1, Part 2. Walkthroughs on this blog.
- Brakedown. Golovnev, Lee, Setty, Thaler, Wahby. CRYPTO 2023.
- Field-Agnostic SNARKs from Expand-Accumulate Codes ([BFKTWZ24], the source of JEA-style constructions). Block, Fang, Katz, Thaler, Waldner, Zhang. CRYPTO 2024.
- Khatam: Reducing the Communication Complexity of Code-Based SNARKs ([Zei24]). Zeilberger 2024 — MCA / 1.5 Johnson bound for linear codes; generalized to -codes in this paper’s §3.2. ePrint 2024/1843
- Linear-Time Accumulation Schemes ([BCFW25]). Bünz, Chiesa, Fenzi, Wang. TCC 2025 — provides the round-by-round knowledge soundness framework Zip+ uses in the list-decoding regime.
- Interactive Oracle Proofs ([BCS16]). Ben-Sasson, Chiesa, Spooner. TCC 2016-B — the BCS-style compilation from IOPs to hash-only succinct arguments.
- WHIR ([ACFY25b]). Arnon, Chiesa, Fenzi, Yogev 2025 — the proof-size successor that ongoing Zinc+ work is targeting.
- Relaxed Modular PCS ([SSPP26]). Shirzad, Sridhar, Papadopoulos, Papamanthou 2026 — concurrent work compiling any multilinear PCS to a relaxed mod-PCS over . ePrint 2026/347
- Binius. Diamond, Posen. 2024–2025 — binary-field SNARKs, the comparison point for bitwise arithmetization.