Ethereum pivots from Poseidon to SHA and BLAKE

On Aug. 13, Justin Drake announced the Ethereum Foundation will prefer SHA or BLAKE hashes in future layer‑1 designs rather than relying on Poseidon. The foundation said Poseidon has not been broken, no migration order will be issued and no fork is planned. The change applies to future protocol design work and does not require immediate changes to wallets, rollups or existing zkVMs.

The decision follows recent advances in binary‑field proof systems that make bitwise operations cheaper to prove. Poseidon was developed to reduce the proving cost of hashes inside SNARKs by matching the algebra used in many proof systems. New binary‑field constructions handle binary operations more naturally, narrowing or eliminating the proving penalty that once favored Poseidon.

SNARKs create compact cryptographic proofs that a computation was performed correctly. Many conventional SNARK implementations use arithmetic over large prime fields, where bitwise operations behind hashes such as SHA‑256 and Keccak were historically expensive to represent and prove. Poseidon was designed to avoid those costs by using algebra that fits prime‑field proofs.

Two recent research papers prompted the reassessment. One introduces a binary‑field construction that aligns closely with bitwise operations. A second paper, posted July 29, applied batching techniques to standard hashes and published benchmarks on commodity hardware.

The benchmarks report that a single M4 Max core can prove about 82,000 BLAKE3 compression evaluations, 42,000 SHA‑256 compressions and 30,000 Keccak permutations per second. Using ten cores, the authors recorded more than 660,000 BLAKE3 compressions per second. The paper also reported SHA‑256 proving more than nine times faster than an earlier comparison. Those figures count internal hash operations inside the proof system; end‑to‑end transaction throughput and production numbers will vary by implementation.

The Foundation links the hash discussion to Ethereum’s post‑quantum and simplification plans. The security roadmap calls for replacing validator BLS signatures with hash‑based leanXMSS signatures and then using a leanVM to aggregate the larger post‑quantum signature data into compact proofs. Lower proving costs for conventional hashes reduce the burden of proving the bitwise computations that leanXMSS and related components produce.

Drake’s personal timeline places a production‑grade leanVM around 2027 and wider use across consensus, data and execution layers in 2028. Ethereum’s official post‑quantum roadmap gives a nonbinding target near 2029 for core infrastructure work and schedules full execution‑layer migration later. The foundation has advised users to keep wallets unchanged for now.

Poseidon remains available as a cryptographic option and can still offer proving advantages in some settings. The current decision sets default hash choices for a potential future L1 that will rely heavily on large, proof‑driven constructions. Protocol developers will consider the new proof performance data, the public review history of candidate hashes and the needs of the post‑quantum migration when updating design plans.