In it’s current state, PyEthereum is not this library.

PyEthereum has roughly zero documentation. PyEthereum has no distinction between public and private APIs There is no formalized strategy for deprecation and backwards incompatible changes. PyEthereum can be configured and made modular in some ways but there is zero documentation on how to do this and it is limited.

So if PyEthereum falls short, how do we get ourselves the library we need?

Option 1: Fix PyEthereum

The most obvious option is to fix PyEthereum. Given the magnitude of changes needed, this is not something that could be done iteratively on any reasonable timeframe which means it would need to be a significant backwards incompatible change.

This approach would leverage the work and mindshare that already exists within the PyEthereum codebase and development community. This is normally the route that I would take as rewrites often appear simple on their surface while in reality they are difficult and involved.

The primary argument against such a rewrite is the significant number of backwards incompatible breaking changes which would be required. This type of change would be disruptive and costly for all of the teams and products which are currently built on top of PyEthereum.

In a similar vein, such a broad change would likely be disruptive to Vitalik’s research.

Option 2: Start Fresh (the one I chose)

A completely new implementation written in Python.

The major benefit of this approach new library which can take cues from the existing implementation but start with a clean slate. This library can be developed in parallel to PyEthereum without causing any disruption to existing users.

The drawbacks to this approach are somewhat nuanced. In the short term, it means a lot of work creating a new implementation, but this is lessened by the wonderful ethereum/tests suite of test cases.

Introducing Py-EVM

Py-EVM is a new implementation of the Ethereum Virtual Machine written in python. It is currently in active development but is quickly progressing through the test suite provided by ethereum/tests. I have Vitalik, and the existing PyEthereum code to thank for the quick progress I’ve made as many design decisions were inspired, or even directly ported from the PyEthereum codebase.

Py-EVM aims to eventually become the defacto python implementation of the EVM, enabling a wide array of use cases for both public and private chains. Development will focus on creating an EVM with a well defined API, friendly and easy to digest documentation which can be run as a fully functional mainnet node.

Step 1: Alpha Release

The plan is to begin with an MVP, alpha-level release that is suitable for testing purposes. We’ll be looking for early adopters to provide feedback on our architecture and API choices as well as general feedback and bug finding.

We expect to enter this phase within the next very few months, if not weeks.

Step 2: Beta Release

Once we are satisfied that the basic design decisions are correct we will then enter a cycle of beta releases. During this time we will plan to develop an adapter as well as documentation for people migrating from PyEthereum.

During this time we will also begin development of the networking components to allow Py-EVM to serve as a full ethereum node on the live network.

This phase is likely to last for multiple months. We hope to be at or near the end by the time that Metropolis is released but ultimately, we will be done when it’s ready.

Step 3: Initial Stable Release

Once Py-EVM is able to run both the mainnet and public test networks it will be ready for a stable 1.0 release.

Development

If you’d like to follow along with the ongoing development of Py-EVM you can do so on github.