Hashing Standards

Hashing Standards

Poseidon • Rescue • MiMC • Fallback SHA-256

The design of SnarkSide’s cryptographic primitives places special emphasis on hash function selection. Unlike traditional applications where general-purpose hash functions like SHA-256 or Keccak suffice, zero-knowledge circuits require ZK-friendly hash functions—optimized for efficiency in finite fields, constraint minimization, and compatibility with SNARK and STARK proving systems.

SnarkSide uses a multi-tiered hashing framework tailored to the needs of different components across the protocol. This section outlines the rationale for selecting Poseidon, Rescue, and MiMC as primary ZK hash functions, and defines the fallback usage of SHA-256 for off-chain integrity verification and cross-chain compatibility.

Why ZK-Friendly Hashes?

In traditional cryptographic applications, a hash function must be:

  • Collision-resistant

  • Preimage-resistant

  • Efficient on CPU or ASIC

In ZK applications, a hash must additionally be:

  • Efficient in arithmetic circuits over a finite field

  • Minimizing constraint overhead

  • Proven secure in the algebraic group used for proof systems

Hash Cost in ZK:

Hash Algorithm
Typical Constraint Count (1 input)

SHA-256

~25,000+

Poseidon

~400–800

MiMC

~1,000–1,200

Rescue

~700–1,000

Poseidon: Primary Hash Function

Poseidon is the default hashing standard across SnarkSide’s circuits due to:

  • Efficiency in R1CS and PLONK systems

  • Minimal arithmetic complexity

  • Native support in Circom, Halo2, and Arkworks

  • Field-agnostic tuning parameters

Use Cases:

  • Nullifier commitments

  • Vault state roots

  • Intent ID derivation

  • Merkle trees (for vaults, LPs, rewards)

  • Oracle hash commitments

Example: Poseidon Merkle Leaf

leaf = Poseidon([notional, direction, expiry, salt])

Poseidon is instantiated over the BN254 scalar field (Fr) and configured with a secure round function and sponge construction optimized for 3-5 input words.

Rescue: Alternative High-Entropy Hashing

Rescue is used for cases requiring stronger algebraic diffusion or compatibility with Starkware systems (if integration occurs):

  • Incentive trees

  • Funding rate accumulators

  • Long-term staking and epoch commitments

Rescue’s design allows for tight cryptographic proofs of security in algebraic models, making it ideal for long-lived state.

Parameters:

  • Rescue-Prime variant

  • State size: 3 field elements

  • Rounds: ~10–14 depending on field

MiMC: Lightweight Legacy Compatibility

MiMC is used in edge cases requiring ultra-low constraint hash functions:

  • Interim commitment steps

  • Noncritical auxiliary data hashing

  • Obsolete compatibility with prior ZK stacks

While less secure than Poseidon or Rescue in certain algebraic settings, MiMC remains a useful primitive for minimized circuit depth when resistance to advanced algebraic attacks is not paramount.

SHA-256: Off-Chain Verification & Interop

Although computationally expensive in ZK, SHA-256 remains indispensable for:

  • Bridge commitments (e.g., L2 → L1 event proofs)

  • Verifier matching with standard blockchain APIs

  • Off-chain data integrity proofs

  • Interop with Chainlink, Pyth, and relayer services

SnarkSide uses SHA-256 only outside of SNARKs and strictly for cross-system verifiability.

Multihash Schema

To distinguish hash types across the system, SnarkSide defines an internal multihash encoding standard:

[hash_type_id | data_length | digest_bytes]

Example:
0x01 | 0x20 | [PoseidonDigest]
0x02 | 0x20 | [RescueDigest]
0x03 | 0x20 | [MiMCDigest]
0xFF | 0x20 | [SHA256Digest]

This allows seamless decoding and avoids ambiguity in state trees or ZK calldata inputs.

Integration with Circom and Halo2

Circom Implementation:

component H = Poseidon(3);
H.inputs[0] <== input0;
H.inputs[1] <== input1;
H.inputs[2] <== salt;

Halo2 Configuration:

Halo2’s native Poseidon and Rescue gadgets are used via:

  • halo2_gadgets::poseidon::Hash

  • Field configured to BN254 or Pasta curves

  • Parameters tuned via Sage security scripts

Summary

SnarkSide’s hashing architecture balances circuit efficiency, cryptographic soundness, and interop:

Use Case
Hash Function

Vaults, Nullifiers, Intents

Poseidon

Epochs, Rewards, Incentives

Rescue

Lightweight auxiliary hashing

MiMC

Off-chain, bridge-compatible

SHA-256

This layered approach allows SnarkSide to remain performant inside ZK circuits while preserving verifiability and compatibility across public chains, L2 systems, and audit frameworks.

PreviousZK TookitNextProving Setup

Last updated