Private Transactions on Ethereum

Suyash Bagad

Merkle Tree

  • Suppose we want to store \(2^{k}\) files in a decentralized and succinct way

\(h = H\big(\)

\(\big)\)

  • Here, \(h\) indeed is a succinct representation of the files \(\{f_i\}_{i \in [8]}\)
  • The problem is: to check if a file in included in \(h\), you need all \(\{f_i\}_{i \in [8]}\) files
  • A better way to achieve this is using Merkle trees!

\(f_1\)

\(f_2\)

\(f_3\)

\(f_4\)

\(f_5\)

\(f_6\)

\(f_7\)

\(f_8\)

Merkle Tree

  • Suppose we want to store \(2^{k}\) files in a decentralized and succinct way

\(f_1\)

\(f_2\)

\(f_3\)

\(f_4\)

\(f_5\)

\(f_6\)

\(f_7\)

\(f_8\)

\(H(f_1)\)

\(H(f_2)\)

\(H(f_3)\)

\(H(f_4)\)

\(H(f_5)\)

\(H(f_6)\)

\(H(f_7)\)

\(H(f_8)\)

Merkle Tree

  • Suppose we want to store \(2^{k}\) files in a decentralized and succinct way

\(H(f_1)\)

\(H(f_2)\)

\(H(f_3)\)

\(H(f_4)\)

\(H(f_5)\)

\(H(f_6)\)

\(H(f_7)\)

\(H(f_8)\)

