https://github.com/YolaYing/ZK-Tornado-Cash

https://github.com/YolaYing/ZK-Tornado-Cash

Last synced: 2 months ago
JSON representation

• Host: GitHub
• URL: https://github.com/YolaYing/ZK-Tornado-Cash
• Owner: YolaYing
• Created: 2024-01-18T23:25:42.000Z (12 months ago)
• Default Branch: main
• Last Pushed: 2024-01-19T16:58:11.000Z (12 months ago)
• Last Synced: 2024-08-02T13:29:34.998Z (5 months ago)
• Language: TypeScript
• Size: 149 KB
• Stars: 0
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

• awesome-ora - zkSafeMixer

README

        
# zkGraph zkSafeMixer

#### This graph listen to both USDT contract and the dummy mixer contract written for this project

This zkgraph was lightly inspired by [proof of Blacklist](https://github.com/varun-doshi/Proof-of-Blacklist-zkGraph) and also [Vitalik's proof of innocence](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4563364). 

Crypto Mixer is used for privacy-preserving applications, like Tornado Cash. Sometimes, it mixes your innocent money with other malicious users' money. It is important to guard against malicious users from using it.

The idea of zkSafeMixer is to query a blacklist of some tokens (here we used USDT for example, and can easily be extended to other tokens and even multiple tokens), and when a user trying to deposit money to a crypto mixer smart contract (here I used a dummy contract I wrote for this project), it checked whether or not any of the users are in the blacklist. If so, it will return a warning signal and potentially prevent the downstream contracts from taking the money.

This was done by listening to multiple contracts (token contracts and mixer contracts together in a zkgraph.

(We talked with super helpful HO developers Lightman and Suning and learned that currently zkgraph only supports one block query per execution, but planned to add the feature to query multiple blocks together in the future. The current code logic will compile and work fine, but it won't make too much real-world sense right now because the current zkGraph only allows querying one block at a time. It will make more sense once the feature is added, and no code change is required to make it work then. But it is fun to write an application code for the future feature though :)

 

####  

## Test Contract and Block id

when debugging execution and proof generation, you may use:

- block id: 5111991

- contract address:

  - USDT contract on sepolia: 0x7169D38820dfd117C3FA1f22a697dBA58d90BA06

  - A dummy mixer contract on sepolia: 0xD92992b49c39C917B6cC587c22E51F720c4b7062

or you can just use 'script.sh' to test the whole workflow(remember to fill in the zkgraph.config.ts)

## Usage CLI

> Note: Only `full` image will be processed by zkOracle node. `local` (generated by commands ending with `--local` option) means the zkGraph is compiled locally and only contains partial computation (so that proving and executing will be faster).

The workflow of local zkGraph development must follow: `Develop` (code in /src) -> `Compile` (get compiled wasm image) -> `Execute` (get expected output) -> `Prove` (generate input and pre-test for actual proving in zkOracle) -> `Verify` (verify proof on-chain).

To upload and publish your zkGraph, you should `Upload` (upload code to IPFS), and then `Publish` (register zkGraph on onchain zkGraph Registry).

## Commonly used commands

- **compile**: `npx zkgraph compile`

- **exec**: `npx zkgraph exec `

- **prove**: ` npx zkgraph prove   -i|-t|-p`

- ……

Read more: https://github.com/hyperoracle/zkgraph-cli#cli