Synthesis — Cryptography

The evolving thesis. Spun out of the hub _inbox on 2026-08-15 from three sources, each of which had been declined by every existing spoke with the same one-line finding: no spoke owns cryptography. diamond-io was parked on 2026-07-28, binius earlier the same day as the split, and flock arrived minutes later and completed the cluster.

Current thesis

The subject is not whether a scheme works but what it costs to run. All three founding sources are about the same distance — between a construction that exists and one anybody can use — and they differ only in how far along it they stand. concrete-efficiency holds the axis: diamond-io is arguing about the gap between "longer than the universe" and "merely infeasible," while binius and flock are arguing about a factor of nine on a laptop. That is one question at three magnitudes, and it is why this spoke exists rather than a "proof systems" one.

Every result is a trade, and the trade is the finding. binius proves and verifies faster than Plonky3 and pays with a 5.574 MiB proof against 4.010 MiB. flock ships fast and slim variants and lets the caller choose. diamond-io buys planetary runtime with assumptions its own summarizer calls novel and risky. A headline number with no stated cost is an incomplete claim here, and reading one starts with asking what it spent.

Speed comes from shrinking the problem, not from working harder on it. binary-fields shrink the element — stop paying to carry one bit inside a 256-bit group. Batching shrinks the protocol — flock proves many copies of one Boolean circuit and thereby avoids the permutation and memory-checking arguments that only general circuits need. In both cases the overhead removed was structural, present because the framework was built for something more general than the workload people actually run.

The prover is the bottleneck, and it is the only part recursion cannot fix. Proof size and verification time can be repaired after the fact by proving a verification; prover time cannot. General zkVM provers run four to six orders of magnitude slower than native execution, and both proof-system papers spend their whole optimization budget there.

One workload is driving all of it. Hashing in bulk — SHA-256, Keccak, BLAKE3 — for rollups and for post-quantum signatures. It is why binary fields became interesting, why batch proving is worth specializing for, and why the numbers are quoted in hashes per second. The application chose the mathematics.

The corpus's first non-proof-system source arrived 2026-09-28 and it is still, in its own way, about the same axis. polyxor128 is a keyed universal hash, not a SNARK — nobody is proving a computation ran correctly, nobody is hiding a program. But its speed comes from the identical move binary-fields already names: carryless multiplication, ordinary multiplication over GF(2)[x], run on the same instructions this spoke's proof-system sources use for polynomial commitment. It also extends the concrete-efficiency trade pattern into a new register: it trades a formally proven collision bound against zero third-party cryptanalysis, which is a different kind of unfinished confidence than "nobody has independently reproduced the benchmark."

The founding disagreement

Are tower fields worth it? binius puts towers in its title and builds its construction on them. flock, in the same family and also over binary fields, identifies challenge points that work without them, calling tower fields "less efficient than direct extensions of F₂," and uses F₂¹²⁸ throughout. Neither paper isolates the question with a benchmark, so this is a stated disagreement rather than a settled one. Both claims stay on binary-fields per the hub's record-don't-overwrite rule.

Open questions

• Is any of it independently reproduced? Every number here was produced by the authors of the system being measured. flock does the available honest things — each system benchmarked at its own peak batch size, ARM's SHA-256/SHA3 instructions disabled so the native baseline is like-for-like — and it is still self-measurement. No third party has re-run anything in this corpus.
• What happens between the two magnitudes? The corpus has schemes that are infeasible by orders of magnitude and schemes that run in milliseconds, and nothing in between. The interesting cases are presumably the ones currently crossing over, and none is held here.
• How much of the speed is the machine? flock states it was tuned for Apple ARM specifically and expects the optimizations to carry to other architectures. Nobody has checked. A prover result on one laptop generation is a narrower claim than it looks.
• What did the coding agents actually do? flock's abstract says the implementation was "co-designed by coding agents" and the limitations section calls it heavily AI-assisted. No detail, no hand-written baseline, no comparison. As evidence about agent capability it is currently a sentence, not a result — but it is a sentence in the abstract of a state-of-the-art performance paper. ../agentic-tooling-wiki owns that question; this spoke owns the proof system.
• Does zero-knowledge cost anything? flock offers succinctness without zero-knowledge and expects the property could be added "at a relatively low cost." Nothing here measures that, and privacy is the half of this field the founding corpus does not touch at all.
• Does a machine-checked proof substitute for independent cryptanalysis? polyxor128's collision bound is formalized in Lean, but the author states plainly that they checked the definitions and the final claim, not the proof steps connecting them, and the construction itself has had no third-party review. A proof that type-checks against definitions nobody outside the project has audited is a narrower guarantee than it first sounds like, and this spoke has no other source that raises the question in this specific form (formal verification of a construction, as against reproduction of a benchmark).

