The idea behind the Vyper project was to develop something that was linguistically designed to naturally present a high degree of security. The project was initially written by Vitalik as a replacement for Serpent, its predecessor, but shortly after its creation, Vyper found itself without a dedicated maintainer. Fortunately, enthusiastic community members picked up the torch and continued development of the project, and we (the EF Python team) got back involved with the project for a while earlier this year.
This fall, a preliminary security audit was performed by the Consensys Diligence team on the Python-based Vyper compiler. You can read the results for yourself here.
We encourage you to read the report, but there are two main takeaways.
- There are several serious bugs in the Vyper compiler.
- The codebase has a high level of technical debt, which will make resolving these issues complex.
Since the existing Python-based Vyper implementation is not yet production ready, it has been moved from the Ethereum github organization to its own organization: vyperlang. The existing maintainers plan to resolve the issues independently once again, but we will continue to monitor the project closely here: >
Meanwhile, our team continues to work in tandem on a Rust-based compiler. More on that below, but first, here’s a little more about how we got to where we are today.
Over the course of this year, we worked with the project managers to focus on improving the quality of the project’s code and architecture. After a few months of work, we were skeptical that the Python codebase could deliver on the idea Vyper promised. The codebase contained a significant amount of technical and architectural debt, and from our perspective, it did not appear that the existing maintainers were focused on fixing this problem.
Explore rust
Earlier this year, in August, we considered producing a version of the Vyper compiler built on a fundamentally different architecture. The goal was to write a compiler in Rust that leverages the Solidity team’s existing work and uses the YUL intermediate representation to allow us to target EVM or EWASM when compiling. A Rust-based compiler can be easily compiled to WASM, making the compiler much more portable than a Python-based compiler. By building on YUL, we would get EVM and EWASM compilation for free, only requiring the compiler to handle transforming a Vyper AST to YUL. We were sufficiently advanced with our Rust-based Vyper compiler when the Python Vyper audit was released and were confident in the direction. The audit confirmed many concerns about the Python codebase and helped validate the direction we were taking.
The work continues
That said, those responsible for the Python Vyper codebase intend to continue the project. While we don’t plan to continue involvement with the Python codebase, we wish them well, but we also wanted to take note of recent events to avoid inadvertently signaling that the project was safe to use.
So, there are currently two “Vyper” compilers: the EF-backed work to build a compiler written in Rust to realize the original Vyper idea, and the Python effort that will work independently toward the same goals in the Python codebase . We hope to continue working together to create a single “Vyper” with multiple implementations, and we will keep everyone updated as the project progresses.
