The problem zkUTXO solves

We want to solve the problem that the current existing privacy solutions are too restrictive to be widely adopted (like in some existing privacy pools, users can only transfer a pre-defined amount and token to get privacy, but usually this is not the real-life scenario when people need it). With the advancement and development of ZK technology, we can create more flexible fully-on-chain privacy solutions.

So we leveraged the Cipher protocol (part of the codebase in this hackathon is from their repo: https://github.com/Cipher-Protocol). In the submitted project, we have the 2 main features to solve the above problem

1. Total Flexibility: Based on the UTXO model, our solution will have total flexibility that empowers users to transfer any token with arbitrary amounts and still keep it private.

2. A Fully On-Chain solution: It's a robust on-chain privacy solution that provides users with secure, trustless, and decentralized private transfer tooling and it is EVM-compatible that can be extended to all EVM-compatible chains or L2

Challenges we ran into

1. Because of EVM-compatibility, we tried to deploy to Scroll and Mantle testnet, but it seems that although they are both EVM-compatible, there are still a few differences. For example, some functions that originally worked on Goerli and Arbitrum Goerli suddenly broke. The reason is that some EVM-compatible chains do not provide the event log filter function for RPC requests. Finally, we use a lower-level method to get all the event information from the chain and then filter it on the client side by ourselves.

2. In this UTXO-based privacy protocol, we maintain an on-chain Merkle tree. It means that when a user sends a transaction, we need to rebuild the Merkle tree on the client side by collecting event logs. It may take a lot of time and affect the user experience because it needs to collect data from the block where the contract is deployed. So we use The Graph to solve it. Through the subgraph service, we can obtain all the required data at once, which makes the entire experience better and faster.

3. We use Circom, a DSL, to write circuits. Circom is a relatively mature and convenient tool. It can even directly help developers produce Solidity verifier contracts. However, due to the feature of our protocol, we must have multiple verifiers in one verifier contract in our protocol. Unfortunately, Circom does not support it. Therefore, I referred to Circom's verifier contract source code and rewrote it using assembly in Solidity. Turn it into one verifier contract that can support countless circuits.