Original author: Frank, Foresight News
Starting last night, Curve suffered from reentrancy bugs in certain versions of Vyper, which led to the hacking of its stable pools, including alETH/msETH/pETH, and triggered a series of secondary disasters and tremors in the DeFi and crypto world, which are still ongoing.
This is also a rare attack event in the DeFi world targeting smart contract language bugs. However, compared to Solidity, which is often mentioned in the crypto world, Vyper is not as well-known.
So what exactly is Vyper, what role does it play in the DeFi world, and why does its bug attract so much attention in the industry? In this article, Foresight News will take you to understand Vyper language, which is currently in the spotlight.
Vyper: The Second Most Popular Smart Contract Programming Language
Vyper was created in 2017. Before that, Solidity was the most commonly used language for writing smart contracts by developers. Just like Solidity, Vyper is a programming language oriented towards smart contracts that can be compiled into bytecode for the Ethereum Virtual Machine (EVM) and run on the EVM.
However, Vyper's compiler is written in Python, making it a Python-based and EVM-compatible programming language. It has strong typing, a small compiler code size, and efficient bytecode generation, making it one of the best choices for Python developers who want to enter Web3.
From the perspective of adoption rate, Vyper is currently the "second largest EVM-compatible smart contract programming language" after Solidity. According to the latest statistics from DeFiLlama before this attack occurred:
In the current DeFi development landscape (in terms of TVL percentage), Solidity occupies an absolute monopoly with 94.71% of market share, while Vyper ranks second with a market share of 3.04%.
From the third place onwards, Rust (0.9%), Cairo (0.53%), and Haskell (0.26%) have experienced a cliff-like decline.
In addition to the characteristics of Python, Vyper does not adopt object-oriented mode, inline assembly, and does not support code reuse, modifiers, inheritance, function overloading, recursive calls, infinite length loops, and binary fixed-length floating points.
In addition, it is optimized for security, readability, auditability, and gas efficiency:
Security: Support for building secure smart contracts in Vyper;
Readability: The smart contract language and compiler implementation of Vyper strive to be simple to improve code readability, especially for users who have no experience with Vyper and users who do not have programming experience;
Auditability: Vyper code maximizes readability, and its simple architecture reduces software errors and improves the auditability of smart contracts;
John Max Skaller, the founder of Vyper, once stated that there are two reasons for building Vyper: "First, I like Python, especially its simplicity, but I don't like its lack of determinism. Much change is needed to make progress, so I decided to retain compatibility with Python. While building a much more advanced programming language, I built certain concepts of functional programming language to correct these problems."
The second reason is performance. I have a main Python program called interscript, a programmable tool with read and write capabilities, which is plagued by the lack of good structure and performance issues in Python.
In general, the design intention of Vyper is to create transparent smart contracts that are easy to understand for participants in order to simplify the process, with a focus on readability and auditability, in order to ensure security.
Advantages and disadvantages of Vyper
This section discusses the advantages and disadvantages of Vyper compared to the Solidity language. After all, from the perspective of market share mentioned above, other smart contract languages have not yet formed a significant climate.
First of all, one of the biggest advantages of Vyper compared to Solidity is that it is based on the characteristics of Python, so although Vyper's functionality and popularity are not as good as Solidity, it is an ideal choice for developers familiar with Python.
At the same time, the Vyper compiler chooses to store local variables in memory instead of on the stack, which makes the contract simpler and more efficient, and solves the common problem of "stack too deep" in other high-level languages.
Vyper also provides more built-in functions to ensure that almost every functionality in Solidity and Yul can also be implemented in Vyper. Developers can access low-level bit operations, external calls, and proxy contract operations through built-in functions, and can achieve custom storage layouts by providing override files at compile time.
And the disadvantages of Vyper compared to Solidity are also obvious, mainly due to the fact that it is a relatively new language compared to Solidity, so the first and foremost is the shortcoming of developer maintenance and community tools:
Vyper still lacks the extensive community support that Solidity has-Solidity has a large number of excellent development tools available for use, such as OpenZeppelin, which provides open-source libraries for secure smart contract development, as well as online IDE Remix and local developer environment IDE Hardhat, which provide tools and functionalities that allow for easy development of DApps.
As of the time of writing, GitHub data shows that Solidity has 568 contributors, while Vyper has 189 contributors, a difference of three times.
However, although Vyper does not have a rich suite of development tools, it has more tightly integrated tools and can also be inserted into Solidity development tools-for example, the Titanaboa interpreter, which has many built-in tools related to EVM and Vyper, can be used for experimentation and development; Dasy, as a Lisp based on Vyper, has compile-time code execution capabilities.
In addition, from a technical detail perspective, Vyper lacks modifiers, class inheritance, and recursive calls, and the programming language is not Turing complete.
Of course, most of these are intentionally provided by Vyper with fewer features, aiming to improve security and auditability, making contracts safer and easier to audit, but this also means that developers need to do extra work to address these limitations, which means that Vyper, which is already at a disadvantage in terms of human resources, is destined to have lower development efficiency.
Where does the influence of Vyper come from?
At present, in this Vyper failure, it only involves specific versions such as 0.2.15, 0.2.16, and 0.3.0, and as can be seen from the previous text, the size of DeFi projects written in Vyper is not large, accounting for less than 5% of the TVL market share.
So why did this Vyper failure have such a big impact?
In short, although there are not many projects actively using the Vyper language for development in mainstream DeFi protocols, and the specific versions of Vyper that had issues this time, there is a top DeFi project that is built on Vyper:
Correct, it is Curve, and the main reason seems to be related to the Gas optimization features mentioned earlier - because Curve contracts are more complex, Vyper makes it easier to manage these complexities and further save Gas (other well-known projects based on Vyper development are few, such as Uniswap v1 version, the first ETH 2.0 deposit contract, etc.).
Since Curve has become a key infrastructure in the DeFi world and even the entire on-chain finance, the stable pools of Curve are essentially the underlying funds and sources of income for most protocols, which is also the key reason for the ongoing aftershocks of this security incident, such as JPEG'd, Alchemix, Metronome, deBridge, Ellipsis Finance, etc.
However, the new version of Vyper has fixed this vulnerability, but since the affected Curve stable pool contracts cannot be upgraded, they cannot be deployed and upgraded, so the corresponding contracts can only be abandoned and the funds withdrawn.
Summary
Overall, the reason why everyone is still fearful of this security incident is mainly because the bug risks at the smart contract language level have far exceeded the scope of the DeFi protocol itself or the logic of smart contracts.
Just imagine, if it weren't just Vyper this time, but even Solidity also had problems, then all DeFi protocols on the chain might have difficulty escaping, and we might really face the risk of "DeFi no longer exists".
But misfortune has its blessings. This time, Curve also revealed the lid on attacks on the smart contract language level, making everyone aware of this possibility. For the DeFi world, it is a great test and an opportunity for self-redemption.
