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 invocationvs. 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
Sample Randomness
secret, blinding ← F_p (uniform random via CSPRNG)
3.2 Computational Hiding
3.3 Computational Binding
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.
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
| Operation | Time | Space | Security |
|---|---|---|---|
| Poseidon commitment | O(1) -- single hash | O(1) | 128-bit |
| Nullifier derivation | O(1) -- single hash | O(1) | 128-bit |
| Merkle insertion | O(24) -- depth hashes | O(24) | 128-bit |
| Groth16 verification | O(1) -- single pairing | O(1) -- ~200 bytes | 128-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
- 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
- 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
