Partnered With:

Multiple DeFi protocols have been attacked, what exactly is the "culprit" Vyper language?

Read this article in 12 Minutes

This incident also exposed the issue of attacking the smart contract language layer, which is a major test and a chance for self-redemption for the DeFi world.

Original Title: "DeFi is gone? Don't panic, let's get to know the Vyper language on the cutting edge"

Original Source: Frank, Foresight News

Since last night, Curve has been affected by a re-entry lock issue in certain versions of Vyper, which has led to hacker attacks on its stable pools such as alETH/msETH/pETH, causing a series of DeFi secondary disasters and shaking the crypto world. The situation is still ongoing and evolving (see timeline "Curve被攻击，殃及多个协议").

This is also a rare attack event in the DeFi world that directly faces smart contract language layer bugs. However, compared to the Solidity language often seen in the encryption world, Vyper is not so well-known.

So what exactly is Vyper, what role does it play in the DeFi world, and why is its bug causing high industry attention? This article from Foresight News will take you to understand the Vyper language that is currently at the forefront of the industry.

Vyper: The Second Most Popular Smart Contract Programming Language

Vyper was created in 2017. Prior to this, the most commonly used language for developers to write smart contracts was Solidity. Like Solidity, Vyper is a programming language designed for smart contracts that can be compiled into bytecode for the Ethereum Virtual Machine (EVM) and run on the EVM.

However, the compiler of Vyper is written in Python, which is a programming language based on Python and compatible with EVM. It has the characteristics of strong typing, small compiler code, and efficient bytecode generation. This also makes it one of the best choices for Python developers who want to enter Web3.

This means that from the perspective of adoption rate, currently Vyper is the "second largest EVM-compatible smart contract programming language" after Solidity. According to the latest statistics from DeFiLlama before the occurrence of this attack:

In the current DeFi development landscape (measured by TVL share), Solidity holds an absolute monopoly with a market share of 94.71%, while Vyper ranks second with a market share of 3.04%.

Meanwhile, from the third place onwards, Rust (0.9%), Cairo (0.53%), and Haskell (0.26%) have experienced a cliff-like decline.

除了基于 Python 的特点之外，Vyper does not adopt object-oriented programming, inline assembly, and does not support code reuse, modifiers, inheritance, function overloading, recursive calls, infinite length loops, and fixed-length binary floating points.

Additionally, it has been optimized for security, readability, auditability, and gas efficiency:

- Security: Supports building secure smart contracts in Vyper.

- Readability: Vyper's smart contract language and compiler implementation strive for simplicity to improve code readability, especially for users who have no experience with Vyper and those who have no programming experience.

- Auditability: Vyper code is designed to be highly readable, and its simple architecture reduces software errors, improving the auditability of smart contracts.

The founder of Vyper, John Max Skaller, once stated that there were two reasons for building Vyper: "Firstly, I like Python, especially its simplicity, but I don't like its lack of scope determinism. Everything requires a lot of changes to make progress, so I decided to build a much more advanced programming language while retaining compatibility with Python, and incorporating some concepts of functional programming languages to address these issues."

The second reason is performance. I have a main Python program called interscript, a programming tool with read and write capabilities, which is plagued by the lack of good structure and performance issues in Python.

Overall, the design intention of Vyper is to create transparent smart contracts that are easy to understand for all parties involved in the smart contract process. This is achieved by prioritizing readability and auditability, ensuring security.

Vyper's advantages and disadvantages

This section discusses the advantages and disadvantages of Vyper compared to the Solidity language. After all, as mentioned earlier in terms of market share, 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 developed based on Python. Therefore, although Vyper may not be as functional and popular as Solidity, it is an ideal optional language for developers familiar with Python.

Meanwhile, the Vyper compiler also chooses to store local variables in memory instead of on the stack, making contracts simpler and more efficient, and solving 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 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 layout by providing override files at compile time.

However, the disadvantages of Vyper compared to Solidity are also very obvious, mainly because it is a relatively new language compared to Solidity, so the first and foremost issue is the maintenance of developers and the shortcomings of community tools:

Vyper still lacks the widespread community support that Solidity enjoys - Solidity has a large number of excellent development tools available for use, such as OpenZeppelin for secure smart contract development providing open source libraries, as well as IDEs like Remix online and local developer environment Hardhat, which provide tools and features that allow for easy DApp development.

As of the time of writing, according to GitHub data, Solidity has 568 contributors, while Vyper has 189 contributors, a difference of three times.

However, although Vyper does not have a rich set of development toolkits, it has more tightly integrated tools and can also be inserted into Solidity development tools such as the Titanaboa interpreter, which has many built-in tools related to EVM and Vyper that can be used for experimentation and development; Dasy, as a Vyper-based Lisp, 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 with fewer features by Vyper, aimed at improving security and auditability, making contracts safer and easier to review. However, this also means that developers need extra work to address these limitations, which means that Vyper, which is not already manpower-advantaged, is destined to have lower development efficiency.

The influence of Vyper comes from where?

Currently, it appears that the Vyper malfunction only involves specific versions such as 0.2.15, 0.2.16, and 0.3.0. As mentioned earlier, the volume of DeFi projects using Vyper is relatively small, accounting for less than 5% of the TVL market share.

In short, although there are not many projects actively developed using the Vyper language in mainstream DeFi protocols, and the specific versions of Vyper that had issues this time, there is a top DeFi project that is based on Vyper development.

Yes, it is Curve, and the main reason seems to be related to the gas optimization feature mentioned earlier - because the Curve contract is more complex, Vyper makes these complexities easier to manage and further saves gas (other well-known projects developed based on Vyper are few, such as Uniswap v1 version, the first ETH 2.0 deposit contract, etc.).

However, the new version of Vyper has already fixed this vulnerability. However, due to the affected Curve stable pool contract being unable to be upgraded, it can only be abandoned and the funds withdrawn.

Summary

Overall, the reason why everyone is still feeling uneasy about this security incident is mainly due to the bug risks in the smart contract language layer, which have far exceeded the scope of the DeFi protocol itself or the logic of the smart contract.

Imagine if not only Vyper, but also Solidity had problems this time, then all DeFi protocols on the chain may be in danger, and we may really face the risk of "DeFi no longer exists".