Challenges I Faced

1. Circuit Size and Constraint Optimization

Problem: Initial circuits were too large, causing proof generation to take 5+ minutes in the browser and often crash due to memory limits(Macbook Air M2 8gb).

Solution:

• Reduced Merkle tree depth from 20 to 5 levels (still supports 32 notes per user)
• Used BN254 Poseidon hash instead of Pedersen (fewer constraints)
• Applied 251-bit field masking to ensure Starknet field compatibility
• Optimized witness generation by pre-computing hash values
• Used single-threaded UltraHonk backend for browser stability

Result: Proof generation reduced to less than a minutes with stable memory usage.

2. Double-Spend Prevention

Problem: In a UTXO system, users could potentially spend the same note multiple times if not properly tracked.

Solution:

• Each note has a unique nullifier =

  Hash(commitment, private_key, leaf_index)

• Nullifier is revealed and stored on-chain when spending
• Contract maintains a mapping of spent nullifiers
• Any transaction with a previously-used nullifier is rejected
• Nullifier computation is verified inside the ZK circuit

Result: Mathematically impossible to double-spend without detection.

3. Merkle Root Synchronization

Problem: Local Merkle tree in browser can become out of sync with on-chain state, causing proof verification to fail with "invalid merkle root" errors.

Solution:

• Query on-chain merkle root before generating proofs
• Store leaf indices with notes for accurate proof generation
• Rebuild local tree from on-chain events if desync detected
• Added comprehensive logging to debug root mismatches

4. Field Element Compatibility

Problem: BN254 curve (used by Noir) has a different field size than Starknet's field, causing hash outputs to be invalid on-chain.

Solution:

• Implemented

  mask_to_stark_field()

  function that applies 251-bit mask
• Applied masking consistently in both circuit and frontend
• Ensured all commitments and nullifiers fit within Starknet's prime field

MASK_251 = (1n << 251n) - 1n
masked_value = raw_hash & MASK_251

5. Relayer Trust and Anonymity

Problem: If users submit transactions directly, their wallet address is linked to the withdrawal. But using a relayer introduces trust assumptions.

Solution:

• Relayer only submits pre-signed proofs — cannot steal funds
• Proof locks the recipient address — relayer cannot redirect
• Relayer fee is specified in proof — cannot overcharge
• Anyone can run a relayer — decentralized submission
• Future: incentivized relayer network with fee market

6. Browser-Based Proof Generation

Problem: ZK proof generation is computationally intensive and browsers have limited resources compared to native environments.

Solution:

• Used WebAssembly (WASM) builds of Noir and barretenberg
• Initialized WASM modules asynchronously to prevent UI blocking
• Set

  threads: 1

  in UltraHonk backend for browser compatibility
• Added progress callbacks to show proof generation status
• Implemented proper error handling for out-of-memory scenarios

## What's Next

- [ ] Transact circuit for anonymous DeFi (JediSwap, zkLend, Nostra)
- [ ] Multi-asset support (ETH, USDC, USDT)
- [ ] Decentralized relayer network with incentives
- [ ] Mobile wallet integration
- [ ] Compliance tools for regulated entities (optional view keys)