A Jan. 8 post published by the Ethereum Foundation (EF) revealed that developers are working on a new implementation of the Vyper compiler, due to “multiple serious bugs” in the existing version. The Vyperlang team responded by noting that existing Vyper smart contracts were not affected by these bugs.
Vyper is an alternative programming language for Ethereum originally conceived by Vitalik Buterin. It focuses on being as human-readable as possible, even at the cost of missing some of the more advanced features found in Solidity, the primary language.
While initially part of the main Ethereum (ETH) code stack, it has since spun-off into an independent repository following an Oct. 2019 preliminary audit by Consensys Diligence. The report found 31 issues with the Vyper compiler, the software that translates the language into computer code for the Ethereum Virtual Machine (EVM).
Ethereum Foundation developers explained in their blog post how they gradually became disillusioned with Vyper maintainers:
“After a few months of work we were skeptical that the python codebase was likely to deliver on the idea that Vyper promised. The codebase contained a significant amount of technical and architectural debt, and from our perspective it didn’t seem like the existing maintainers were focused on fixing this.”
Even before the report, the EF team began work on a new Vyper compiler based on the Rust language. The decision was motivated by increased portability to EWASM, a new virtual machine implementation replacing the EVM that is set to be introduced with Ethereum 2.0.
Compiler bugs not critical, argue Vyper maintainers
Bugs found in the Vyper compiler were especially significant due to its use in the Ethereum 2.0 deposit contract, a critical component of the Proof-of-Stake (PoS) system.
However, Vyper developers clarified in a Twitter thread that a separate audit was conducted for the contract itself by Runtime Verification, which found no unfixed bugs. It used the compiled machine code of the contract to perform the analysis, meaning that any anomaly introduced by the compiler would’ve been detected.
Furthermore, the Vyperlang team released an update on Jan. 7, claiming to have fixed over 75 percent of the bugs outlined by the Consensys audit.
Development of both the Rust and Python versions of Vyper will continue, though EF developers remain hopeful that both implementations will work toward a single Vyper language — a goal that is likely to require close cooperation between the two teams.