ZK Mixuper

ZK Mixuper is developed to allow users to transfer funds anonymously.

Overview

The app user-flow consists of two steps: 1 - deposit to a pool with a specific nominal e.g. 100 ADA from a compromised address, 2 - withdraw you funds using generated on step 1 secret from the same pool to a fresh uncompromised address.

Our service allows users to deposit in ADA. To interact with the app, users need to connect their wallet to the service. At the moment we provide an option to connect all wallets that support CIP-30. After connecting a wallet, selecting a pool and signing the transaction user receives a note which he must save. This note will be required to withdraw funds from the pool. User deposits are stored in a Merkle Tree as "commitments", a commitment is a hash digest of users secret.

The user who has the note can enter it on the website, fill in the address to receive funds and withdraw them. The verification service is based on zero knowledge proof: user wants to proof the ownership of deposited funds by constructing a zk-proof. It makes use of users secret by proving its hash is contained in the Merkle tree of deposits.

Our tech stack:

Haskell (Plutus, Plutarch), TypeScript (node.js, React, lucid), Aiken, Circom

Open source:

• Monorepo for front-end, off-chain applications, and Aiken smart contracts zk-mixuper
• Arithmetic circuit used for zk-proofs zkp-circuit
• Experimental Merkle tree which is not used in production and is provided for reference zk-mixuper-deposit. We decided it is better to keep the tree as a list and re-hash it to find a new root.
• On-chain ZKP validator, which is not used in production and is provided for reference zk-mixuper-on-chain. This is the validator for Zero knowledge proof (SNARK). We are making efforts to optimize this algorithm to stay within the network limit.

Our project is inspired by tornado, pairing, cardmix.

Challenges.

We faced with Cardano on-chain limitations:

1. Due to transaction size limits max height of Merkle tree is 8.
2. Due to execution units limits (CPU & memory) this code could not be run on-chain. Therefore zk-proof is verified off-chain by the relayer.

Roadmap

We plan to do much more script optimization and redesign the user flow, splitting the proof validation and withdrawal process into several steps to help us stay within Cardano's on-chain limitations. Another option is to use new plutus builtin functions for pairing and group operations, when CIP-0381 will be included in new network update (hardfork). In parallel there is an option to deploy existing protocol into a hydra head with changed protocol parameters, that have more generous execution units limits.