近期的Curve池漏洞与我们在过去几年里看到的大多数加密货币黑客事件有所不同，因为与之前的许多漏洞不同，这一次并不直接与智能合约本身的漏洞有关，而是与它所使用的语言的底层编译器有关。

在这里，我们谈论的是Vyper：一个面向智能合约的、具有Pythonic风格的编程语言，旨在与以太坊虚拟机（EVM）交互。我对此次漏洞的背后原因非常感兴趣，所以我决定深入研究。

随着这次漏洞的发展，每天的新闻头条都在报告新的数字。现在看来，情况终于得到了控制，但在此之前已经有超过7000万美元被盗。根据LlamaRisk的事后评估，截止到今天，有几个DeFi项目的池子也被黑客攻破，包括PEGD的pETH/ETH: 1100万美元；Metronome的msETH/ETH: 340万美元；Alchemix的alETH/ETH: 2260万美元；和Curve DAO: 大约2470万美元。

这次漏洞被称为重入错误，它是在Vyper编程语言的某些版本上出现的，特别是v0.2.15、v0.2.16和v0.3.0。因此，使用这些特定版本的Vyper的所有项目都可能成为攻击的目标。

什么是重入（reentrancy）？

为了理解这次漏洞为什么会发生，我们首先需要了解什么是重入以及它是如何工作的。

如果一个函数在执行过程中可以被中断，并且在其之前的调用完成执行之前可以安全地再次被调用（「重新进入」），则称该函数为可重入的。可重入函数在硬件中断处理、递归等应用中都有使用。

为了使一个函数变得可重入，它需要满足以下条件：

- 它不能使用全局和静态数据。这只是一种约定，没有硬性的限制，但如果使用全局数据的函数被中断和重新启动，它可能会丢失信息。

- 它不应修改自己的代码。无论函数何时被中断，都应该能够以相同的方式执行。这可以管理，但通常不建议这样做。

- 它不应该调用其他非重入函数。重入不应与线程安全混淆，尽管它们紧密相关。一个函数可以是线程安全的，但仍然不是可重入的。为了避免混淆，重入只涉及到一个线程的执行。这是在没有多任务操作系统存在的时代的一个概念。

这里有一个实际的例子：

函数 non_reentrant_function：

- 这个函数没有参数。

- 它直接返回全局变量i的五次方。

- 所以当你调用这个函数时，它总是返回5**5，即3125。

函数 reentrant_function：

- 这个函数有一个参数number，是整型。

- 它返回参数number的五次方。

- 这意味着你可以给这个函数传入任何整数，并得到这个数的五次方作为返回值。例如，如果你传入2，它会返回2的5次方，即32。

值得注意的是，许多智能合约函数都不是可重入的，因为它们访问如钱包余额之类的全局信息。

什么是锁（Lock）？

锁本质上是一种线程同步机制，某个进程可以声称或「锁定」另一个进程。

最简单的锁类型被称为二进制信号量。这种锁为被锁定的数据提供独占访问。还有更复杂的锁类型，可以提供对读数据的共享访问。在编程中误用锁可能导致死锁或活锁，进程持续互相阻塞，状态不断改变但没有进展。

编程语言在后台使用锁来优雅地管理和共享多个子程序之间的状态更改。但是，某些语言，如C# 和Vyper允许在代码中直接使用锁。

在上面的例子中，我们希望确保如果msg.sender（合同呼叫者）是另一个合同，它不会在执行时调用代码。如果在raw_call() 下面还有更多的代码，而没有锁，msg.sender可能会在我们的函数执行完毕之前调用上面的所有代码。

因此，在Vyper中，nonreentrant(『lock』) 装饰器是一种控制对函数的访问的机制，以防止调用者在它们完成运行之前反复执行智能合约函数。

在许多DeFi黑客事件中，通常都是合约开发者没有预见到的智能合约错误，一个聪明但恶意的利用者发现了某些函数或数据暴露的方式中的弱点。但这次的情况独特之处在于，Curve的智能合约以及所有其他成为攻击受害者的池和项目在代码本身中都没有已知的漏洞。合同是稳固的。

nonreentrant(『lock』) 是存在的。

由于Vyper语言在处理重入锁的方式上出现了问题，导致了这个问题的发生。所以，合约创建者可能部署了看似合理的代码，但由于编译器没有正确处理锁，使得攻击者能够利用这个有缺陷的锁进行利用，导致合约行为出现意料之外的结果。

让我们看看真正受到重入攻击的合约。注意 @nonreentrant(『lock』) 修饰符吗？通常情况下，这应该可以防止重入，但实际上并未能防止。攻击者能够在函数返回结果之前反复调用remove_liquidity()。

这是如何被利用的？

到目前为止，我们知道重入攻击是一种反复调用智能合约中的某个函数的方法。但这是如何导致资金被盗和在Curve攻击中损失7000万美元的呢？

注意智能合约末尾的self.balanceOf[msg.sender] -= _burn_amount吗？这告诉智能合约池中msg.sender的流动性，减去燃烧费。接下来的代码行为message.sender调用transfer()。

因此，一个恶意合约可以在金额更新之前不断地调用提现，几乎让他们可以选择提取池中的所有流动性。

这样的攻击通常的流程是这样的：

- 易受攻击的合约有10个eth。

- 攻击者调用存款并存入1个eth。

- 攻击者调用提现1个eth，此时提现函数执行一些检查：

- 攻击者的账户中是否有1个eth？是的。

- 将1个eth转移到恶意合约。注意：合约的余额尚未更改，因为该函数仍在执行。

- 攻击者再次调用提现1个eth。（重新入场）

- 攻击者的账户中是否有1个eth？是的。

这将重复，直到池中没有更多的流动性。

Vyper语言中的这个问题已经被修复，在0.3.0版本之后不再存在。如果您是开发人员，或使用Vyper的 Web3 组织，请确保立即更新您的版本。