导语：近期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年底发布了新版本的测试版。旧版Tornado Cash在去中心化方面做得相当出色，其链上合约完全开源且不设多签控制，前端代码不仅开源还备份在IPFS网络中。考虑到旧版架构更为简洁明了，本文将重点解析旧版的工作原理。
Tornado Cash的核心设计理念是通过汇集大量存取款交易来混淆视听。用户存入代币后，只需出示ZK Proof证明自己曾存款，就能用新地址提取资金，从而切断存取款地址之间的关联性。
形象地说，Tornado就像一个透明的玻璃箱，里面堆满了众人投入的硬币。虽然我们能看清是谁放入了硬币，但由于硬币的高度同质化，当陌生人从中取走一枚时，我们很难追溯这枚硬币最初的主人。
（图源：rareskills）这种场景其实并不陌生：当我们在Uniswap池子里兑换ETH时，根本无法确认这些ETH来自哪个流动性提供者。但关键区别在于，使用Uniswap需要支付等值代币作为交换，且无法实现资金的私密转移；而混币器仅需提款者出示存款凭证即可。
为了确保存取款行为的一致性，Tornado池子设定了标准化的存取金额。比如某个池子的100名存款者和100名取款者，虽然交易记录公开可查，但每人存取金额完全相同，这就有效切断了资金流转的痕迹。这种设计在提供隐私保护的同时，也不可避免地为洗钱行为创造了便利条件。
这里引出一个关键问题：取款者如何在不暴露身份的情况下证明自己的存款记录？最直接的方法是披露具体存款记录，但这显然会泄露隐私。零知识证明的巧妙之处就在于，它允许取款者在不透露任何敏感信息的前提下，证明自己确实在Tornado合约中有未提取的存款记录。
这个证明过程可以转化为一个数学问题：已知Tornado的存款记录集合为{C1，C2，…C100…}，取款者Bob需要证明自己持有的密钥能生成其中的某个Cn，但又不透露具体是哪一个。这就要用到Merkle Tree的特殊性质。
Tornado将所有存款记录组织成一棵Merkle Tree，每个新存款都会生成一个特征值Commitment作为叶子节点，并更新Merkle Root。例如Bob的第1万笔存款会记录在第1万个叶子节点C10000=Cn，合约随后会计算新的Root值。（注：为优化计算效率，Tornado合约会缓存最近发生变化的节点数据）
（图源：RareSkills）Merkle Proof的优势在于其简洁性。即便Merkle Tree包含超过100万个叶子节点，验证某笔交易存在的证明也仅需21个节点数值。
取款时，Bob需要证明两件事：一是Cn确实存在于Merkle Tree中，这可以通过构造包含Cn的Merkle Proof来实现；二是证明自己持有的存款凭证与Cn存在关联。
深入解析Tornado业务逻辑
当用户在Tornado Cash界面点击存款按钮时，前端代码会在本地生成两个随机数K和r，计算出Cn=Hash(K，r)的值后，将这个commitment提交给Tornado合约，存入Merkle Tree。这里的K和r相当于私钥，用户必须妥善保管，因为后续取款时仍需使用。
（encryptedNote是可选项，允许用户用私钥加密凭证K和r并存储在链上以防丢失）需要强调的是，这些操作都发生在链下，Tornado合约和外部观察者都无法获取K和r。一旦这些凭证泄露，就相当于钱包私钥被盗。
Tornado合约收到存款后，会将Cn记录为Merkle Tree的新叶子节点并更新Root值。因此，每个Cn都对应着特定的存款行为，外界可以观察到哪些地址进行了存款，以及对应的Cn值。
取款时，用户在前端输入凭证K和r，系统会使用这些参数生成ZK Proof，证明Cn存在于Merkle Tree中且与用户持有的凭证对应。这个过程中，所有关键参数都被隐藏，既保护了隐私，又验证了取款资格。同时公开的参数包括：当前Merkle root、收款地址A和防重放攻击标识符nf。
设计上采用两个随机数K和r生成Cn是出于安全考虑，单一随机数可能导致碰撞风险。其中nf=Hash(K)作为防重放攻击的标识符，与Cn一一对应。这个机制类似于以太坊的nonce，确保每笔取款只能执行一次。
如果没有nf机制，虽然可以通过检查ZK Proof是否重复来防止重放攻击，但这会带来巨大的存储开销。相比之下，记录小巧的nf标识符是更经济的解决方案。
取款函数的参数设计体现了精妙的平衡：用户提交的ZK Proof隐藏了关键信息，自定义的收款地址通常为新创建地址，而nf则确保交易唯一性。不过这里存在一个小问题：新创建的取款地址往往没有ETH支付gas费，因此系统允许用户指定中继者(relayer)代付gas，费用从提款金额中扣除。
综上所述，Tornado Cash通过巧妙的密码学设计，在用户基数足够大的情况下，就像让目标消失在茫茫人海中。其中ZK-SNARK技术的应用尤为关键，它成功隐藏了取款人的关键信息。可以说，Tornado是目前将ZK技术应用于实际场景中最精妙的项目之一。
声明：文章不代表CHAINTT观点及立场，不构成本平台任何投资建议。投资决策需建立在独立思考之上，本文内容仅供参考，风险 自担！转载请注明出处：https://www.chaintt.cn/11908.html
