Ethproofs

Introducing the definitive guide to ZK in 2026. The year’s biggest questions pointed to ZK: Can we trust AI? Will quantum break encryption? Can private money live on public rails? How do we know what’s real online? Read how in the 2026 ZK Industry Report with @zeroknowledgefm.

ZisK v1.1.0-alpha release 🚀 Ethereum proven in real time on 4x5090 GPUs with a p99 of 9.62s. All providing 128-bit provable security, powered by Poseidon1, and post-quantum secure. This release pushes the prover further and fixes bugs, without trading soundness for benchmarks. Release notes: github.com/0xPolygonHermez/z…

Goodbye, Poseidon! An epic 8-year, 8-figure rabbit hole in post-quantum cryptography reaches its dream conclusion. The Ethereum Foundation is abandoning Poseidon for L1, pivoting to SHA or BLAKE. This milestone unlocks ultimate security for lean Ethereum and foreshadows a golden era of hash-based cryptography. Since 2018, the Ethereum Foundation has invested in magic cryptographic bricks, so-called "SNARK-friendly hashes". In 2019, Poseidon was born. It held strong and became the dominant SNARK-friendly hash, securing billions via zkrollups and zkVMs. In a stunning reversal, breakthrough SNARK designs show that SNARK-friendly hashes aren't necessary after all. Off-the-shelf traditional hash functions like SHA2 and BLAKE2s can now match Poseidon in a SNARK. In hindsight the key was not SNARK-friendly hashes, but hash-friendly SNARKs. The secret is doing maths over the smallest prime number: 2. So-called "binary fields" natively speak the language of bits, aligning with the boolean operations inside traditional hashes. This is a stark departure from "prime fields", where awkward large-prime arithmetic makes bit manipulation painfully expensive. We're talking sci-fi cryptography. 1M traditional hash calls proven per second, on a laptop. Just 100x overhead vs native CPU boolean compute. Nobody predicted such performance, not even the handful of binary-field visionaries. Hat tip to the research geniuses: Jim and Ben with Binius in 2023; Ron, Benedikt and William with Flock in June. With SHA2, the lean aesthetic of minimal assumptions reaches its climax. The EF's principled stance on pure hash-based cryptography has aged like fine wine. We now enjoy foundations the world can trust for decades and centuries, foundations worthy of the dream of an internet of value. Speed of deployment is a secondary win. There's no longer a need to wait years for Poseidon cryptanalysis to bake. Emile and Thomas from the EF post-quantum team are moving at breakneck speed with binary fields. The strawmap now points to a production-grade leanVM in 2027, with CL, DL, EL deployments in 2028. As AI becomes exceptional at cryptanalysis, the contrarian bet to avoid riskier structures like lattices and isogenies is visibly paying off. The past weeks have been brutal. Lattice-based "HAWK" and isogeny-based "SQIsign", both signature schemes in NIST's Round 3, have suffered blows. Sources I trust say more blood is coming. On AI, the open autoresearch trend kicked off by ECDSA[.]fail is spreading fast, with amazing outcomes from zk[.]golf and SNARK[.]fast. Days ago SNARK[.]fast crossed 1.8M BLAKE3/sec proven on an M3 Max. Stay tuned for fresh autoresearch challenges dropping tomorrow. Also tomorrow: Ethproofs call #10, dedicated to binary fields. Possibly the most noteworthy Ethproofs call yet. Experts leading the charge will present the future of hash-based SNARKs at 2pm UTC. What an incredible time to be alive. To witness history, DM me for a calendar invite :) Today I can confidently claim that hash-based cryptography has won out for blockchain post-quantum signatures. SNARK succinctness compresses arbitrarily many signatures into one small proof per block. SNARK flexibility yields k-of-n threshold signatures, complex multisigs, and more. Ultimate security. Uncompromising performance. Full programmability. Believe in something. Believe in hashes.

If proving becomes part of Ethereum’s core infrastructure, it cannot live only in the cloud. It has to work on machines people actually own, under real-world constraints. Today, Ethproofs is launching a pilot to test exactly that. We’re funding 4 prover teams to run on-prem multi-GPU rigs and prove 1-in-10 Ethereum L1 blocks on Ethproofs. The goal is simple: encourage more production-grade proving in the wild. This first cohort is a pilot, not a closed club. We are ready to scale. We’re also updating the $300K RTP grants. They are separate from this pilot and open to any team that meets the criteria. Read about all the details here 👇

that was quite the @eth_proofs call 😁

