The problem zkAuction solves

This system solves a few critical problems in sealed-bid auctions on public blockchains:

Bid Integrity:
It guarantees that once a bidder commits to a bid (by submitting a Poseidon-based commitment), they cannot change it later. This prevents strategic manipulation or last-minute bid changes.

Secure Commit-Reveal Process:
By separating the auction into a commit phase (where only a cryptographic commitment is stored) and a reveal phase (where the actual bid and salt are provided), the system ensures that bid values remain hidden until the reveal. This prevents collusion and front-running.

Transparent Settlement:
Although deposits (which equal the bid amounts) are visible on-chain, the actual bid values are only determined at the reveal stage. This allows the contract to fairly determine the winning bid and refund losing bidders.

Efficient Verification Using zk Proofs:
Using a zero-knowledge proof ensures that bids satisfy certain conditions (e.g., being above a minimum) without revealing the bid itself during commitment. The Poseidon hash is SNARK-friendly, making it efficient for on-chain verification.

Challenges I ran into

I could not get everything to work smoothly at first. I spent a lot of time wrestling with integrating zero-knowledge proofs into the system. Designing the Circom circuit was tricky—I had to ensure that it correctly checked that a bid was above a minimum and computed a Poseidon hash commitment without any glitches. Then there was the whole trusted setup process, which generated the zkey and verification key files. It was a challenge to make sure that the parameters used off-chain (in the circuit) matched the on-chain Poseidon implementation in Solidity.

Another big headache was making sure that the off-chain proof generation and on-chain verification were completely in sync. Even a tiny difference in how the Poseidon hash was configured could throw everything off. I also had to handle unit conversions carefully; when working with Ether, it’s all in wei, so I had to be really careful not to mix up units.

On the frontend, loading the WASM files and dynamically importing the witness calculator was no walk in the park either. I kept getting errors like “expected magic word” because the files weren’t being served correctly or the paths were off.

Mostly the challenges I had were related to not knowing how to using zk-technology at all. This was my first and I'm glad I got to learn. Also, I kept having network issues, so I could not demo my application and test it entirely and on time during the building process.