Introduction
With the emergence of Flock as a PQ proof system for binary circuits (esp. hashes), Ethereum no longer requires specific circuit-friendly hashes for protocols whose computation would be proven. Still, the question of which hash function to choose is non-trivial, as they all have advantages and disadvantages in the context of the Ethereum protocol.
Usage
Use cases
We restrict ourselves to the cases of massive usage of a hash function:
-
Consensus layer (CL) signatures (an XMSS variant). Here a few hundred hash calls are needed to both sign and verify a signature. The setup has significant additional cost, roughly proportional to the (sign+verify)*(number of signatures).
-
Aggregation of CL signatures with a PQ proof system (currently a variant of LeanVM). A PQ hash-based proof of aggregation requires Merkle-tree hashing of messages whose total size is at least the size of the computation trace, and its verification requires checking dozens of Merkle paths from those trees.
 -
Building the state tree at the execution layer (EL) and providing proofs of tree transition for block verification (both natively and inside a zkVM). This needs a huge Merkle tree (or its variant), with current implementation using Keccak (a variant of SHA-3).
 -
EL signatures. One of the PQ signature options is a hash-based signature such as SPHINCS+. Being stateless, it requires far more hash function calls than CL’s XMSS, but the number of signatures per block is expected to be smaller.
- EL aggregation: proving the execution of Ethereum blocks, including verification of EL signatures, using some zkVM. The latter is supposed to use a hash-based proof system, similar to LeanVM. Such proof systems are supposed to use recursion, so that the same hash function is both used within a commitment scheme and proven within a collection of Merkle paths.
Input lengths
It is worth mentioning early on that all candidate hash functions work iteratively.
Figure 3: Iterative hash function (padding scheme of SHA-256).
Concretely, they first pad the input so that it becomes an integer number of chunks, and then compress it chunk by chunk. From the performance perspective, only the number of chunks matters rather than the number of bytes, both in native and in circuit computation. As the padding rules and the chunk size differ for each hash, it is crucial to identify the expected message byte length in order to estimate the performance of each hash function. In turn, the message length is determined by the outer protocol, and may include the digest length of the hash function itself if the hash function output also becomes an input.
Figure 4: Number of compression calls as a function of message length for SHA-256.
Here is a breakdown of message lengths for each case:
- Hash function calls in XMSS CL signatures use n+k bytes for WOTS chains and 2n+k bytes for the Merkle tree, where n is 16 assuming 128-bit digests (which is a reasonable choice assuming a ROM-based XMSS security proof) and k is 22-23 bytes: a 16-byte public parameter plus a 7-byte chain tweak (separator, 32-bit epoch, chain index, position in chain) or a 6-byte tree tweak (separator, level, 32-bit position), following the reference hash-sig implementation. The inputs are thus 39 and 54 bytes long, respectively, and both cases occur almost equally often.
- PQ proof systems (both LeanVM and zkVMs) take long messages (hundreds of bytes to several KB) for Merkle tree leaves, whereas the inner tree nodes universally map 32 bytes to 16 bytes.
- Similarly, for the state tree the leaves take an arbitrary size (typically more than 32 bytes), whereas the inner tree nodes are always 32-to-16-byte mappings.
- SPHINCS+ exists in several variants, and one of the most appealing deals with 16-byte digests, whereas hash function inputs in WOTS and FORS subtrees take between 16 and 64 bytes (but usually less than that).
Requirements
Security
The cryptographic security of a hash function comprises two parts:
- Security of the inner component – a permutation (SHA-3), a blockcipher (BLAKE2) or a compression function (SHA-2). For each option we require that the component has the same security against basic attacks (CICO problem, key recovery, collision/preimage search, respectively) as random functions/permutations against adversaries bounded by 2^{\lambda}. This is almost never proven formally, but argued via public scrutiny: if no cryptanalyst has found an attack for some time, we hope it is secure.
- Security of the hash function as a mode of operation that uses the inner component as a blackbox. This part can be provably secure; it means that assuming ideal behaviour of the inner component (argued heuristically as above) we prove that the full construction is ideal (this is called an indifferentiability proof) or that the full construction is resistant against some class of attacks.
Native performance
All the use cases listed above assume a quite high workload for hash functions, but fortunately all major candidates are fast enough that hash function performance is almost never a bottleneck. Still, we outline a few baselines in order to see how much we have to optimize the implementations:
- Key generation time in XMSS signatures for CL is proportional to the key lifetime. We want a decent number of signatures (2^{30}) to be producible in reasonable time (a few hours max) on commodity validator hardware, e.g. a regular desktop. Signature generation time in XMSS is a few milliseconds.
- CL signature aggregation: aggregating 1000 XMSS signatures requires proving about 2^{17} hash calls. Flock commits only the AND-gate outputs plus the circuit inputs and outputs, i.e. 2^{13}-2^{15} bits per hash call depending on the hash (about 23K bits for SHA-256, 41.6K for Keccak-f[1600], about 11K for BLAKE3), so the witness is 2^{31}-2^{32} bits (256-512 MB). It is packed into \mathbb{F}_{2^{128}} elements, Reed-Solomon encoded at rate 1/2 in 64 interleaved rows, and committed via a Merkle tree whose leaves are codeword columns of 64 \times 16 = 1024 bytes: for a 2^{32}-bit witness this is 2^{20} leaves, i.e. about 2^{24} compression calls for leaf hashing plus 2^{20} for the inner nodes. We want this to take less than a second.
- State tree computation: based on the current block structure (a few thousand touched accounts and storage slots per block, each lying on a path of \approx 40 nodes in a binary state tree), we estimate that 2^{17}-2^{18} hashes per block are computed to craft and rebuild Merkle paths. We need this to take at most 0.1-0.2 seconds, so that it fits into the block building and validation budget within a 12-second (soon 6-second) slot.
- EL hash-based signature generation is very fast no matter which hash function is used, with one exception: signing on a hardware wallet. From the UX perspective, any algorithm that requires more than a few seconds to sign is bad, whereas 1-2 seconds is tolerated. Key generation on such a wallet is yet another computationally intensive operation. As it is one-time, we assume it is okay if it takes a few minutes.
- EL signature aggregation and, more generally, proving full blocks with a zkVM is one of the most challenging use cases. Right now a typical block fits into 2^{30} RISC-V instructions, so proving such a block with a hash-based proof system requires committing to about 2^{36} field elements (2^{30} trace rows times roughly 64 columns) of size 31 bits each (KoalaBear or Mersenne31 field), i.e. about 256 GB of trace. Altogether we make about 2^{32} hash function calls to build a Merkle tree (dominated by hashing the leaves, plus 2^{30} inner 2-to-1 nodes), and this should be doable within 1 second. However, this operation is supposed to run not on a simple desktop but rather on a large GPU-equipped server.
Proving performance
Currently the most appealing proof system candidate is Flock. It is optimized for proving batches (100+) of identical circuits, and most of our use cases fit into this category. The actual proving performance is proportional to the number of AND operations in the bit circuit (padded to the next power of 2), and we will evaluate all the hash designs with respect to this metric. Concretely, Flock arithmetizes the circuit as R1CS over \mathbb{F}_2 and commits only to the AND-gate outputs and the circuit I/O; XOR gates are free. The witness is packed 128 bits per \mathbb{F}_{2^{128}} element and committed with the Ligerito polynomial commitment: an interleaved Reed-Solomon code of rate 1/2 with 64 rows, whose columns (1 KB each) form the leaves of a Merkle tree hashed with BLAKE3 or SHA-256. The commitment phase takes about a quarter of the prover time, and PCS opening another 17-24%; the remaining half is the zerocheck and lincheck sumchecks. On a 10-core M4 Max, Flock proves about 660K BLAKE3 compressions, 340K SHA-256 compressions or 250K Keccak-f[1600] permutations per second at batch sizes of 2^{16}-2^{18}.
Based on the current network workload, the expected number of validator signatures per block, the typical block size, and existing zkVM benchmarks, we have outlined the following list of proving performance requirements:
- Prove the hashing of 2^{25} bytes per second with LeanVM (in other words, a million hash calls) on a powerful laptop. This should allow for both proving Ethereum blocks in real time on GPUs and aggregating \approx 1000 XMSS signatures / 250 SPHINCS+ signatures (= proving about 2^{18} hash calls) on a laptop.
Standardization
Certain hash functions have been selected as government (NIST, GOST) or worldwide (IETF, ISO) standards. Being a standard brings certain benefits:
- A standardized hash function gets more attention from cryptanalysts (both during the standardization process and afterwards) and thus has a lower risk of being broken. Even if an attack appears, no one blames a security architect for following a de facto standard.
- It is implemented as a default option in many cryptographic software packages and is available on many platforms.
- Future cryptographic protocols, e.g. proof systems, are optimized for standard hash functions.
These are major advantages, but there exist other hash functions that have undergone a similar level of scrutiny and are widely implemented. We thus require that a future hash function is either standard or equally widely implemented and thoroughly analyzed.
Reasonable choices for hash functions
SHA-2-256
Selected by NIST in 2002, the SHA-2 family of hash functions has undergone significant public scrutiny from several generations of cryptanalysts (more than 45 cryptanalytic papers overall). It is implemented in almost every cryptographic software package, and modern Intel CPUs provide hardware acceleration for SHA-2.
SHA-2 belongs to what is now called the ARX design family, i.e. its internal operations are modular additions (32-bit for SHA-2-256), XORs, and bit rotations/shifts.
Being conceptually similar to SHA-1 and MD5, which experienced full breaks in 2004-05 with differential cryptanalysis, SHA-2 was viewed as potentially vulnerable and was replaced by the newer design SHA-3 in 2012. However, the later years showed that cryptanalysts struggled to break more rounds of SHA-2, and there has been only minor progress in the number of attacked rounds since then. The best collision attacks with complexity within 2^{128} operations reach 38 (out of 64) rounds at a cost of about 2^{104} (EUROCRYPT 2026), with practical collisions up to 35 rounds; zero-sum distinguishers on the compression function reach 47 rounds at 2^{46}. All other attacks either cost more than 2^{128} (preimage attacks start at 2^{248}) or work in a weakened setting where the initial value is selected by the adversary (39-40 rounds).
The mode of operation of SHA-2 is much weaker than its internal compression function. SHA-2 is a simple Merkle-Damgard construction, where the collision and preimage security of the compression function provably implies the security of the full hash. However, it also carries a well-known length-extension problem: a person who knows H(M_1) can figure out H(\mathrm{pad}(M_1)||M_2) even if M_1 is secret (e.g. contains a key). This property rules out indifferentiability from a random oracle: no RO has this property, and it is easily detectable. There exist simple fixes to this problem, which allow using the same compression function internally with little computational overhead – but they all yield a formally different hash function, not fully compliant with the standard.
Performance-wise, SHA-2 has always been good in software, though the lack of parallelism prevented it from being much faster on long messages. Also, on short messages SHA-2 requires at least 1 compression call for messages smaller than 56 bytes, and at least 2 compression calls for messages between 56 and 120 bytes long, which makes it suboptimal for the 2-to-1 compression use case. Within Flock, SHA-2 compression is rather slow, requiring 22K ANDs to hash 512 bits.
SHA-3 / Keccak
The SHA-3 competition witnessed more than 60 submissions (though half of them were broken in the first months), of which 5 made it to the final (BLAKE, Keccak, Groestl, JH, Skein) and have remained unbroken since. Keccak, the eventual SHA-3, was selected for its high security margin, hardware-friendly design, and dissimilarity to SHA-2, which was supposed to minimize the chance of breaking it using the differential cryptanalysis toolkit developed earlier for the SHA family. Since its presentation in 2008, Keccak has undergone the most thorough cryptanalysis to date, with more than 50 papers published on the subject. As a US government standard, it has been implemented in nearly all software packages dealing with cryptography, and is the default choice for all protocols involving hash functions and/or random oracles.
SHA-3 implements an NRX design, where bit rotations and XORs are combined with bitwise multiplication. A big state (1600 bits by default) and wide diffusion have made all differential attacks costly. SHA-3 carried a novel (at the time of its introduction) design called sponge mode, where a big state undergoes a bijective transformation (also called a permutation), alternating with message injection. Sponge mode comes with an indifferentiability proof in the random permutation model, which heuristically means that the hash is as good as a random oracle as long as the permutation does not exhibit any properties unexpected for a random one. This means that in order to make use of the provably secure sponge mode, one has to ensure that the Keccak permutation is random enough, and a weird distinguisher may contradict this belief. If we limit our consideration to adversaries doing at most 2^{128} computation units, the best distinguishing attack on the permutation (a zero-sum) covers 13 rounds (out of 24), whereas the best collision attack on the full hash covers 6 rounds and the best preimage attack 3 rounds (5 rounds for a 128-bit output). This demonstrates a very high security margin.
The big state makes SHA-3 relatively slow compared to SHA-2 and later alternatives. The NIST requirement to have 256-bit security against preimage attacks has resulted in wasting a large fraction of the state on the so-called capacity part, thus hashing 148 bytes per permutation call. Even though later research has proven that for short messages the capacity size can be much reduced, and that a smaller Keccak state can be more efficient for short messages, none of these suggestions has made it into the standard. Within Flock, SHA-3 compression is little faster than SHA-2, requiring 38K ANDs to hash 1088 bits.
Ethereum’s Keccak differs from SHA-3 in a minor detail: the padding scheme. Whereas both versions are equally secure, the functions are not compatible in either direction, thus making the Ethereum client implementation slightly more complex.
The SHA-3 designers have recently published a variant with half as many rounds (but otherwise identical), calling it KangarooTwelve. The cryptanalysis and proofs carry over to this design intact, so we can conclude that it has a high security margin. However, the adoption of this hash function is rather minimal.
SHA-2 variant
It is relatively easy to patch the SHA-2 mode so that the resulting construction is indifferentiable from a random oracle while keeping most of the SHA-2 cryptanalysis intact. Let F(IV,m) be the compression function of SHA-2, and let the message M to be hashed be divided into chunks m_1,m_2,\ldots,m_k. We construct an additional 64-byte message chunk m' as D||len(M), where D is a domain separator, and then define H(M) = f(\cdots f(f(f(IV,m'),m_1),m_2),\ldots ,m_k), so that f(IV,m') can be precomputed for certain len(M) values, and the actual computational cost is minimal for M as no special padding is needed. The downside of this scheme is that we have to start with a non-standard IV in order to prevent cross-collisions with regular SHA-2. This makes the construction incompatible with the standard. Security-wise, we additionally have to account for collision and preimage attacks where the adversary has full control over the IV. Current cryptanalysis records show that such attacks reach only 1-2 rounds further.
Except for messages whose length is a multiple of 64 bytes or up to 8 bytes shorter, this variant is as fast as regular SHA-2.
BLAKE2
BLAKE2 is a further evolution of the SHA-3 finalist BLAKE. While it is also an ARX design like SHA-2, the two structures have little in common. The big state of BLAKE2 (16 32- or 64-bit words) combines modular additions with XORs and rotations, with diffusion achieved by rearranging the state words each round. The big state and the absence of rotation patterns suggest that differential cryptanalysis fails due to activating too many state bits, though this has never been formally proven. The compression function of BLAKE2 is based on a blockcipher, and both it and the full BLAKE are provably indifferentiable from a RO under some ideal modelization of the blockcipher. In contrast to SHA-3, the distinguishers for BLAKE2 are much more powerful than the attacks on the full hash (collisions and preimages): a practical boomerang distinguisher covers 6.5 rounds (out of 10), and 8 rounds at a cost of 2^{182}, whereas no collision or preimage attack on the BLAKE2 hash has been published at any number of rounds. However, the cryptanalysis record of BLAKE2 is much shorter than that of both SHA-2 and SHA-3, and even of Poseidon: fewer than 10 cryptanalysis papers. This can be attributed to the strength of the design, but also indicates much lower attention from cryptanalysts.
BLAKE2 has always been notable for performance, as its internal structure is parallelism-friendly and enjoys a boost from vector operations on CPUs. Both BLAKE2 variants use the wide state to store message lengths, flags, etc., to minimize performance overhead, so that the 2-to-1 compression function can be implemented with only one blockcipher call. For the case of Ethereum, BLAKE2s, which deals with a 512-bit state, 512-bit message chunks, and 32-bit words, is a better fit than its twice larger counterpart BLAKE2b. Within Flock, Blake2b compression is among the fastest, requiring 14K ANDs to hash 512 bits.
Both BLAKE2b and BLAKE2s are widely used in Internet protocols and high-performance cryptographic applications, and are implemented in a number of libraries. They have been standardized as RFC 7693.
BLAKE3
BLAKE3 is a version of BLAKE2s with several important modifications: the mode of operation has changed, the number of rounds has been reduced from 10 to 7, and the internal blockcipher operations have been changed slightly. All these changes, while increasing the performance by about 40%, effectively break all proof and cryptanalytic compatibility with the earlier versions. As a result, BLAKE3 has no indifferentiability proof, nor do the attacks on BLAKE2 carry over to this version. Asserting the security of BLAKE3 would require re-evaluating all the past attacks.
Other Hashes
A few other designs are worth mentioning in the context of a future Ethereum hash function:
- The other SHA-3 finalists (Skein, JH, and Groestl) have undergone significant third-party scrutiny, but have never been widely adopted. They are also inferior in terms of performance.
- So-called lightweight hash functions such as Ascon-Hash and SPONGENT might be close to optimal in terms of bit operations per message byte, but have never been adopted or even implemented in major cryptographic libraries. Their cryptanalysis record is scarce.
- RIPEMD-160 has been used as part of Bitcoin address derivation as a second layer of defence (it follows SHA-2 hashing). Its short output makes it useless in most other protocols.
- ZK-friendly hash functions such as Tip5 and the Poseidon variants remain unbroken, but their cryptanalysis is still advancing at a notable pace. We cannot consider them mature yet.
Summary
Legend: 
good, 
acceptable with caveats, 
problematic, 
no data. Native performance gives single-core software throughput on long messages (commodity x86, SIMD but no hash-specific instructions unless stated) and the number of compression-function / permutation calls needed to hash a 64-byte message.
| Hash function | Security margin | Cryptanalytic papers | Provable security | Native performance | Flock performance | Standardization | Adoption |
|---|---|---|---|---|---|---|---|
| Requirement | At least 33% | Should exist | long messages: 1-2 GB/s; 64-byte inputs: 1250K calls in 1 s | prove 1M hash calls per second | NIST FIPS or ISO or RFC | Wide | |
| SHA-2-256 | collisions on 38/64 rounds (2^{104}), practical on 35/64; 45+ papers |
31 |
Merkle-Damgard: collision/preimage resistance provable, but length extension rules out indifferentiability and thus usage as RO |
long: 1 GB/s ; 64 bytes: 7.2 Mcomprs/s |
22K ANDs per 64-byte block; 340K compressions/s |
NIST FIPS 180-4, ISO/IEC 10118-3 |
ubiquitous; hardware acceleration on x86 and ARM |
| SHA-2 variant | as SHA-2, plus 1-2 rounds for adversary-chosen IV |
31 (as SHA-2; same compression function) |
indifferentiable from RO; reuses SHA-2 compression function |
as SHA-2 or faster |
as SHA-2 (prefix block precomputed) |
non-standard IV and prefix; incompatible with FIPS |
trivial to build on any SHA-2 library, but not available off the shelf |
| SHA-3 / Keccak | zero-sum distinguishers on 13/24 rounds, collisions on 6/24; 50+ papers |
27 |
sponge indifferentiability proof in the random permutation model |
long: 0.2 GB/s ; 64 bytes: 2.5 Mcomprs/s |
38K ANDs per permutation; 250K permutations/s |
NIST FIPS 202 (Ethereum’s Keccak-256 padding differs from the standard) |
in all major libraries; already used by the Ethereum EL |
| KangarooTwelve | same attacks as Keccak against 12 rounds |
27 (Keccak corpus; none dedicated to the 12-round instance) |
same sponge/tree proofs as Keccak |
long: 0.5 GB/s regularly, up to 2-3 GB/s in the tree mode ; 64 bytes: 5 Mcomprs/s |
about 19K ANDs per permutation, wasted on short inputs |
IETF RFC 9861 (informational); not a NIST standard |
few implementations; essentially no protocol adoption |
| BLAKE2s | 6.5/10-round boomerang distinguisher (8/10 at 2^{182}) vs no collision attack on the hash at all; fewer than 10 papers |
4 out of 16 total for the BLAKE family |
indifferentiable from RO in the ideal-cipher model |
0.7 GB/s; 64 bytes: 7 Mcomprs/s |
about 14K ANDs per 64-byte block; 2-to-1 in one call |
IETF RFC 7693 (informational); not a NIST standard |
widely implemented (OpenSSL, libsodium, Go, Rust); used in WireGuard, Zcash, Argon2 |
| BLAKE3 | 7 rounds; BLAKE2 attacks do not carry over; little dedicated cryptanalysis |
1 out of 16 total for the BLAKE family |
no indifferentiability proof for the new mode |
long: up to 7 GB/s with parallel hashing; 64 bytes: 10 Mcomprs/s |
about 11K ANDs per compression; 660K compressions/s |
no standard or RFC; specified only by the designers |
high-quality reference implementations and growing use in tooling, but absent from major crypto libraries and protocols |
Cryptanalysis summary
Entries are (attacked rounds / full rounds) with the attack complexity in parentheses; only attacks costing at most 2^{128} operations are listed. “Distinguisher” refers to the inner component (compression function, permutation or keyed permutation). Collision entries are for the real IV, except for the SHA-2 variant, where the adversary controls the chaining value and the relevant results are semi-free-start / free-start collisions. “Claimed” marks results whose complexity estimate has not been independently verified or for which no example was exhibited. Entries marked “–” mean no published result within the cost limit.
| Hash function | Rounds | Best distinguisher | Best collision | Best preimage |
|---|---|---|---|---|
| SHA-256 | 64 | 47/64 zero-sum (2^{46}, Biryukov-Lamberger-Mendel-Nikolic, ASIACRYPT 2011; claimed, the message-modification cost is not reproducible); 46/64 (2^{46}, Lamberger-Mendel 2011) | 38/64 ePrint 2026/1120; 35/64 two-block collision (practical, 2^{48} and 75 GB, CRYPTO 2026) | -- (all published preimage attacks cost \ge 2^{248}) |
| SHA-2 variant | 64 | as SHA-256 | 39/64 semi-free-start (practical, EUROCRYPT 2024); 40/64 free-start for SHA-224 only | -- |
| SHA-3 / Keccak | 24 | 13/24 zero-sum (2^{82}, Guo-Liu-Song 2016) | 5/24 for SHA3-256 (practical, 2^{37}, Guo et al. 2019) | 3/24 for SHA3-256 (2^{57}, 2019); for a 128-bit output (SHAKE128): 5/24 (2^{100.5}, 2025) |
| KangarooTwelve | 12 | as SHA-3 | -- (no dedicated result; Keccak collision techniques up to 5-6 rounds should port with re-solved connectors) | -- |
| BLAKE2s | 10 | 6.5/10 boomerang quartet (practical, about 2^{17}, Hao 2014) | -- (no collision or near-collision on the hash at any round count | -- (pseudo-preimage 6.75/10 only at 2^{253.9}) |
| BLAKE3 | 7 | 3/7 boomerang quartet (practical, Hao et al. 2023); 7/7 boomerang only at 2^{180} | -- | -- |
Performance summary
We provide performance numbers in cycles/byte for one particular 64-bit platform
| Hash | 64-byte message | Long message |
|---|---|---|
| SHA-2 | 4.8 | 2.1 |
| SHA-3 | 13.4 | 5.9 |
| Blake2s | 4.9 | 3.3 |
| Blake3 | 3.2 | 1.1 |
This performance translates to the following numbers on a 2.2 GHz single core:
| Hash | 2-to-1 compression calls (millions/sec | Long hashing (GB/sec) |
|---|---|---|
| SHA-2 | 7.2 | 1 |
| SHA-3 | 2.5 | 0.15 |
| Blake2s | 7 | 0.7 |
| Blake3 | 10.7 | 2 |
Conclusion
As the summary table indicates, each hash function has clear advantages and disadvantages:
- SHA-2 is fast and battle-tested but can not be a random oracle as is;
- SHA-3 is scrutinized and standardized, but is slow natively and in circuits.
- All BLAKEs are fast, BLAKE2s also carries a provably secure component, but the cryptanalysis record is scarce.
Rankings
If one would need to minimize the risks (from underscrutiny, complexity, etc.) at the cost of performance then the following ranking seems optimal:
- SHA-3
2-3. BLAKE2s
2-3. SHA-2 variant - KangarooTwelve
- BLAKE3
Further cryptanalysis of BLAKE2 would make it to the top.
I am personally more confident in the cryptanalytic security of the BLAKE2 blockcipher, so would rank the candidates as follows:
1-2. SHA-3
1-2. BLAKE2s
3-4. KangarooTwelve
3-4. BLAKE3
5. SHA-2 variant.