长推：技术复盘Curve被攻击的过程
简单看了下Curve被攻击的过程和相关代码, 来做一个简单的技术向复盘.
原文作者：Eric Lee
原文来源：twitter
注：本文来自@Yang1127LI 推特，CHAINLOOK整理如下：
简单看了下Curve被攻击的过程和相关代码, 来做一个简单的技术向复盘.
(适合新手学习整个过程) #Curve #Reentrancy #DeFi
PS: 除了最初的学习阶段, 我从来不使用也不会建议别人使用Vyper, 它的开发者人数远少于Solidity, 少了很多去踩坑和验证这个语言特性的开发者, 也少了很多社区的支持.
哪些池子被攻击了, 原因是什么?
主要是 alETH, msETH, pETH等池子, 它们被攻击的原因都是同一个, 使用了特定几个版本的Vyper编译器, 在Reentrancy Guard(防重入)功能上出现了问题, 导致了被重入攻击.
（使用了0.2.15版本Vyper的Curve Pool）
https://twitter.com/vyperlang/status/1685692973051498497
攻击流程
以alETH为例, 攻击交易为https://explorer.phalcon.xyz/tx/eth/0xb676d789bb8b66a08105c844a49c2bcffb400e5c1cfabd4bc30cca4bff3c9801…
可以看到, 攻击者部署了一个用于攻击的智能合约, 利用Balancer的闪电贷获取本金(40000ETH), 通过若干次add_liquidity和remove_liquidity的调用获得了攻击收益(~22M USD).
攻击细节1
其中的重入攻击发生在第一次调用remove_liquidity函数时.
被重入的remove_liquidity函数代码如图.
在图中, 26行是移除流动性过程中给用户发送ETH的逻辑, 而41~43行更新用户的LP Token余额以及totalSupply都是在这个操作之后.
这就是常见的被重入攻击的代码特点: 先转账后更新状态.
攻击细节2
接下来重入调用的add_liquidity函数如下图.
攻击者在remove liquidity中途给他发送15146个ETH时, 用fallback函数重入调用add liquidity函数, 此时因为total supply还没有更新, 导致37行处应该mint给用户的LP Token的数量计算变大了, 也就是这次他用20000个ETH得到了34277个LP Token.
攻击细节3
之后他便可以用多出的很多LP Token去正常地移除流动性, 拿到超出正常的ETH数量.
之后还掉闪电贷之后 获利 7258 WETH + 4821 alETH
Vyper的重入锁
这里虽然Curve的代码写法有潜在的重入风险, 但被攻击的原因还是Vyper的重入锁问题.
Vyper重入锁的实现原理: 在某个storage slot存入一个value, 函数执行时会检该值是否为1, 如果没有就把它设置为1. 这是一个很常见的重入锁的实现.
关于【长推：技术复盘Curve被攻击的过程】的延伸阅读
Base 链 DEX —— Aerodrome VS Curve
Velodrome是一个成功的DeFi案例，通过改进veCRV模板，实现了更优越的DEX模式。与Curve不同，Velodrome的流动性提供者不收取交易费用，而是通过VELO代币排放获得激励。通过仪表投票，veCRV/veVELO持有者决定每周发行的CRV/VELO代币分配比例。Velodrome避免了其他协议吞噬供应的可能性，并提供了类似于Convex的功能，但更简单。它正在成为超级链的基础流动性中心，可能会改变游戏规则。Velodrome已在Optimism上取得巨大成功，其产品套件包括收取和分配费用的DEX部分。
流动性提供者的博弈，Curve债务难题何解？
当场外交易的CRV变得可流动时，Curve将不得不经历另一次压力测试。
例如Curve中就是用"lock"来代表这个slot
Vyper重入锁的漏洞
Curve的add/remove liquidity函数的重入锁中都用了"lock"来代表他们想共用一个重入锁.
但Vyper的重入锁在某些版本中, 每次都会移动到一个新的slot中, 而不会判断他们是否想使用同一个slot(左侧50行).
在图中的commit里面, 右侧42~43行修复了这一操作, 添加了同名检查
受影响的编译器版本: v0.2.15 ~ v0.3.0
这个漏洞在v0.3.1中被修复 (修复时间 2021.10.25)
https://github.com/vyperlang/vyper/commit/eae0eaf86eb462746e4867352126f6c1dd43302f
但是被影响的Curve Pool的代码却一直没有发现自己中间隐藏的问题
总结1
Curve Pool对于重入锁的使用思路是正常的, 但是对于语言中对于重入锁的具体实现是否完成了自己预想的功能并没有充分地检查. 这样的问题在测试中是可以被发现的.
预想的功能为: 防止add/remove liquidity函数之间的相互重入, 那么测试一定要覆盖这个场景. 并不会存在想不到的问题
总结2
Vyper有没有问题, 肯定是有的, 重入锁实现中出现这样的错误可以算是一个低级错误了.
另外因为重入锁是内嵌在Vyper语言特性中, 并通过@修饰词来调用的, 也会让开发者经常忽略了这些修饰器内部实现是否正确(在传统编程里面同样问题, 但不会直接导致丢钱).
总结3
Curve Pool的部署模式是每个池子有自己的合约, 他们使用的Vyper版本也会随着时间而变化.
这不同于UniswapV2中最常见的工厂合约模式, 所有Pool都有相同的代码和版本.
另外池子无法被暂停, 也无法升级, 在保证不可篡改的同时也丢失了灵活性.
最后观点: 不是唱衰Vyper, 也不是说智能合约只能有一种编程语言.
而是:
1)对于新手学习以及要上线的项目来说, 选择最大众的开发语言永远是更好的.
2)在DeFi这样的对于合约安全性是第一要务的编程场景来讲, 一个相对于主流语言基本带来不了本质提升的编程语言是没有存在的必要的.
最后, 还在学习Vyper, 以及支持在DeFi中使用Vyper的, 很想听到大家为什么还会使用它.
像Python? 编译字节码更短?
WTF is the usage of these features?
免责声明：本文仅代表作者个人观点，不代表链观CHAINLOOK立场，不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险，以及遵守所在国家和地区的相关法律法规。
图文来源：Eric Lee，如有侵权请联系删除。转载或引用请注明文章出处！
标签：Curve
