昨晚逐渐，Curve 由于受 Vyper 某些版本的再入锁故障影响，造成集团旗下 alETH/msETH/pETH 等平稳池被黑客入侵，从而引发一系列的 DeFi 灾害性与加密世界波动，至今仍在愈演愈烈中（参照时间轴《Curve 受到攻击，殃及好几个协议书》）。

那也是 DeFi 世界罕见地面对对于区块链智能合约语言层 Bug 攻击事情。不过相比于加密世界中常常见诸报端的 Solidity 语言，Vyper 其实也不那样为人正直熟知。

那 Vyper 到底是什么，他在 DeFi 世界中扮演着怎样的角色，为何它 Bug 又也会引起行业高度关注？本文 Foresight News 带大家一起来了解一下正处于舆论旋涡的 Vyper 语言。 

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 的优势与劣势

本章节目录谈起的 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 影响力从哪儿来？

目前来说，本次 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 世界来讲，是一次考试，也是一场重获新生的好机会。