owned this note
owned this note
Published
Linked with GitHub
# Compliant Programmable Privacy: Introducing Typhoon Protocol
## # UPDATE: Implementation (2023/11/02)
> The work is inspired by [The Nakamoto Challenge from a16z](https://a16zcrypto.com/posts/announcement/introducing-the-nakamoto-challenge-addressing-the-toughest-problems-in-crypto/)
Typhoon, leveraging zkSNARK, serves as a trustless protocol designed to maintain privacy without compromising on compliance, effectively suspending transactions from flagged addresses.
## I. Problem
Platforms like [Tornado Cash](https://github.com/tornadocash/tornado-core) on Ethereum have ensured transactional anonymity. However, their lack of sanctions screening mechanisms inadvertently leaves room for financial malpractices such as money laundering.
## II. Solution
Typhoon is a trustless and programmable solution founded on zkSNARK technology, offering:
1. **Anonymity**: It preserves the anonymity of transactions by obscuring the link between sender and recipient.
2. **Sanctions Screening**: It includes an integral sanctions screening mechanism to deter transactions from flagged or "suspicious" addresses.
### Protocol Description
![](https://hackmd.io/_uploads/HyEtf03bT.png)
Our objective is to build a proof system that simultaneously retains Tornado Cash-level privacy while incorporating vital sanctions screening capabilities.
**Deposit**: The user construct a commitment from the user's address and a secret random number and deposit token into the smart contract with the commitment.
**Withdraw**: Within the secret random number, user can generate a proof to prove not in the blacklist and withdraw the token.
Typhoon's proof system ensures:
1. **zero-knowledge**: Only the sender knows the link between the commitment and their identity.
2. **completeness**: Users who aren't on a sanctions list can effortlessly prove their compliance, enabling seamless transactions.
3. **soundness**: If a user is indeed on a sanctions list, they will be unable to produce a valid proof, ensuring that the protocol remains compliant with legal norms.
### SNARK Proof
To meet Typhoon's privacy and compliance objectives, we incorporate two distinct SNARK proofs in our protocol.
#### 1. Commitment Proof
The commitment proof ensures a given commitment was constructed using their address, without disclosing any linkage between the commitment and their address.
With the user's public key $B$, generator of elliptic curve $g$, the commitment $C$ is generated by the following steps
1. Generate random number $r$
2. Construct nullifier $S=B+g^r$, and garbler $D=B*r$
3. Finally, construct the commitment $C=Com(S,D)$
Statement of knowledge of commitment proof, with public values $C, B$
$$S_1[C,B]=\{\text{I KNOW } r \text{ SUCH THAT }C=Com(B+g^r,B*r)\}$$
#### 2. Not-in-Blacklist Proof
The Non-in-Blacklist proof ensures that the commitment is a valid leaf in the Merkle tree and not linked to any blacklisted addresses.
Statement of knowledge of Not-in-Blacklist proof, with public values merkle root $R$, hash of nullifier $h$, Merkle opening for leaf $O$, address in blacklist $a_{block}$
\begin{equation*}
S_2[R,h,O,a_{\text{block}}] =
\left\{
\text{I KNOW } r,B \text{ SUCH THAT}
\begin{array}{cc}
& Addr(B)\neq a_{\text{block}} \\
& Addr(g^r)\neq a_{\text{block}} \\
& h=H(B + g^r) \\
& O \text{ is the opening of } Com(B+g^r,B \ast r)
\end{array}
\right\}
\end{equation*}
### Workflow
#### 1. Setup
Define $\mathcal D_1=(d_1{_p},d_1{_v}), \mathcal D_2=(d_2{_p},d_2{_v})$ as the zkSNARK proving and verifying key pairs for Commitment and Not-in-Blacklist proofs, respectively.
#### 2. Deposit
A user with a public key $B$ can deposit a token as follows:
1. Generate a random number $r$
2. Create a nullifier $S=B+g^r$, a garbler $D=B*r$ and a commitment $C=Com(S,D)$
3. Generate a zkSNARK proof $P_1$ for the commitment using $d_1{_p}$
4. The user then sends an Ethereum transaction with the commitment $C$ and proof $P_1$. If the proof is valid, the commitment $C$ is added as a new leaf in the Merkle tree.
#### 3. Withdraw
For withdrawal, a user proceeds as follows:
1. Select the recipient
2. Select the Root $R$ and compute opening $O$
3. Compute the nullifier hash $h=H(B+g^r)$
4. Generate a zkSNARK proof $P_2$ using $d_2{_p}$
5. Send an Ethereum transaction with proof $P_2$. If the proof is verified, the commitment is flagged as withdrawn, and the funds are transferred to the recipient.
### Implementation
https://github.com/jstinhw/typhoon