Growth edges

Ranked; each names the kind of source that would close it (see ../QUALITY.md → Growth edges).

1. Nothing is independently measured. Three sources, three sets of author-run benchmarks. — needs: a third-party evaluation, a reproduction study, or a standardized proving benchmark run by someone with nothing in the race. HALF CLOSED 2026-08-20 (research pass) by zk-bench (T1, SCN 2024): a standardized framework run by academics with no prover in the comparison, over 13 curves, 9 arithmetic libraries, 5 SNARK tools and 5 named AWS instance types — and its opening line is this spoke's tension verbatim, "claimed results are generated in isolation, and omissions in details render them irreproducible." It answers the question in principle and not for the systems held here: its tools are Bellman, halo2, gnark, Circom and Starky, a generation before binius and flock, with no binary-field system in it. Needs now: a third party running binius against flock, or either against Plonky3, on stated hardware. Hunted again 2026-10-04 (Most wanted #36), nothing at the bar. The nearest source is still BinarySpartan (Setty, ePrint 2026/1656; see contract-validated-zk-bench). Its PDF now returns a Cloudflare challenge (HTTP 403) to every fetch tried, so the body is still unread. An unsigned HackMD summary of it states what the abstract does not: an M4 Max with 12 cores, no GPU; Binius64 and Plonky3 at about 52k and 54k BLAKE3 proofs/s at peak; and baselines "as pinned and configured by Flock's own harness". If the paper confirms that last point, the one run holding both Binius64 and Plonky3 uses configurations chosen by a third competitor, flock. That is not the neutral run this edge asks for. Nothing from the summary goes onto a page until the paper is read. Plonky3 has also started shipping its own binary-field prover (GF(2^64) values, GF(2^192) challenges, per its own pull requests), so the old "binary field vs Plonky3" split is starting to blur.
2. No primary source for the lattice corner. indistinguishability-obfuscation rests entirely on a T2 explainer; the diamond iO paper itself is not held. — needs: the paper, or a survey of evasive LWE and its status.
3. The whole spoke is a performance corpus. Nothing here is about breaking anything — cryptanalysis, attacks, parameter selection, or the process by which an assumption loses trust. That is half the discipline. — needs: an attack paper, a cryptanalysis survey, or a post-mortem of a broken assumption.
4. No standards or deployed-system layer. AES, SHA-3 and the NIST post-quantum selections are named in passing and paged nowhere. The corpus is three research artifacts and no infrastructure. — needs: a specification, or a documented migration in a system people run.
5. Privacy is absent. "Zero-knowledge" appears here mainly as a property flock does not implement. Nothing covers the actual privacy constructions this vocabulary comes from. — needs: a source where hiding the witness is the point.

Contradictions / tensions

Beyond the tower-fields disagreement above, the tension worth watching is whose claims these are. This is a field where the sources are the builders: irreducible wrote the system that flock beats, and flock's authors sit at NYU, Succinct and Espresso Systems — organizations with a stake in fast proving. That does not make the numbers wrong, and each paper is careful in the ways available to it. It does mean the corpus currently records a competition as reported by its competitors, which is a different epistemic object from a measured field.

