A proof of concept trustless ethereum mixer
Decentralized Ethereum Mixer
When someone sends 1 ether to the
depositfunction in miximus.sol they append single leaf to the merkle tree.
Afterwards someone who has the secret key (sk) and
nullifierof the leaf of the merkle tree is allowed to withdraw 1 ether. But instead of revealing the information to prove that they control it. They (using a zksnark) produce a proof that they know this information without revealing it. They also create a proof that their leaf is in the merkle tree.
When they verify this proof they reveal the nullifier, but not the sk. So no one is able to tell which nullifier maps to which leaf.
To prevent double spends the smart contract tracks the nullifiers and only allows a single withdrawal per nullifiers.
git submodule update --init --recursive
cmake .. && make
Finally you will need to download the ~400MB proving key from here, unzip it and save it in the
Start your prefered ethereum node,
cd testsand run
python3 test.pyThis will 1. Generate verification keys, proving keys, This step takes a lot of ram and its likely your OS will kill it if you have a bunch of windows open. 2. deploy the contract 3. Deposit 32 ether in 1 ether chunks. 4. Withdraw the 32 eth so that an observer cannot tell which deposit it was based upon.
The examples are interactive and ask you for the addresses you want to send from and to. The contract is deployed on the Rinkeby test net. These scripts deposit and withdraw from that contract.
python3 deposit.pyether this will create a transaction from an account of your chosing to send 1 ether to the smart contract. It will create a files of the forum
%dis the merkel tree index of your commitment.
python3 withdraw.pywill ask you for a file
%d.jsonit will call libsnark and generate a proof with proving key
python3 withdraw.pytakes a long time to run so make sure that your
eth.accountsis unlocked by the time the transaction gets broadcast. otherwise it will drop to pdb debugger.
A major problem in the current system is who pays for the gas for the withdrawal. While the perfect solution to this is to allow the smart contract to pay for gas. This is not possible at the moment. There for we provide layer two transaction abstraction where a depositor can define a fee that gets paid to whoever pays the gas of a transaction. Future work should formalize a communication channel where people can advertise these transactions so that others can pay the gas for them and recive a reward.