LOADING...
LOADING...
LOADING...
当前位置: 玩币圈首页 > 区块链资产 > 回看TornadoCash原理:监管者的眼中钉却是最精妙的ZK应用

回看TornadoCash原理:监管者的眼中钉却是最精妙的ZK应用

2023-09-10 极客 Web3 来源:区块链网络

作者:Faust,极客web3

导语:近期Vitalik和一些学者联名发表了新论文,其中提到了Tornado Cash如何实现反xi钱方案(其实就是让取款人证明,自己的存款记录属于一个不包含黑钱的集合),但文中缺乏对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的主要思路是:把大量的存取款行为混杂在一起,存款者在Tornado存入Token后,出示ZK Proof证明自己存过款,再用一个新地址提款,以此切断存取款地址之间的关联性。

更具体的概括,Tornado就像一个玻璃箱,混杂了很多人放进去的Coin硬币。我们能看到放Coin的是哪些人,但这些Coin高度同质化,如果有生面孔的人从玻璃箱拿走一枚Coin,我们很难知道他拿走的Coin最初是谁放进去的。

这种场景似乎屡见不鲜:当我们从Uniswap池子里SWAP几枚ETH时,根本无法知道划走的ETH是谁提供的,因为曾给Uniswap提供流动性的人太多了。但不同之处是,每次用Uniswap划走Token,我们需要用其他Token作为等价的成本,且不能把资金“私密的”转让给别人;而混币器只需要提款者出示存款凭证就行。

为了让存取款动作看起来有同质性,Tornado池子的存款地址每次存入的资金、取款地址每次取出的资金都保持一致,比如某个池子的100个存款者和100名取款者,虽然公开可见,但看起来彼此没有任何联系,而且每人存入的金额、取出的金额,都是一样的。这时就可以混淆视听,没法按照存取款金额判断关联性,进而切断资金转移痕迹,显而易见的是,这为xi钱行为提供了天然的便利。

但有一个关键问题:取款者在提款时,怎么证明自己存过款?向混币器发起取款的地址,与所有的存款地址都不关联,那么该如何判断他的提款资格?看起来最直接的方法,是取款者直接披露自己的存款记录是哪一笔,但这就直接泄露了身份。此时零知识证明就派上了用场。

提款者出具一个ZK Proof,证明自己在Tornado合约里有存款记录,且该笔存款尚未被提取,就能顺利发起取款。零知识证明本身就实现了隐私保护,外界只知道:取款人的确往资金池里存过款,但不知道他对应哪个存款者。

要证明“我在Tornado资金池里存过款”可以被转化为“我的存款记录可以在Tornado合约里找到”。如果用Cn表示存款记录,问题就归纳为:

已知Tornado的存款记录集合为{C1,C2,…C100…},取款者Bob证明自己曾用手上的密钥,生成了存款记录里的某个Cn,但通过ZK不泄露Cn具体是哪个。

这里要用到Merkle Proof的特殊性质。因为Tornado的所有存款记录,都存进了链上构造的一棵MerkleTree,作为其最底层的叶子结点,而叶子总数约为2的20次幂>100万,大多数都处于空白状态(赋予了初始值)。每当有新存款行为产生时,合约就会把其对应的特征值Commitment写入一个叶子里,然后更新Merkle Tree的root。

比如,Bob的存款操作是Tornado有史以来第1万笔,那么与这笔存款有关联的一个特征值Cn会写入Merkle Tree的第1万个叶子结点,也即C10000= Cn。然后合约会自动算出新的Root,update一下。(ps:为了节约计算量,Tornado合约会缓存之前一批有变化的节点的数据,比如下图中的Fs1和Fs2、Fs0)

而MerkleProof本身很简洁轻便,它利用了树状数据结构在检索/溯源过程中的简洁性。若想对外证明某笔交易TD存在于MerkleTree中,只要给出Root对应的MerkleProof(如下图中右边的部分),它相当简洁。如果Merkle Tree格外庞大,底层叶子有2的20次幂个,也就是包含100万笔存款记录,Merkle Proof也只需要包含21个节点的数值,非常短。

如果要证明某笔交易H3的确包含在Merkle Tree中,设法证明用H3和Merkle Tree上其他的部分数据,可以生成Root,而生成Root所需要的那部分数据(包括Td在内)就构成了Merkle Proof。

而Bob在取款时,要证明自己拥有的凭证对应着Merkle Tree上有记录的某笔存款哈希Cn。也就是说,他要证明两件事:

·Cn存在于链上Tornado合约里的Merkle Tree中,具体可以构造一个Merkle Proof,里面包含Cn;

·Cn与Bob手上的存款凭证有关联。

Tornado业务逻辑详解

Tornado用户界面的前端代码中事先实现了很多功能,当一名存款者打开TornadoCash网页并点击存款按钮后,前端代码附带的程序会在本地生成2个随机数K和r,随后会计算出Cn=Hash(K,r)的值,再把Cn(就是下图中的commitment)传入Tornado合约,插入到后者记录的Merkle Tree里。说白了,K和r相当于私钥。它们很重要,系统会提示用户妥善保存。后面提款时仍然要用到K和r。

值得注意的是,以上工作皆发生于链下,也就是说:Tornado合约和外界观察者都不知晓K和r。如果K和r被泄露了,就类似于钱包私钥被盗。