\(H'(H(f_1), H(f_2))\)

\(H'(H(f_3), H(f_4))\)

\(H'(H(f_5), H(f_6))\)

\(H'(H(f_7), H(f_8))\)

\(h^1_1\)

\(h^1_2\)

\(h^1_3\)

\(h^1_4\)

\(h^2_1\)

\(h^2_2\)

\(h^3_1\)

\(H'(h^1_1, h^1_2)\)

\(H'(h^1_3, h^1_4)\)

\(H'(h^2_1, h^2_2)\)

Merkle Tree

\(H(f_1)\)

\(H(f_2)\)

\(H(f_3)\)

\(H(f_4)\)

\(H(f_5)\)

\(H(f_6)\)

\(H(f_7)\)

\(H(f_8)\)

\(h^1_1\)

\(h^1_2\)

\(h^1_3\)

\(h^1_4\)

\(h^2_1\)

\(h^2_2\)

\(h^3_1\)

  • Indeed, \(h_1^3\) is succinct form of the files. How do we prove inclusion?

Merkle Tree

\(H(f_1)\)

\(H(f_2)\)

\(H(f_3)\)

\(H(f_4)\)

\(H(f_5)\)

\(H(f_6)\)

\(H(f_7)\)

\(H(f_8)\)

\(h^1_1\)

\(h^1_2\)

\(h^1_3\)

\(h^1_4\)

\(h^2_1\)

\(h^2_2\)

\(h^3_1\)

  • Indeed, \(h_1^3\) is succinct form of the files. How do we prove inclusion?

Merkle Tree

\(H(f_1)\)

\(H(f_2)\)

\(H(f_3)\)

\(H(f_4)\)

\(H(f_5)\)

\(H(f_6)\)

\(H(f_7)\)

\(H(f_8)\)

\(h^1_1\)

\(h^1_2\)

\(h^1_3\)

\(h^1_4\)

\(h^2_1\)

\(h^2_2\)

\(h^3_1\)

  • Only \(\left( H(f_6), h^1_4, h_1^2 \right)\) are enough to prove inclusion of \(f_5\)! Sister nodes!

Tornado.Cash

  • Brings transaction privacy by breaking the on-chain link between the recipient and destination addresses
  • Works in two stages: Deposit and Withdraw

Deposit

  • Deposit: \((i)\) Generate \(k, r \leftarrow \mathbb{F}_p\) and compute \(C_1 = H(k, r)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(h^1_1\)

\(h^1_2\)

\(h^1_3\)

\(h^1_4\)

\(h^2_1\)

\(h^2_2\)

\((ii)\) Send \(N\) ETH to contract \(\mathcal{C}\) which adds \(C_1\) to the Merkle tree

\(h^3_1\)

  • Deposit: \((i)\) Generate \(k, r \leftarrow \mathbb{F}_p\) and compute \(C_1 = H(k, r)\)

\(C_1\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(h^1_1\)

\(h^1_2\)

\(h^1_3\)

\(h^1_4\)

\(h^2_1\)

\(h^2_2\)

\((ii)\) Send \(N\) ETH to contract \(\mathcal{C}\) which adds \(C_1\) to the Merkle tree

\(h^3_1\)

Deposit

  • Deposit: \((i)\) Generate \(k, r \leftarrow \mathbb{F}_p\) and compute \(C_1 = H(k, r)\)

\(C_1\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(h^1_1\)

\(h^1_2\)

\(h^1_3\)

\(h^1_4\)

\(h^2_1\)

\(h^2_2\)

\((ii)\) Send \(N\) ETH to contract \(\mathcal{C}\) which adds \(C_1\) to the Merkle tree

\(h^3_2\)

\(h^3_1\)

Deposit

  • Deposit: \((i)\) Generate \(k, r \leftarrow \mathbb{F}_p\) and compute \(C_1 = H(k, r)\)

\(C_1\)

\(C_2\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(h^1_1\)

\(h^1_2\)

\(h^1_3\)

\(h^1_4\)

\(h^2_1\)

\(h^2_2\)

\((ii)\) Send \(N\) ETH to contract \(\mathcal{C}\) which adds \(C_1\) to the Merkle tree

\(h^3_3\)

\(h^3_1\)

\(h^3_2\)

Deposit

  • Deposit: \((i)\) Generate \(k, r \leftarrow \mathbb{F}_p\) and compute \(C_1 = H(k, r)\)

\(C_1\)

\(C_2\)

\(C_3\)

\(C_4\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(h^1_1\)

\(h^1_2\)

\(h^1_3\)

\(h^1_4\)

\(h^2_1\)

\(h^2_2\)

\((ii)\) Send \(N\) ETH to contract \(\mathcal{C}\) which adds \(C_1\) to the Merkle tree

\(h^3_5\)

\(h^3_1\)

\(h^3_2\)

\(h^3_3\)

\(h^3_4\)

Deposit

Withdraw

  • To withdraw a coin \(k,r \in \mathbb{F}_p\) at position \(l \in \mathbb{Z}_{2^{16}-1}\), we do:

\((i)\) Select a withdrawal address \(A\)

\((ii)\) Select a root \(R\) among the stored ones and compute opening \(O(l)\) w.r.t \(R\)

\((iii)\) Compute nullifier hash \(h= H(k)\)

\((iv)\) Compute a proof using Groth16 proof system s.t. :

\begin{aligned} \texttt{wit} &\leftarrow (k, r) \in \mathbb{F}_p^{2}, \ l \in \mathbb{Z}_{2}^{16}, \ O(l) \in \mathbb{Z}_p^{16} \\ \texttt{stmt} &\leftarrow h = H(k) \ \wedge \ O(l) \text{ is opening proof of } H(k, r) \text{ at position } l \text{ to } R \end{aligned}

\((v)\) The contract verifies the proof and uniqueness of the nullifier hash.

       If that succeeds, the contract transfers \(N\) ETH to \(A\).

Withdraw

  • To withdraw \(C_3\), create a proof \(\pi =  \mathcal{P}\left( k_3, r_3, (C_4, h_1^1, h_2^2) \right)\)
  • The contract verifies \(\pi\) and checks if nullifier hash is unused.

\(C_1\)

\(C_2\)

\(C_3\)

\(C_4\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(H(0)\)

\(h^1_1\)

\(h^1_2\)

\(h^1_3\)

\(h^1_4\)

\(h^2_1\)

\(h^2_2\)

\(h^3_5\)

Comparison

Anonymity
Non-custodial
Variable amounts
Shielded payments
ZK Rollup
Proof system

\(^{\dagger}\) Concerns with Tornado.cash: https://lightco.in/2019/08/07/tornado-review/

Groth16

PLONK

\(^{\ddagger}\) Theoretically, ZK Rollups with Groth16 is possible. Loopring uses Groth16 with ZK Rollups.

\(\dagger\)

\(\ddagger\)

Benchmarks

  • The CRS in Groth16 is non-universal, each circuit requires a trusted setups
  • TurboPLONK competes Groth16 in performance
  • UltraPLONK (Q3 2021) is set be 3-4x better than TurboPLONK

Thank you!

Made with Slides.com