A couple shots 📸 of our CSO Alan presenting Pico Prism 2.0 at @eth_proofs BEAST MODE in Cannes. ⭐️The highlights: a new worker-coordinator architecture that cuts GPU requirements from 64 to 16, rewritten GPU code with expanded RISC-V 64IM support, and 33% more workload capacity in the same proving time. Open sourcing soon. More results coming.

Time for BEAST mode: the future of @leanEthereum execution. Look for the @class_lambda and @alignedlayer teams

See you there. One if not the most important event in @EthCC with BEAST MODE @eth_proofs day.

1/ The Roadmap to Lean Ethereum: Scaling, PQ Security, and Networking. How does Ethereum integrate PQ signatures and SNARK aggregation into real-world clients? Let's break down the latest discussion between @raulvk, @corcoranwill and @nico_mnbl for @zeroknowledgefm. 🧵

New EIP! EVMification 🔗 github.com/ethereum/EIPs/pul… Highlights: - Replaces five specific precompiles—RIPEMD-160 (0x03), MODEXP (0x05), BLAKE2f (0x09), BLS12 map-to-G1 (0x10), and BLS12 map-to-G2 (0x11)—by deploying equivalent EVM bytecode at the same addresses at fork activation time. - After activation, those addresses must no longer be treated as precompiles; they become regular accounts with code, preserving the call interface and maintaining backward compatibility at the address level. - Primary motivation is reducing protocol/client maintenance burden and lowering consensus/implementation risk, while also making zkEVM implementations easier by avoiding multiple bespoke non-EVM “native” circuits/implementations. - The proposal explicitly accepts gas-cost changes: calls will be priced by standard EVM opcode execution rather than legacy precompile gas formulas, which may increase costs (notably for large MODEXP inputs) and can break contracts that hardcode gas stipends. - Usage analysis in the rationale motivates selection: RIPEMD-160 has minimal on-chain use; MODEXP usage is overwhelmingly for 256-bit modulus SNARK verification rather than RSA; BLAKE2f is reportedly mostly used by a single contract; BLS12 map operations are pure field arithmetic suitable for EVM implementation. ELI5: Ethereum has a few special “built-in shortcuts” (called precompiles) at fixed addresses that do certain math/crypto tasks. This proposal says: instead of having clients treat those addresses as special forever, we should put normal EVM smart-contract code at those same addresses that does the same job. That way, everything still works the same for contracts calling them, but Ethereum clients (and zkEVMs) don’t need custom implementations for each shortcut—just the EVM.

Here is our proposal to make end-to-end formally verified zkEVMs for the next version of Ethereum. Gain Between 2x and 4x more TPS (more at the end), unlocking a huge utility increase. 🏁 Why? End-to-end formal verification is needed as security issues in ZK proofs are hard to track and can be catastrophic given the value at stake (several billion dollars on the Ethereum mainnet). Scope The EVM implementations, like Revm, with a correctness proof down to the RISC-V compiled assembly code of the interpreters. We do not cover the formal verification of the circuits and cryptographic primitives here. What exists For now, there is a verified translation from the core of the Revm implementation to the formal language Rocq through "rocq-of-rust" (our work), and a compilation pipeline, Peregrine, built on top of CompCert, to compile an EVM interpreter in Rocq to RISC-V in a formally verified way. These projects are either done or in active progress. Limitations The main limitations of relying on an EVM written in Rocq (or any formal language) are: - Speed. This is hard to beat an imperative language like Rust with a mature optimizing toolchain like LLVM. - Diversity. Leveraging existing EVM interpreters brings battle-tested solutions and enhances security through implementation diversity. Proposition Making a pipeline to compile (a subset of) Rust programs down to assembly code. This is a huge project. We also need to be able to reason on the semantics of Rust that we compile to show it is equivalent to other EVM implementations (something that "rocq-of-rust" provides for some parts). There are some ingredients to make it manageable, including AI, certifying compilation rather than certified compilation, and using a simpler Rust backend than LLVM to start with, such as CompCert. Computing the gains We estimate that, compared to an EVM implementation in a formal language (Rocq or Lean), switching to a language with explicit memory management, such as Rust, should yield a 2x performance improvement. Going all the way with LLVM verification, we get an additional 2x compared to using optimization in the formally verified C compiler CompCert. So, there is between 2x and 4x improvement based on these estimates. We assume there needs to be at least one zkVM that is formally verified end-to-end to validate each block. Thanks for reading through. Happy to discuss or collaborate on this project! 🚀