ZeraLabs logo
WALLET

Cryptographic Primitives

BN254 field arithmetic, Poseidon hash commitments, Merkle accumulators, and entropy bounds

This page provides rigorous mathematical treatment of Zera's privacy system, covering Poseidon hash-based commitments over the BN254 scalar field, incremental Merkle tree accumulators, and information-theoretic entropy bounds that underpin commitment hiding and nullifier unlinkability.

1. BN254 Scalar Field

Zera's privacy system operates over the BN254 scalar field F_p (a prime field of order ~2^254), using the Poseidon X5 algebraic hash function for commitments and Merkle tree construction, and Groth16 zk-SNARKs for succinct non-interactive zero-knowledge proofs verified on-chain via Solana's alt_bn128 precompile.

Definition 1 (BN254 Scalar Field): F_p is a prime field of order p ~ 2^254, the scalar field of the BN254 (alt_bn128) elliptic curve. All Poseidon operations and Groth16 R1CS constraints are expressed as arithmetic in this field.

2. Poseidon X5 Hash Function

Definition 2 (Poseidon Hash Function): Poseidon is an algebraic hash function based on the X5 S-box (x → x^5 in F_p) composed with linear layers (MDS matrices). It maps n field elements to one field element: Poseidon: F_p^n → F_p.

Why Poseidon Hash-Based Commitments

Zera uses Poseidon X5, an algebraic hash function designed for efficient arithmetic circuit representation. Unlike Pedersen commitments (which operate over elliptic curve groups), Poseidon commitments are native to the BN254 scalar field F_p -- the same field used by Groth16 R1CS constraints. This means commitment verification inside a zk-SNARK circuit requires minimal constraints, dramatically reducing proof generation time.

Poseidon X5 in R1CS: ~250 constraints per hash invocation
vs. SHA-256 in R1CS: ~25,000 constraints per hash invocation

Poseidon's algebraic structure means commitment verification inside Groth16 circuits is ~100x more efficient than traditional hash functions. This is the key advantage over both Pedersen (which requires elliptic curve operations in-circuit) and SHA-256 (which requires bit decomposition).

3. Commitment Construction

3.1 Definition

Setup: Let F_p be the BN254 scalar field. Poseidon X5 is parameterized with round constants and an MDS matrix derived from a nothing-up-my-sleeve seed. The commitment takes 7 field element inputs:

C = Poseidon(amount, secret, blinding, asset, memo[0], memo[1], memo[2], memo[3])

To commit to a transaction, the user samples secret, blinding ← F_p uniformly at random and computes the Poseidon hash of all inputs. The nullifier is derived as N = Poseidon(secret, C).

Step-by-Step Construction

Step 1 of 3

Sample Randomness

The user samples secret and blinding uniformly at random from the BN254 scalar field F_p (~254 bits of entropy each). These must be generated via a CSPRNG and never reused across commitments.
secret, blinding ← F_p  (uniform random via CSPRNG)

3.2 Computational Hiding

Theorem 1: The Poseidon commitment scheme is computationally hiding. Given C = Poseidon(amount, secret, blinding, ...), where secret and blinding are uniformly random in F_p and unknown to the adversary, determining amount requires inverting Poseidon on unknown inputs -- reducing to the preimage resistance of the hash function. Note: unlike Pedersen commitments which achieve perfect (information-theoretic) hiding, Poseidon provides computational hiding -- sufficient for all practical security levels.

3.3 Computational Binding

