Abstract

Standard cryptographic hash functions like SHA-256 and Keccak-256 are efficient in hardware and software but impose enormous constraint counts when expressed inside arithmetic circuits used by ZK proof systems. A single SHA-256 hash requires roughly 25,000 R1CS constraints in a Groth16 circuit - expensive enough that hashing large Merkle trees inside a ZK proof is often a bottleneck that dominates proving time. SNARK-friendly hash functions - Poseidon, Rescue, Reinforced Concrete, and their variants - are designed from the ground up to minimize arithmetic circuit depth and constraint count, trading off some classical security assumptions for a dramatic reduction in in-circuit cost.

Why Conventional Hashes Are Expensive In-Circuit

SHA-256 operates over 32-bit words using bitwise operations (AND, XOR, rotate). Inside a prime-field arithmetic circuit, each bitwise operation must be decomposed into field elements and range-checked, producing many constraints per gate. The mismatch is fundamental: SHA-256 is optimized for binary hardware, while ZK proof systems like Groth16, PLONK, and STARKs operate natively over large prime fields (e.g., the BLS12-381 scalar field of order roughly 2^255). Poseidon, by contrast, uses the Substitution-Permutation Network (SPN) structure with an S-box defined as x^5 or x^7 over the native field, which requires only a small number of field multiplications per round and maps directly to the arithmetic circuit model.

Poseidon and Its Deployment

Poseidon was introduced in 2019 by Grassi, Khovratovich, Rechberger, Roy, and Schofnegger and has since become the de facto SNARK-friendly hash in Ethereum’s ZK ecosystem. Zcash uses Sinsemilla (a different algebraic construction) for their Orchard shielded pool, while Ethereum’s Privacy and Scaling Explorations group uses Poseidon in Semaphore, Tornado Cash’s circuits, and the Ethereum Attestation Service’s ZK credential work. The Starknet ecosystem uses Poseidon with a modified parameter set tuned for its STARK-native field. A single Poseidon hash over two field elements costs roughly 240 constraints in a Groth16 circuit, compared to ~25,000 for SHA-256 - roughly a 100x improvement. The poseidon-rs crate and the circomlib library both provide audited implementations.

Security Caveats and Algebraic Attacks

The low constraint count of SNARK-friendly hashes comes from a reduced number of nonlinear rounds and the algebraic structure of the S-box. This algebraic structure creates attack surfaces that do not exist for bit-based hash functions. Grobner basis attacks, interpolation attacks, and algebraic saturation attacks are all relevant threat models. The Poseidon team has published updated security analysis and parameter recommendations in response to Grobner basis improvements, and the current Poseidon2 variant (2023) adjusts the linear layer and round counts to provide tighter security margins. Implementers should always use published, audited parameter sets and never adjust round counts without a fresh security analysis.

Rescue and Reinforced Concrete

Rescue (Aly et al.) uses the inverse S-box x^(-1) alternating with x^alpha, which provides resistance against some algebraic attacks at the cost of higher constraint count than Poseidon. Reinforced Concrete (Grassi et al., 2022) uses a hybrid design with a lookup-based S-box that achieves strong classical security bounds while remaining efficient in proof systems that support lookup arguments - notably PLONK with Plookup. As lookup-argument support matures in PLONK-based systems, Reinforced Concrete is gaining traction for use cases that require stronger classical security guarantees than Poseidon provides. The concrete-hash Rust crate from Zama implements this family and is used in their FHE-SNARK bridging work.