|arnaucube b1c0ae724f||3 months ago|
|.github/workflows||8 months ago|
|circuits||6 months ago|
|contracts||6 months ago|
|dist||9 months ago|
|migrations||9 months ago|
|src||3 months ago|
|test||3 months ago|
|.gitattributes||9 months ago|
|.gitignore||9 months ago|
|LICENSE||9 months ago|
|README.md||3 months ago|
|compile-circuits.sh||9 months ago|
|miksi-logo00-small.png||9 months ago|
|package-lock.json||9 months ago|
|package.json||9 months ago|
|test-compile-circuits.sh||9 months ago|
|truffle-config.js||9 months ago|
|tsconfig.json||9 months ago|
|tslint.json||9 months ago|
Ethereum zk mixer where all the computation & constructions are done offchain and then proved inside a zkSNARK to the smart-contract (both to deposit and withdraw).
From Esperanto, miksi (miks·i): to mingle, to blend, to mix, to shuffle
The client builds a MerkleTree, carries out the required computation, and then generates a zk-proof proving that the offchain computation has been done correctly (no leaf deletion, and only one correctly formatted leaf addition).
This approach requires only
~325.000 gas to deposit (compared to
~1M gas for an onchain computation approach) , and
~308.000 gas to withdraw.
These gas savings come from the fact that we don't need to carry out the MerkleTree computations onchain. Instead, we prove the correctness of these offchain computations inside the snark proof, and verify this proof onchain. It's much cheaper to verify the proof than to carry out the necessary computations onchain.
Warning: This repository is in a very early stage. The current version works, but is not finished. There are some improvements in the works.
The WebApp to use miksi-core can be found at https://github.com/arnaucube/miksi-app, and a live-demo with the smart contract deployed at Goerli Ethereum testnet can be used here: https://arnaucube.github.io/miksi-app/
npm run test-circuits
npm run test-sc
npm run test
Note: Both the spec and the code are works in progress. There are some pending improvements in the works, and some diagrams are needed to better explain things.
All computations and constructions are done offchain and then proved inside a zkSNARK to the smart-contract
From the depositer's perspective, the interface facilitates the following flow:
commitment, which is the Poseidon hash:
commitment = H(coinCode, amount, secret, nullifier), where:
coinCode: code that specifies which currency is being used (
amount: the amount to be deposited
secret: random, private
commitmentto the MerkleTree
commitmentcontained in the leaf you've just added to the MerkleTree
RootOld(the current one in the smart-contract) to
RootNewhas been done following the rules (no leaf deletion, and only one correctly formatted leaf addition, etc.)
depositcall, together with the zkProof data
Once these steps have been carried out, the smart-contract verifies the zkProof of the deposit, and if everything checks out ok, stores the commitment and the new root.
The deposit circuit can be found here.
As before, all computations and constructions are done offchain and then proved inside a zkSNARK to the Smart Contract
From the withdrawer's perspective, the interface facilitates the following flow:
nullifieryou reveal, whose
commitmentis in a MerkleTree with
rootmatching the one stored in the smart-contract
If the zkProof verification passes, and the nullifier has not already been used, the smart-contract sends the ETH to the specified address.
The withdraw circuit can be found here.