Theorem 2: Under the collision resistance of Poseidon, the commitment scheme is computationally binding. Finding two distinct input tuples (amount, secret, blinding, ...) and (amount', secret', blinding', ...) that produce the same commitment C would constitute a Poseidon collision -- contradicting the assumed collision resistance of the hash function.
Computational Hiding
With secret and blinding sampled uniformly from F_p (~254 bits of entropy each), the commitment output is computationally indistinguishable from a random field element -- hiding the amount, asset, and memo.
SNARK-Native Efficiency
Poseidon operates natively in F_p -- the same field as Groth16 R1CS constraints. Commitment verification inside a circuit costs ~250 constraints, enabling practical proof generation on consumer hardware.

4. Merkle Tree Accumulator

4.1 Incremental Merkle Tree

Definition 5: Zera uses a 24-level binary Merkle tree where each internal node is computed as Poseidon(left, right). The tree is incremental: new leaves are appended at the next available index, and only the path from the new leaf to the root is recomputed.

4.2 Merkle Root as State Commitment

Node(i, j) = Poseidon(Node(i-1, 2j), Node(i-1, 2j+1))
Root = Node(24, 0)
Capacity = 2^24 = 16,777,216 leaves

4.3 Membership Proofs in Zero Knowledge

Definition 6: A Merkle inclusion proof for leaf C at index i consists of 24 sibling hashes (one per level). Inside the Groth16 circuit, the prover demonstrates knowledge of a valid path from C to a known root R without revealing the leaf index or sibling values:

∃ (path, index) : MerkleVerify(R, C, path, index) = true

This requires 24 Poseidon evaluations inside the circuit (~6,000 R1CS constraints for the Merkle path alone), which is tractable thanks to Poseidon's SNARK-friendly design.

5. Algebraic Entropy Bounds

Zera's commitments and nullifiers operate over F_p, the BN254 scalar field of prime order p ~ 2^254. The secret and blinding factor inputs to Poseidon must be sampled with sufficient entropy to guarantee hiding. We formalize this requirement:

S_0 = { s_i ∈ F_p | H_α(s_i) ≥ H_min }, α > 1

Here H_α denotes the Renyi entropy of order α > 1, a stricter measure than Shannon entropy. When secret and blinding inputs are sampled uniformly from F_p, Poseidon commitments are computationally hiding: without the secret, the commitment output is indistinguishable from random field elements.

5.1 Entropy Floor

For uniform sampling in the BN254 scalar field, the Renyi entropy satisfies:

H_α(S_0) ≥ log p − O(1) ≈ 254 bits

This guarantees that an adversary observing arbitrarily many Poseidon commitments gains negligible advantage in recovering secret or blinding inputs. The 254-bit field provides a massive entropy reservoir -- far exceeding the 128-bit security level targeted by BN254 pairing operations.

Renyi Entropy
Generalizes Shannon entropy; for order α > 1 it yields stronger security guarantees against adversaries with bounded auxiliary information -- directly applicable to bounding leakage from Poseidon outputs.
Poseidon Preimage Resistance
The Poseidon X5 permutation over F_p provides collision resistance and preimage resistance -- the computational hardness assumptions that underpin commitment binding and nullifier security.

6. Key Mathematical Properties

BN254 Scalar Field: All arithmetic operates in F_p where p is the BN254 scalar field order (~2^254). Groth16 pairing operations use the BN254 (alt_bn128) elliptic curve.

Poseidon Hash Commitment: C = Poseidon(amount, secret, blinding, asset, memo[0..3]) -- binding via collision resistance, hiding via secret/blinding entropy

Nullifier Derivation: N = Poseidon(secret, commitment) -- deterministic, unlinkable to commitment without knowledge of secret

Merkle Accumulator: 24-level incremental Merkle tree with node hash = Poseidon(left, right), capacity 16,777,216, root history buffer of 100 entries

7. Complexity & Security Summary

OperationTimeSpaceSecurity
Poseidon commitmentO(1) -- single hashO(1)128-bit
Nullifier derivationO(1) -- single hashO(1)128-bit
Merkle insertionO(24) -- depth hashesO(24)128-bit
Groth16 verificationO(1) -- single pairingO(1) -- ~200 bytes128-bit

8. Implementation Stack

  • Rust (on-chain): light-poseidon 0.4 for Poseidon hashing, ark-bn254 0.5.0 and ark-ff 0.5.0 for field arithmetic, groth16-solana 0.2.0 for proof verification
  • TypeScript (client): circomlibjs for Poseidon hash computation, snarkjs for Groth16 proof generation, @noble/hashes for Keccak-256 auxiliary hashing
  • Verification: Solana's alt_bn128 precompile provides native BN254 pairing operations for on-chain Groth16 verification
  • CSPRNG-sampled field elements for secret and blinding; all field operations are deterministic given inputs
  • Poseidon round constants derived from nothing-up-my-sleeve seeds for transparency

9. Security Recommendations

Operational Security
  • CSPRNG for secret and blinding field elements -- never reuse across commitments
  • Validate all field elements are in [0, p) before Poseidon evaluation
  • Use audited Poseidon implementations (light-poseidon, circomlibjs)
  • Verify Groth16 proofs on-chain via alt_bn128 precompile -- never accept unverified proofs
  • Comprehensive test vectors for Poseidon round constants and circuit outputs
Post-Quantum Considerations
  • Poseidon hash commitments are not directly broken by Shor's algorithm (unlike Pedersen commitments which rely on discrete log)
  • However, BN254 pairings used by Groth16 are vulnerable to quantum attacks on elliptic curves
  • Migration path: hash-based commitments (already deployed) are quantum-resistant; the proof system would need replacement (e.g., lattice-based SNARKs or STARKs)
  • The Poseidon commitment layer is architecturally positioned for a post-quantum proof system swap

Go Deeper

Proof System

Groth16 circuits, post-quantum analysis, WOTS

$ZERA Token

Burn mechanics, fee structure, supply dynamics

Compliance & Economics

Regulatory positioning, investment framework

Glossary

All terms and definitions