编者按：本文来自安比实验室，作者：p0n1，Odaily星球日报经授权转载。大量零知识证明项目由于错误地使用了某个zkSNARKs合约库，引入「输入假名(InputAliasing)」漏洞，可导致伪造证明、双花、重放等攻击行为发生，且攻击成本极低。众多以太坊社区开源项目受影响，其中包括三大最常用的zkSNARKs零知开发库snarkjs、ethsnarks、ZoKrates，以及近期大热的三个混币应用hopper、Heiswap、Miximus。这是一场由Solidity语言之父Chris两年前随手贴的一段代码而引发的血案。双花漏洞：最初暴露的问题
semaphore是一个使用零知识证明技术的匿名信号系统，该项目由著名开发者barryWhiteHat此前的混币项目演化而来。俄罗斯开发者poma最先指出该项目可能存在双花漏洞。问题出在第83行代码，请仔细看。该函数需要调用者构造一个零知识证明，证明自己可从合约中提走钱。为了防止「双花」发生，该函数还读取「废弃列表」，检查该证明的一个指定元素是否被标记过。如果该证明在废弃列表中，则合约判定校验不通过，调用者无法提走钱。开发者认为，这样一来相同的证明就无法被重复提交获利，认为此举可以有效防范双花或重放攻击。然而事与愿违，这里忽视了一个致命问题。攻击者可根据已成功提交的证明，利用「输入假名」漏洞，对原输入稍加修改便能迅速「伪造证明」，顺利通过合约第82行的零知识证明校验，并绕过第83行的防双花检查。该问题最早可追溯到2017年，由ChristianReitwiessner大神，也就是Solidity语言的发明者，提供的zkSNARKs合约密码学实现示例。其后，几乎以太坊上所有使用zkSNARKs技术的合约，都照用了该实现。因此都可能遭受以下流程的攻击。混币应用：该安全问题的重灾区
数据：zkSync参与桥接交易的用户量突破90万:金色财经报道，据 Dune Analytics 数据显示，以太坊 Layer2 扩容解决方案 zkSync 跨链桥接参与桥接交易的用户量突破90万，本文撰写时达到903,093个，跨链桥接存储总价值为280,661 ETH，按照当前ETH价格计算约合5.34亿美元。[2023/6/4 11:56:18]
零知识证明技术在以太坊上最早和最广泛的应用场景是混币合约，或匿名转账、隐私交易。由于以太坊本身不支持匿名交易，而社区对于隐私保护的呼声越来越强烈，因此涌现出不少热门项目。这里以混币合约的应用场景为例，介绍「输入假名」漏洞对零知项目的安全威胁。混币合约或匿名转账涉及两个要点：1.证明自己有一笔钱2.证明这笔钱没有花过为了方便理解，这里简单描述一下流程：1.A要花一笔钱。2.A要证明自己拥有这笔钱。A出示一个zkproof，证明自己知道一个hash(HashA)的preimage，且这个hash在以root为标志的tree的叶子上，且证明这个preimage的另一种hash是HashB。其中HashA是witness，HashB是publicstatement。由于A无需暴露HashA，所以是匿名的。3.合约校验zkproof，并检查HashB是否在废弃列表中。若不在，则意味着这笔钱未花过，可以花。4.如果可以花，合约需要把HashB放入废弃列表中，标明以HashB为代表的钱已经被花过，不能再次花了。上面代码中的第82行verifyProof(a,b,c,input)用来证明这笔钱的合法性，input是publicstatement，即公共参数。第83行通过require(nullifiers_set]==false)校验这笔钱是否被花过。很多zkSNARKs合约尤其是混币合约，核心逻辑都与第82行和83行类似，因此都存在同样的安全问题，可利用「输入假名」漏洞进行攻击。漏洞解析：一笔钱如何匿名地重复花5次？
zkSync：zkSync Era执行延迟安全机制将允许有足够时间检测问题并及时作出反应:3月24日消息，zkSync介绍zkSync Era多层安全机制中的其中一种机制，即执行延迟，执行延迟意味着每个提交给L1的L2块在执行和最终确定之前都会有一个时间锁，最初该延迟将是24小时，随着系统的成熟，该延迟将逐渐减少，直到移除Alpha阶段，届时延迟将被完全移除。延迟主要是确保团队有足够的时间在区块成为最终区块之前验证包含在区块中的交易的影响，并且有足够的时间来检测漏洞、调查并通过治理冻结协议。
此前报道，2月中旬zkSync宣布上线Fair Onboarding Alpha主网，在此阶段，主网对最终用户保持关闭，注册项目可以在系统向外部用户开放之前在封闭环境中部署和测试应用程序。同时，zkSync 2.0更名为zkSync Era，zkSync 1.0更名为zkSync Lite。根据zkSync Era路线图，下一个里程碑是zkSync Era公开发布。[2023/3/24 13:23:41]
上面verifyProof(a,b,c,input)函数的作用是根据传入的数值在椭圆曲线上进行计算校验，核心用到了名为scalar_mul()的函数，实现了椭圆曲线上的标量乘法。我们知道以太坊内置了多个预编译合约，进行椭圆曲线上的密码学运算，降低zkSNARKs验证在链上的Gas消耗。函数scalar_mul()的实现则调用了以太坊预编译7号合约，根据EIP196实现了椭圆曲线alt_bn128上的标量乘法。下图为黄皮书中对该操作的定义，我们常称之为ECMUL或ecc_mul。密码学中，椭圆曲线的{x,y}的值域是一个基于modp的有限域，这个有限域称之为Zp或Fp。也就是说，一个椭圆曲线上的一个点{x,y}中的x,y是Fp中的值。一条椭圆曲线上的某些点构成一个较大的循环群，这些点的个数称之为群的阶，记为q。基于椭圆曲线的加密就在这个循环群中进行。如果这个循环群的阶数为质数，那么加密就可以在modq的有限域中进行，该有限域记作Fq。一般选取较大的循环群作为加密计算的基础。在循环群中，任意选定一个非无穷远点作为生成元G，其他所有的点都可以通过G+G+....产生出来。这个群里的元素个数为q，也即一共有q个点，那么我们可以用0,1,2,3,....q-1来编号每一个点。在这里第0个点是无穷远点，点1就是刚才提到的那个G，也叫做基点。点2就是G+G，点3就是G+G+G。于是当要表示一个点的时候，我们有两种方式。第一种是给出这个点的坐标{x,y}，这里x,y属于Fp。第二种方式是用n*G的方式给出，由于G是公开的，于是只要给出n就行了。n属于Fq。看一下scalar_mul(G1Pointpoint,uints)函数签名，以point为生成元，计算point+point+.....+point，一共n个point相加。这属于使用上面第二种方法表示循环群中的一个点。在Solidity智能合约实现中需要使用uint256类型来编码Fq，但uint256类型的最大值是大于q值，那么会出现这样一种情况：在uint256中有多个数经过mod运算之后都会对应到同一个Fq中的值。比如s和s+q表示的其实是同一个点，即第s个点。这是因为在循环群中点q其实等价于点0。同理，s+2q等均对应到点s。我们把可以输入多个大整数会对应到同一个Fq中的值这一现象称作「输入假名」，即这些数互为假名。以太坊7号合约实现的椭圆曲线是y^2=ax^3+bx+c。p和q分别如下。这里的q值即上文中提到的群的阶数。那么在uint256类型范围内，共有uint256_max/q个，算下来也就是最多会有5个整数代表同一个点。这意味着什么呢？让我们回顾上面调用scalar_mul(G1Pointpoint,uints)的verifyProof(a,b,c,input)函数，input数组里的每个元素实际就是s。对于每个s，在uint256数据类型范围内，会最多存在其他4个值，传入后计算结果与原值一致。因此，当用户向合约出示零知识证明进行提现后，合约会把input放入作废列表。用户还可以使用另外4个值再次进行证明提交。而这4个值之前并没有被列入「废弃列表」，因此“伪造”的证明可以顺利通过校验，利用5个「输入假名」一笔钱可以被重复花5次，而且攻击成本非常低！还有更多受影响的项目
数据：昨日桥接ETH至zkSync与StarkNet笔数均创单日历史新高:3月20日消息，据 Dune 数据显示，昨日共有 17,012 笔交易将 2237.6 枚 ETH 桥接至 zkSync，共有 8572 笔交易将 858.5 枚 ETH 桥接至 StarkNet，跨链桥接 ETH 至 zkSync 与 StarkNet 网络的笔数均创单日历史新高。[2023/3/20 13:15:07]
存在问题的远远不止semaphore一个。其他很多以太坊混币项目以及zkSNARKs项目都存在同样的允许「输入假名」的问题。这当中，影响最大的要数几个大名鼎鼎的zkSNARKs库或框架项目，包括snarkjs、ethsnarks、ZoKrates等。许多应用项目会直接引用或参考他们的代码进行开发，从而埋下安全隐患。因此，上述三个项目迅速进行了安全修复更新。另外，多个利用了zkSNARKs技术的知名混币项目，如hopper、Heiswap、Miximus也立刻进行了同步修复。这些项目在社区热度都十分高，其中Heiswap更是被人们称为「Vitalik最喜爱的项目」。「输入假名」漏洞的解决方案
事实上，所有使用了该zkSNARKs密码学合约库的项目都应该立即开展自查，评估是否受影响。那么应该如何修复这个问题？所幸的是，修复很简单。仅需在验证函数中添加对输入参数大小的校验，强制要求input值小于上面提到的q值。即严禁「输入假名」，杜绝使用多个数表示同一个点。暴露的深层问题值得反思
在zkSync上部署Uniswap V3的提案获得通过:金色财经报道，据相关页面信息显示，在zkSync上部署Uniswap V3的提案已结束。超4000万票赞成，预计将在4-6周内完成部署。
根据提案，尽早部署Uniswap将“巩固Uniswap作为第一大DEX和思想领袖的地位”。它应该有助于Uniswap建立先发优势。更重要的是，Uniswap DAO 治理将留在以太坊L1上。zkSync将使用L1<>L2通信桥来支持任意消息传递以进行治理。[2022/10/14 14:27:08]
该「输入假名」导致的安全漏洞值得社区认真反思。我们再回顾一下整个故事。2017年Christian在Gist网站贴出了自己的zkSNARKs合约计算实现。作为计算库，我们可以认为他的实现并没有安全问题，没有违反任何密码学常识，完美地完成了在合约中进行证明验证的工作。事实上，作为Solidity语言的发明者，Christian在这里当然不会犯任何低级错误。而两年后的今天，这段代码却引发了如此的安全风波。两年多的时间内，可能有无数同行和专家看过或使用过这段只有两百多行的代码，却没有发现任何问题。核心问题出在哪里？可能出在底层库的实现者和库的使用者双方间对于程序接口的理解出现了偏差。换句话说：底层库的实现者对于应用开发者的不当使用方式欠缺考虑；而上层应用开发者没有在使用中没有深入理解底层实现原理和注意事项，进行了错误的安全假设。所幸的是，目前常见的zkSNARKs合约库都火速进行了更新，从底层库层面杜绝「输入假名」。安比实验室认为，底层库的更新诚然能够很大程度上消除掉后续使用者的安全隐患，但若该问题的严重性没有得到广泛地宣传和传播，依旧会有开发者不幸使用到错误版本的代码，或者是根据错误的教程进行开发，从而埋下安全隐患。「输入假名」漏洞不禁让我们回想起此前频繁曝出的「整数溢出」漏洞。二者相似之处颇多：都是源于大量开发者的错误假设；都与Solidity里的uint256类型有关；波及面都十分广；网络上也都流传着很多存在隐患的教程代码或者库合约。但显然「输入假名」漏洞显然更难检测，潜伏时间更长，需要的背景知识更多。安比实验室认为，随着zkSNARKs、零知识证明应用、隐私技术的兴起，社区会涌现出更多的新应用，而背后暗藏的更多安全威胁可能会进一步暴露出来。希望这波新技术浪潮中，社区能充分吸收以往的惨痛教训，重视安全问题。参考文献https://github.com/https://github.com/https://gist.github.com/https://github.com/https://github.com/
ZKSwap将临时移除Uniswap上的流动性:2021年2月5日 据ZKSwap（zks.org） 团队透露，ZKS 将在接下来的72小时内，完成4次快照和空投发放，并在第一次快照之前的24小时内，短暂移除Uniswap 上的流动性池子（ZKS/USDT），并在空投的4000万ZKS 发放完毕的48小时之内，重新添加Uniswap 的流动性池子，考虑到本次空投后，ZKS 流通量从4000万个增加到8000个，为了避免价格的剧烈变化，重新添加Uniswap流动性的时候，如果市场价格高于移除流动性时价格的50%， 那么将会按照市场价格添加流动性；如果空投后，市场价格低于移除流动性时价格的50%， 那么将会按照移除流动性时的价格的50% 添加流动性。ZKSwap 团队也希望其他在Uniswap上提供流动性的社区成员，可以暂时移除流动性，并在空投结束后，重新添加流动性。ZKSwap空投完毕后，将会全力准备ZKSwap 主网上线，并开启一系列的流动性挖矿和交易挖矿活动。[2021/2/5 18:58:15]
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。