真正的ZK应用解析：深入探讨Tornado Cash的工作原理与业务逻辑

导语：

最近Vitalik与多位学者合作发表了一篇新论文，探讨了Tornado Cash如何实现反洗钱方案。论文提出通过让取款人证明其存款记录属于不包含黑钱的集合来实现这一目标，但文中对Tornado Cash的业务逻辑和原理解读不够深入，让读者感到意犹未尽。

值得注意的是，Tornado这类隐私项目才是真正利用了ZK-SNARK算法的零知识特性，而大多数打着ZK旗号的Rollup项目实际上只使用了ZK-SNARK的简洁性。很多人常常混淆Validity Proof与ZK的区别，而Tornado恰恰是理解ZK应用的绝佳案例。

本文作者曾在2022年为Web3Caff Research撰写过一篇关于Tornado原理的文章，现将部分内容节选并加以拓展，整理成文，帮助读者更系统地理解Tornado Cash。

原文链接：https://research.web3caff.com/zh/archives/2663?ref=157

“龙卷风”的工作原理

Tornado Cash是一款基于零知识证明的混币器协议，其旧版本于2019年投入使用，新版本则在2021年底推出了beta版。旧版Tornado基本实现了去中心化，链上合约开源且不受多签控制，前端代码开源并备份在IPFS网络中。由于旧版结构更为简洁明了，本文将重点解读旧版本。

Tornado的核心思路是将大量存取款行为混合在一起。存款者在Tornado存入代币后，通过出示ZK Proof证明自己曾存款，再使用新地址提款，从而切断存取款地址之间的关联性。

更形象地说，Tornado就像一个透明的玻璃箱，里面混杂着许多人投入的硬币。虽然可以看到是谁放入了硬币，但由于硬币高度同质化，当一个陌生人从箱中取走一枚硬币时，我们很难确定这枚硬币最初是谁放入的。

（图源：rareskills）

这种场景其实并不陌生：当我们在Uniswap池子里兑换ETH时，根本无法知道这些ETH来自哪个具体的流动性提供者。但不同之处在于，Uniswap交易需要支付等价的代币作为成本，且无法实现资金”私密”转让；而混币器只需要提款者出示存款凭证即可。

为了确保存取款行为具有同质性，Tornado池子中的每笔存款和取款金额都保持一致。虽然所有存取款记录都公开可见，但彼此之间看似毫无联系，且金额相同，从而有效混淆视听，切断资金转移痕迹。这也为洗钱行为提供了天然的便利。

关键问题在于：提款者如何证明自己曾存款？由于提款地址与所有存款地址都不相关，如何验证其提款资格？最直接的方法是披露具体存款记录，但这会暴露身份。这时零知识证明就发挥了关键作用。

提款者通过出示ZK Proof，证明自己在Tornado合约中有未提取的存款记录，即可成功提款。零知识证明既保护了隐私，又让外界确认提款者确实存过款，但无法对应到具体存款人。

将”我在Tornado资金池存过款”转化为”我的存款记录存在于Tornado合约中”。如果用Cn表示存款记录，问题就简化为：已知存款记录集合{C1，C2，…C100…}，取款者Bob需要证明自己持有的密钥生成了其中的某个Cn，但通过ZK技术不泄露具体是哪一个。

这里利用了Merkle Proof的特殊性质。Tornado将所有存款记录组织成一棵Merkle Tree，作为其底层叶子节点。每当有新存款时，合约会将对应的特征值Commitment写入叶子节点，并更新Merkle Tree的根。

例如，Bob的存款是Tornado的第1万笔交易，那么与其关联的特征值Cn就作为Merkle Tree的第1万个叶子节点C10000=Cn。合约会自动计算新的Root并更新。（注：为节省计算量，Tornado合约会缓存之前变化的节点数据）

（图源：RareSkills）

Merkle Proof本身非常简洁高效。要证明某笔交易存在于Merkle Tree中，只需提供Root对应的Merkle Proof。即使Merkle Tree包含100万笔存款记录，Merkle Proof也仅需21个节点数值。

证明交易H3存在于Merkle Tree中，只需证明用H3和其他部分数据可以生成Root，这些数据就构成了Merkle Proof。