Updated 2026-08-20. zk-bench is the first source here that is not a competitor, and it sharpens the complaint into something specific. The problem is not that builders shade their numbers; it is that a prover timing does not identify a system. On zk-Bench's own measurements the arithmetic library underneath moves SHA-256 proving by 14.02× (gnark against snarkjs, same circuit, same curve), the circuit implementation reverses a tool's ranking between two test vectors, and the AWS instance type is worth 40–50% by itself. binius's reported margin over Plonky3 is 2.3×. Every cross-source comparison this wiki has drawn sits inside a confounder larger than the effect, and the fix is not more benchmarks from builders but a stated backend and instance alongside every number.

The second tension is between diamond-io's argument that analyzability is a security property — no towers of protocols inside protocols, so a reader can follow it without twenty years of background — and the direction of the proof-system work, where each paper stacks more optimizations onto the last (univariate skip, deterministic challenges, deferred reduction, ring-switching, list-decoding). Both are reasonable and they pull opposite ways. Nobody in the corpus argues the point across that line.

Cross-spoke adjacency

• ../mathematics-wiki — finite fields, Reed–Solomon codes, proximity gaps. Theory taught from first principles routes there; a construction with a benchmark routes here. The closest boundary in the hub.
• ../research-wiki — homonym. Theorem proving is deductive, machine-checked proof; a SNARK is a probabilistic argument about an execution. Never merge on the words "prover" and "proof."
• ../bit-manipulation-wiki — F₂ addition is XOR and binary multiplication is what carryless multiply instructions exist for; instruction-level technique is theirs, the algebra and the scheme are here. polyxor128 (2026-09-28) is the boundary in practice: its SIMD carryless-multiply dispatch is their territory, its universal-hash construction and proven collision bound are this spoke's, and it was routed here on that split, with ../bit-manipulation-wiki logged as runner-up and given no page.
• ../defensive-security-wiki — blue-team practice. A CVE in an implementation is theirs; a scheme's security argument is ours.
• ../agentic-tooling-wiki — flock's agent-built implementation. The claim about agents cross-links there.
• Blockchain has no spoke. Ethereum and Bitcoin appear throughout because they pay for fast provers. If that body grows it wants its own home, not this one's second half.

Index — Cryptography Wiki

Catalog of every page, grouped by schema.org @type. Spine: synthesis (thesis), log.md (history), this file (catalog). Spun out of the hub _inbox on 2026-08-15 (3 sources). Every performance number here is author-run on hardware the authors chose. Record the machine.

DefinedTerm (concepts)

• concrete-efficiency — the spoke's through-line: the distance between a scheme that exists and one that runs; why every gain is a trade (prover time ↔ proof size ↔ generality ↔ safety), and why speed comes from shrinking the problem rather than working harder on it · through-line
• succinct-argument — SNARK: a short certificate that a computation ran correctly, checkable far faster than re-running it; the PIOP + polynomial-commitment framework, curve-based vs hash/code-based families, and why the prover is the only bottleneck recursion cannot fix. Not theorem proving · primitive
• binary-fields — F₂ and its extensions: addition is XOR, squaring is cheap, elements are bit strings; why bit-heavy hashing made them the endpoint of the shrinking-field trend, and the live tower-vs-direct-extension disagreement · mathematical-structure
• indistinguishability-obfuscation — iO: encrypting a program so it runs on plaintext without revealing its logic; galactic runtime as the standing blocker, lattice assumptions as the price of improving it, and analyzability argued as a security property · primitive
• universal-hash — keyed hash families with a provable collision bound over the choice of key (Carter–Wegman); the NH/CLHASH/UMAC lineage, and how re-keying a hash output turns it into a MAC · primitive

ScholarlyArticle (sources)

