原文作者：Frank，Foresight News
昨夜开始，Curve 因受 Vyper 个别版本的重入锁故障影响，导致旗下 alETH/msETH/pETH 等稳定池被黑客攻击，由此引发一系列的 DeFi 次生灾害与加密世界震荡，至今仍在持续发酵中。
这也是 DeFi 世界罕见地直面针对智能合约语言层 Bug 的攻击事件。不过相比于加密世界中常常见诸报端的 Solidity 语言，Vyper 其实并不那么为人所熟知。
那 Vyper 究竟是什么，它在 DeFi 世界中扮演着怎样的角色，为什么它的 Bug 又会引起行业的高度关注？本篇文章 Foresight News 就带大家来了解一下目前正处于风口浪尖的 Vyper 语言。
Vyper 创建于 2017 年，在此之前，开发人员编写智能合约最常用的语言是 Solidity。而 Vyper 和 Solidity 一样，都是一种面向智能合约的编程语言，可编译为以太坊虚拟机（EVM）的字节代码，运行在 EVM 上。
不过 Vyper 的编译器使用 Python 进行编写，是一种基于 Python 且兼容 EVM 的编程语言，具有强类型、小型编译器代码和高效的字节码生成的特点，这也使其成为想要进入 Web3 的 Python 开发人员的最佳选择之一。
这导致从采用率角度看，目前的 Vyper 也是仅次于 Solidity 的「第二大兼容 EVM 的智能合约编程语言」，截至此次攻击事件发生前的 DeFiLlama 最新统计数据显示：
在目前的 DeFi 开发格局中（TVL 占比维度），Solidity 以 94.71% 的市场份额占据绝对垄断地位，而 Vyper 以 3.04% 的市场份额位列第二名。
而第三名开始往后的 Rust（0.9% ）、Cairo（0.53% ）、Haskell（0.26% ）已经是断崖式下降。
除了基于 Python 的特点之外，Vyper 不采用面向对象模式、内联汇编，并且不支持代码重用、修饰符、继承、函数重载、递归调用、无限长度循环和二进制定长浮点等。
此外它还针对安全性、可读性、可审核性和 Gas 效率进行了优化：
安全性：支持在 Vyper 中构建安全的智能合约；
可读性：Vyper 的智能合约语言和编译器实现力求简单，以提高代码的可读性，尤其是对于没有使用 Vyper 经验的用户以及一般没有编程经验的用户；
可审核性：Vyper 代码最大限度地让人可读，且其简单架构减少了软件错误，提升了智能合约的可审计性；
Vyper 的创始人 John Max Skaller 曾表示，构建 Vyper 有两个原因：「首先，我喜欢 Python，特别是它的简单性，但我不喜欢它缺乏范围确定性，凡事都需要做大量更改来取得进展，因此我决定在保留与 Python 兼容性的同时，通过建造高级得多的编程语言，并在其中建造函数性编程语言的某些概念来改正这些问题。
第二个原因是性能。我有一个称之为 interscript 的主要 Python 程序，一个有读写能力的编程工具，它受到 Python 中缺乏良好结构和性能问题的困扰」。
总的来说，Vyper 的设计初衷是为了创建出智能合约参与方易懂的透明智能合约简化流程，以主打可读性与可审核性，从而确保安全。
本章节谈及的 Vyper 优劣势，主要是相比 Solidity 语言，毕竟从上文提到的市场份额维度，其它的智能合约语言暂时还未形成较大的气候。
首先，Vyper 相比 Solidity 的最大优势之一，就是它基于 Python 开发的特性，因此虽然 Vyper 的功能和流行程度不如 Solidity，但对于熟悉 Python 的开发人员来说，它是理想的可选语言。
同时，Vyper 编译器还选择将局部变量存储在内存中而不是堆栈上，这使得合约更加简单和高效，并解决了其他高级语言中常见的「堆栈过深」的问题。
Vyper 也提供了更多内置函数，以确保几乎每个 Solidity 和 Yul 中的功能在 Vyper 中也可以实现。开发者通过内置函数可以访问低级位运算、外部调用和代理合约操作，通过编译时提供覆盖文件可以实现自定义存储布局。
而 Vyper 相比 Solidity 的劣势也很明显，主要源于它是一种相对 Solidity 较新的语言，所以首当其冲自然是开发者维护和社区工具层面的短板：
Vyper 至今仍然缺乏 Solidity 所拥有的广泛社区支持——Solidity 有大量优秀的开发工具可供使用，像 OpenZeppelin 为安全的智能合约开发提供开源库，以及 Remix 在线 IDE 和本地开发人员环境 Hardhat 等 IDE，为其提供了允许轻松开发 DApp 的工具和功能。
截至发文时，GitHub 数据显示，Solidity 的贡献者为 568 人，而 Vyper 为 189 人，相差 3 倍。
不过 Vyper 虽然没有丰富的的开发工具套件，但它有更紧密集成的工具，并且也可以插入到 Solidity 开发工具中——如 Titanaboa 解释器，具有许多与 EVM 和 Vyper 相关的内置工具，可用于实验和开发；Dasy，作为一种基于 Vyper 的 Lisp，具有编译时代码执行功能。
此外从技术细节角度，Vyper 缺少修饰符、类继承和递归调用，并且编程语言不是图灵完备的。
当然这些大部分是 Vyper 特意提供更少的功能，旨在提升安全性和可审计性，以使合约更安全和易于审核，但这也使得开发人员需要额外的工作来解决这些限制，从而意味着本就不占人力优势的 Vyper 注定开发效能偏低。
目前来看，此次 Vyper 故障只涉及 0.2.15、 0.2.16 和 0.3.0 等几个特定版本，且从上文也可知，使用 Vyper 编写的头部 DeFi 项目的体量并不大，仅占不到 5% 的 TVL 市场份额。
那为何此次 Vyper 的故障却造成了如此大的影响？
简言之，虽然在主流 DeFi 协议中，主动使用 Vyper 语言进行开发的项目并不多，且此次出现问题的是 Vyper 的几个特定版本，但有一个头部 DeFi 项目却是基于 Vyper 开发：
没错，正是 Curve，主要原因似乎与上文提到的 Gas 优化特性有关——因为 Curve 合约较为复杂，Vyper 使得这些复杂性变得更易于管理，并进一步节省 Gas（其它基于 Vyper 开发的知名项目则屈指可数，如 Uniswap v1 版本、第一个 ETH 2.0 存款合约等）。
由于 Curve 已经成为 DeFi 世界甚至整个链上金融的关键基础设施，所以在层层嵌套之下，Curve 的稳定池本质上就是绝大部分协议的底层资金与收益来源，这也是此次安全事件发生至今，JPEG'd、Alchemix、Metronome、deBridge、Ellipsis Finance 等余震不断的关键原因。
不过 Vyper 的新版本已经修复这个漏洞，但由于受影响的 Curve 稳定池合约不可升级，因此无法进行部署升级，只能选择废弃对应合约，将资金撤出。
总的来看，此次安全事件之所以大家会心有余悸，主要是因为智能合约语言层的 Bug 风险，已经远超 DeFi 协议本身或者说智能合约逻辑的范畴。
试想一下，如果此次不只是 Vyper，而是连 Solidity 也同样出了问题，那么链上所有的 DeFi 协议可能都几难幸免，我们甚至会真的面临「DeFi 不存在了」的风险。
但祸兮福之所倚，这次 Curve 也算被动掀开了对智能合约语言层进行攻击的问题盖子，让大家意识到了这个可能，对 DeFi 世界而言，是一次大考，也是一场自我救赎的机会。