Bob提款时需要证明其凭证对应Merkle Tree中记录的存款哈希Cn。具体需要证明两点：Cn存在于链上Merkle Tree中（可通过Merkle Proof证明）；Cn与Bob持有的存款凭证相关联。

Tornado业务逻辑详解

Tornado用户界面前端代码预设了多项功能。当用户点击存款按钮时，前端会在本地生成两个随机数K和r，计算Cn=Hash(K,r)的值，再将Cn（即commitment）传入Tornado合约，纳入其构建的Merkle Tree。K和r相当于私钥，系统会提示用户妥善保存，因为提款时仍需使用。

（encryptedNote是可选项，允许用户用私钥加密凭证K和r并存储到链上，防止丢失）

值得注意的是，这些操作都在链下完成，Tornado合约和外界观察者都无法知晓K和r。如果K和r泄露，就相当于钱包私钥被盗。

Tornado合约收到用户存款和提交的Cn=Hash(K,r)后，将Cn作为新叶子节点加入Merkle树，并更新Root值。但Merkle Tree的叶子节点并不存入合约状态，仅作为event参数记录在区块中。合约只保存merkle root，提款时用户通过merkle Proof证明存款记录对应现有merkle root即可，这与轻客户端跨链桥的提款原理类似。

这一设计展现了Tornado的巧妙之处：为节省gas费，不将完整merkle tree存入合约状态，仅记录root；将叶子节点作为event数据存入历史区块，这与Rollup节省gas成本的思路异曲同工。

提款时，用户在前端输入凭证（随机数K和r），Tornado Cash前端程序会使用K、r、Cn=Hash(K,r)及对应的Merkle Proof作为输入参数，生成ZK Proof，证明Cn是Merkle Tree上的有效存款记录，且K和r是其对应凭证。

这相当于证明：我知道Merkle Tree上某笔存款记录对应的密钥。提交给Tornado合约的ZK Proof会隐藏这4个参数，外界（包括合约）都无法获知，确保了隐私性。

生成ZKProof还涉及其他参数：提款时Merkle Tree的根root、自定义收款地址A、防重放攻击标识符nf。这3个参数会公开上链，但不影响隐私。

这里有个细节：生成Cn时使用了两个随机数K和r，而非单个随机数，这是为了提高安全性，防止暴力破解。

图中的A代表提款接收地址，由用户自行填写。nf是防重放攻击标识符，其值为nf=Hash(K)，K是生成Cn时使用的两个随机数之一。这样nf就与Cn关联起来，每个Cn都有对应的nf。

为什么需要防重放攻击？由于混币器的特性，提款时无法确定提款对应哪个叶子节点Cn，也就无法知道提款人与哪些存款人关联，更无法确认存款次数。提款者可能利用这点频繁提款，直到抽干资金池。

nf的作用类似于以太坊地址的交易计数器nonce，都是为了防止交易重放。提款时需要提交nf，检查是否已被使用：若已使用，提款无效；若未使用，则记录该nf，后续相同nf的提款将被拒绝。

能否随意生成一个合约未记录的nf？不行，因为生成ZK Proof时需要保证nf=Hash(K)，而K与存款记录Cn关联。随意编造的nf无法对应任何存款记录，也就无法生成有效ZK Proof，提款操作自然失败。

有人可能会问：能否不用nf？既然提款需要ZK证明与某个Cn关联，检查ZK Proof是否已提交不就可以了吗？但实际上，永久存储所有ZK Proof会严重浪费存储空间。相比之下，设置小巧的nf标识符并永久存储更为经济。

提款函数的参数和逻辑如下：用户提交ZKProof、nf=Hash(K)，自定义收款地址recipent。ZKProof隐藏了Cn、K和r的数值，保护用户隐私。recipent通常使用新地址，避免个人信息泄露。

这里有个小问题：为保持匿名，提款常使用新地址，但新地址没有ETH支付gas费。因此提款时需要声明一个中继者relayer代付gas费，合约会从提款中扣除部分给relayer作为报酬。

综上所述，TornadoCash能有效隐藏存取款者间的关联。当用户量足够大时，就像罪犯混入人群难以追踪。提款过程依赖ZK-SNARK技术，被隐藏的witness部分包含关键信息，这是混币器最精妙的设计。可以说，Tornado是目前ZK技术最巧妙的应用层项目之一。