• flock — Bünz, Rothblum & Wang (NYU / Succinct / Espresso), arXiv 2607.27491, 2026-07-29: a hash-based post-quantum SNARK for batches of one Boolean circuit. ≈250× native overhead; 42.1k SHA-256 and 30.7k Keccak-f per second on one M4 Max core, 661k BLAKE3/s on ten; ~9× Binius64 on SHA-256, 14× on BLAKE3. 100-bit soundness, proofs under 450 KB. Prototype only, no zero-knowledge yet, tuned for Apple ARM, implementation "co-designed by coding agents" · source · T1 · arxiv.org
• zk-bench — Ernstberger, Chaliasos, Kadianakis, Jovanovic, Orrù, Livshits, Gervais & Steinhorst (TUM / Imperial / UCL / Ethereum Foundation / CNRS), ePrint 2023/1503, SCN 2024: the spoke's first benchmark run by nobody in the race. 13 curves × 9 arithmetic libraries, 5 SNARK tools, 5 named AWS instance types. The substrate dominates the scheme — gnark proves SHA-256 14.02× faster than snarkjs on the same circuit and curve; halo2 is 8.64× slower than gnark on one test vector and 1.09× faster on another; hardware alone moves proving 40–50%. Predates binius and flock · source · T1 · eprint.iacr.org
• binius — Diamond & Posen (Irreducible), IACR ePrint 2023/1784: a SNARK over towers of binary fields down to F₂, with no embedding overhead — Brakedown adapted via block-level encoding, plus binary-field ports of HyperPlonk's checks and Lasso's lookup. 8,192 Keccak-f in 5.90 s against Plonky3's 13.8 s, bought with a larger proof (5.574 vs 4.010 MiB). Target: Keccak proofs for Ethereum rollups · source · T1 · eprint.iacr.org
• contract-validated-zk-bench — Hulek, Peresini & Homoliak (Brno University of Technology), ePrint 2026/1729. Eight systems (Groth16, ICICLE, Halo2, Plonky3, Winterfell, Nova, RISC Zero, SP1) on 8 CPU cores plus CUDA, compared through workload-specific semantic contracts so systems answer the same declared public claim even when their circuits differ. Plonky3 and Winterfell smallest proving time and RAM; Groth16 and ICICLE sub-kilobyte proofs; zkVMs trade proof size and memory for programmability. Still no Binius, still no Flock · source · T1 · eprint.iacr.org

BlogPosting (sources)

• diamond-io — Buterin on diamond iO (2026-07-28): trades safety for speed to reach "planetary, rather than galactic runtime — still infeasible today"; modifies BGG+14 ABE, rests on evasive LWE (non-falsifiable in Naor's sense) and all-product LWE, and argues its real advantage is being analyzable at all · source · T2 · vitalik.eth.limo

SoftwareSourceCode (sources)

• polyxor128 — Orson Peters (orlp), 2026: a keyed 128-bit universal hash in Rust for fast file/stream integrity checks. Collision bound (n/4096+3)/2¹²⁸, formalized and Lean-proved (LLM-written proof, author-checked definitions and final claim but not the proof steps). Up to 130 GB/s on a Ryzen 9950X, 60 GB/s on an M2 Pro (self-reported); finalize_mac builds an AES-based MAC for untrusted channels. No third-party cryptanalysis yet. The spoke's first non-proof-system, non-iO source · source · T1 · github.com

Organization (entities)

• irreducible — the company behind Binius; publishes and ships the implementation, and supplies the Binius64 baseline every other system quotes · vendor · thin node

Person (entities)

• vitalik-buterin — appears twice over and in two roles: author of the iO explainer held here, and a target number — flock measures itself against his 200k-hashes/second estimate for Ethereum's post-quantum transition · author · thin node
• orson-peters — author of polyxor128; better known outside this spoke for pdqsort (default unstable sort in Rust and Go) and an earlier universal hash, polymur-hash · author · thin node

Synthesis

• synthesis — the thesis: the subject is what a scheme costs to run, not whether it works; one question at three magnitudes

Notes

• Founding weakness, stated up front: all three sources are the builders reporting on their own constructions, and nothing has been independently reproduced. The corpus records a competition as described by its competitors. Growth edge 1.
• Entity nodes deferred at founding — Benjamin Diamond, Jim Posen, Benedikt Bünz, Ron Rothblum and William Wang are named in prose but not paged; NYU, Succinct and Espresso Systems likewise. Page one when it recurs or a query needs it.
• Half the discipline is missing by construction. This is a performance corpus: nothing here is about breaking a scheme (cryptanalysis, attacks, parameter choice) and nothing is about privacy. Growth edges 3 and 5.