sol_poseidon2 — a faster Poseidon2 hash syscall on BN254

[TypiCal25]

sol_poseidon2 — a faster Poseidon2 hash syscall on BN254

Add a new syscall, sol_poseidon2, exposing the Poseidon2 hash function over the BN254 (alt_bn128) scalar field — the direct successor to sol_poseidon. It is purely additive and feature-gated (enable_poseidon2_syscall); sol_poseidon is untouched. A parameters flag selects between two editions of the same permutation that differ only in their partial-round count.

Problem

Every program that recomputes a ZK-friendly hash on-chain — Merkle-path verification, commitment checks, public-input digests — pays for it in CU, which is why sol_poseidon exists. But sol_poseidon runs the original Poseidon, and the ecosystem has since moved on:

• Poseidon2 (ePrint 2023/323) is a drop-in faster construction at the same field and same security level: identical scalar field, identical x⁵ S-box, identical security analysis, with only the linear layer redesigned. It cuts permutation multiplications by up to ~90% and Plonk/R1CS constraints by up to ~70% (up to ~4× faster). On-chain, that is a direct CU reduction on the hashing every ZK program already does.
• Poseidon2 is now the default across the proving stacks — Plonky3, RISC Zero, the Circom Poseidon2 gadgets, the HorizenLabs reference. Provers are emitting Poseidon2; Solana has no matching on-chain primitive, so verifiers can't share it.
• The t=3 sponge makes on-chain cost linear and predictable in input length (ceil(n/2) fixed-width permutations) instead of growing with a per-width round schedule.

Proposed Approach

One syscall, ABI-identical to sol_poseidon so it reuses the audited slice-translation path and keeps tooling familiar:

define_syscall!(fn sol_poseidon2(
    parameters: u64,      // edition selector (round count)
    endianness: u64,      // 0 = big-endian, 1 = little-endian
    vals_addr: *const u8, // inputs: &[&[u8]]
    vals_len: u64,        // number of inputs, n
    result_addr: *mut u8  // 32-byte output
) -> u64);