Tornado合约收到用户存款,并收到用户提交的Cn=Hash(K,r)后,便将Cn插入到Merkle树的最底层,作为新的叶子结点,同时会更新Root的数值。所以,Cn和用户的存款动作是一对一关联的,外界可以知道每个Cn对应着哪个用户,知道有哪些人往混币器里存入了Token,并且知道每个存款者对应的存款记录Cn。

在取款步骤中,取款者在前端网页里输入凭证/私钥(存款时生成的随机数K和r),TornadoCash前端代码中的程序会使用K和r、Cn=Hash(K,r)、Cn对应的Merkle Proof作为输入参数,生成ZK Proof,证明Cn是存在于Merkle Tree上的某笔存款记录,而K和r是对应Cn的凭证。

这一步就相当于证明:我知道某笔记录于Merkle Tree上的存款记录对应的密钥。当ZK Proof被提交给Tornado合约时,上述4个参数均被隐藏,外界(包括Tornado合约)无法获知,借此保障了隐私。

生成ZKProof涉及的其他参数还包括:取款时Tornado合约里Merkle Tree的根root、自定义的收款地址A、防止重放攻击的标识符nf(后面会讲)。这3个参数会公开发布到链上,外界可以获知,但不影响隐私。

这里面有个细节,就是存款操作生成Cn时,用了2个随机数K和r来生成Cn,而不是单个随机数。这是因为单个随机数不够安全,有一定概率发生碰撞,比如,采用单随机数可能导致两个不同的存款者恰巧采用1个同样的随机数,导致生成的Cn撞车。

至于上图中的A,代表接收提款的地址,由提款者自己填写。nf则是一个防止重放攻击的标识符,其数值nf=Hash(K),K就是存款生成Cn那一步用到的2个随机数之一(K和r)。这样一来,nf就与Cn关联了起来,换言之,每个Cn都有对应的nf,两者一一关联。

为什么要防止重放攻击呢?由于混币器在设计上的特性,取款时不知道用户提走的币对应Merkle树的哪个叶子Cn,也就不知道提款人和哪些存款人关联,就不知道提款人到底存过几次款。提款者可以利用这一特性频繁提款,发起重放攻击,多次从混币器池里取走Token,直到把资金池抽干。

在这里,nf标识符的作用类似于每个以太坊地址都有的交易计数器nonce,都是为了防止某笔交易被重放而设置。当一笔取款发生时,取款者需要提交一个nf,检查这个nf是否已被使用过(记录在案):如果有,此次取款无效。如果没有,表示该nf尚未被使用,取款有效,对应的nf会被记录下来。下次再有人提交这个nf时,对应的取款动作直接判定为无效。

如果有人胡乱生成一个合约没记录过的nf行不行?当然不行,因为取款者生成ZK Proof时,需要保证nf=Hash(K),而随机数K与存款记录Cn关联,也就是说,nf与某笔有记录的存款Cn关联。如果随便编造一个nf,这个nf与存款记录中的所有存款都对不上号,就不能顺利生成有效的ZK Proof,后续的工作就无法顺利完成,取款操作就不会成功。

可能也有人会问:不用nf行不行?既然提款者在提款时需要提交ZK证明,证明自己和某个Cn有关联,那么每当提款动作发生时,查找对应的ZK Proof是否被提交到链上过,不就行了吗?

但事实上,这样做的成本很高,因为Tornado cash合约不会永久存储过去提交的ZK Proof,因为这会严重浪费存储空间。与其比较每个新交到链上的ZKProof和既有的Proof是否一致,还不如设置个占地很小的标识符nf并将其永久存储来的更划算。

按照取款函数的代码示例,其需要的参数和业务逻辑如下:

用户提交ZKProof、nf(NullifierHash)=Hash(K),自定义一个接收提款的地址recipent,ZKProof隐藏了Cn和K、r的数值,让外界无法获取判断用户身份。recipent往往会填写一个干净的新地址,也不会泄露个人信息。

但这里面有个小问题,就是用户在取款时,为了不可溯源,往往用新申请的地址发起取款交易,此时新地址没有ETH来支付gas费。所以取款地址发起取款时,要显式声明一个中继者relayer,由它代付gas费,之后混币器合约会直接从用户提款里扣掉一部分交给relayer,作为回报。

综上所述,TornadoCash可以隐瞒取款者与存款者的关联,在用户量很大的情况下,就如同一个闹市区,犯人混进人群后警方就难以追踪。取款过程中需要用到ZK-SNARK,被隐藏起来的witness部分包含取款人关键信息,这是整个混币器最关键的一点。目前看来,Tornado可能是与ZK相关的最巧妙的应用层项目之一。

参考资料

1.https://etherscan.io/address/0xa160cdab225685da1d56aa342ad8841c3b53f291#codeTornado合约源码

2.https://mirror.xyz/mazemax.eth/BTbTOrEKzGkc-XoDcFtLPfJPtQ1Mt96BZYsW83m33IUTornado.cash新旧版机制对比

3.https://www.youtube.com/watch?v=Z0s4W3UBxM8AnonymousPayments

4.https://medium.com/taipei-ethereum-meetup/zkp-study-group-tornado-cash-fdbb84d44b93[ZKP讀書會]TornadoCash

5.https://medium.com/taipei-ethereum-meetup/tornado-cash-%E5%AF%A6%E4%BE%8B%E8%A7%A3%E6%9E%90-eb84db35de04TornadoCash實例解析

查看更多

—-

编译者/作者:极客 Web3

玩币圈申明:玩币圈作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币圈平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...