• Permutation: the published HorizenLabs BN254 instance — field p = 21888…495617, S-box x⁵, width t=3; external matrix M_E = circ([2,1,1]), internal matrix M_I with diagonal [1,1,2]; round order M_E → R_F/2 full → R_P partial → R_F/2 full.
• Sponge: rate 2, capacity 1; state initialised [0, 0, n] (the capacity lane carries input length as a domain tag, so different arities can't collide); absorb 2 per block, squeeze state[0]. Cost is linear in n.
• Two editions via the parameters flag, differing only in the partial-round count R_P:

Edition (selector)	t	R_F	R_P	S-boxes/perm	Rel. cost	Algebraic design level M
Poseidon2-128 (0, default)	3	8	56	80	1.0×	≥ 2¹²⁸
Poseidon2-256 (1)	3	8	114	138	~1.7×	≥ 2²⁵⁶

• Constants from the HorizenLabs Grain-LFSR generator; editions share everything except the R_P constant table.
• CU model: deterministic and linear, base + ceil(n/2)·C_edition, with C_256 ≈ 1.7·C_128, pinned in the SIMD.
• Determinism: every client byte-identical; mandatory KATs anchored to the published HorizenLabs BN254 vector; canonical-element validation; a single unified error code (cf. SIMD-0129) so the error path can't become a divergence vector.

Why Two Editions

This is the part most worth scrutinising, because it is easy to over-claim. The parameters flag is purely an algebraic-cryptanalysis margin. It does not change generic or post-quantum security.

The "128"/"256" is the Poseidon2 design security level M — the bound below which algebraic attacks (Gröbner-basis / interpolation) must fail. For these instances R_F=8 covers statistical attacks identically, so the difference lives entirely in R_P. It is not a data-security claim: a sponge's generic security here is capped by the BN254 field, and is identical for both editions:

• Preimage / one-wayness (what hiding/secret data relies on): ~2¹²⁷ quantum (Grover is proven-optimal for black-box inversion and is round-independent).
• Collision: ~2¹²⁷ classical / no-QRAM quantum. The only quantum speedup (Brassard–Høyer–Tapp, ~2⁸⁵ here) needs ~2⁸⁵ cells of quantum-accessible memory (implausible at scale) and attacks binding, not hiding.

So Poseidon2-128 is the right default for essentially everything, including long-lived secret data. Harvest-now-decrypt-later on both commitments (H(secret, rand)) and additive/sponge ciphertexts (ct = pt + H(key, nonce…)) reduces to preimage/one-wayness, never collision — and that is ~2¹²⁷ quantum for both editions.

The only thing Poseidon2-256 buys is headroom in the algebraic margin, and that margin is a live, moving research target: the 2025 subspace-trail Gröbner analysis (ToSC 2025/954, follow-up 2026/967) found the original round-count model mis-estimates rounds — without breaking 128-bit prime-field Poseidon. A quantum adversary doesn't get a clean √ speedup either: the Grover+Gröbner hybrid (2017/1236) accelerates only the variable-guessing dimension, not the dominant Gröbner linear algebra. For irreversible, indefinitely-lived secrets that can never be re-hidden once written, a caller may rationally want margin that survives those revisions; for everything else it is wasted CU. A per-call flag lets each site pay exactly for the margin it wants — at zero cost to callers that don't. (Reasonable people may prefer to ship 128 only; see Feedback.)

Use Cases

• All on-chain ZK verification that currently calls sol_poseidon gets cheaper, predictable hashing and stays aligned with Poseidon2-native provers (Plonky3, RISC Zero, Circom).
• Merkle-path and commitment recomputation — the dominant on-chain hashing pattern — benefits most, since cost is linear in path length.
• Privacy / shielded protocols that maintain commitments, nullifiers, encrypted notes, and key-derived PRFs can recompute them on-chain within budget, with an optional conservative edition for the long-lived secret subset.
• Cross-stack provers can use one canonical BN254 Poseidon2 in-circuit and on-chain.

Future Work

Out of scope for this SIMD but enabled or complemented by it:

• Poseidon2 over BLS12-381, once a higher-security-level field is wanted on-chain (BLS12-381 group ops already landed via SIMD-0388).

Draft SIMD

Full proposal with the complete ABI, permutation/sponge specification, KATs, CU model, alternatives, and a detailed security analysis (two-lever model, Grover/BHT/Gröbner, and harvest-now-decrypt-later):

https://drive.google.com/file/d/1nK9BZpBMSPo3Ypoj8YH1x6EYE8IkHAeo/view?usp=sharing

Feedback Welcome

1. New syscall, or extend sol_poseidon with new Parameters variants (the SIMD-0388 enum-discriminated pattern)? I lean new — it's a different permutation and a different construction (fixed t=3 sponge vs. t=n+1).
2. Ship both editions, or Poseidon2-128 only? Since the 256-level edition adds no generic or post-quantum security and only algebraic-margin headroom, "128 is enough for everyone" is a defensible position. I lean toward exposing both via the flag (marginal cost: one constant table, one selector value, one set of KATs), but want input — especially from anyone with a concrete case for the higher margin.
3. CU model and input cap N_max — does the linear base + ceil(n/2)·C_edition model work for cross-client determinism/cost reviewers (Anza, Firedancer), and what input cap do clients want.

[deanmlittle]

Do you think we could just reuse the existing sol_poseidon syscall with an additional variant in the Parameters enum like Parameters::Bn254X5V2? If so, the surface area of things we'd need to change could be much smaller.

[TypiCal25]

From what I understand about Poseidon2, there is a redesign of the linear layer itself with a few additional operations that makes the permutation itself differ from the permutation of Poseidon(1).

[deanmlittle]

Sure, but isn't that just an enum variant naming issue?

[TypiCal25]

Yep if we can reuse the original syscall and modify it directly, then that works much better. It's something that I considered in the draft of the proposal but didn't put in here.

[deanmlittle]

Do we have concept ack from @samkim-crypto and @0x0ece?

[0x0ece]

Yes for me

[samkim-crypto]

Yes, I am in support of this as well.

1. I would also recommend reusing the existing sol_poseidon syscall with an additional variant in Parameters. We always want to make simpler changes that are small and localized to minimize syscall bloat.
2. I marginally favor restricting this initial implementation to the 128-level variant. The 256-level variant is niche, and I don't think there are no live production projects utilizing it at the moment. We can always introduce the 256 variant via a separate SIMD in the future. I don't have strong feelings though so if others prefer supporting both out of the box, then I am good with that too.
3. The CU equation seems reasonable to me. Maybe 128 could be a nice number for the input cap.