This is the initial framework for an eth1 pyspec.

Ethereum 1.0 lacks a comprehensive and accessible specification. This creates several pain points, but the most prevalent is that intricate core changes must spend a significant amount of time describing the current state of Ethereum, before even defining the proposed changes.

The Ethereum 2.0 spec has been a great example of "spec driven development". Eventually, we'd like to merge the two specs into a uniform, all encompassing specification. Until then, we've taken the liberty to experiment with a couple slightly different approaches than the eth2 specs:

• generate documentation from code -- the eth2 spec is a collection of markdown files that can be transpiled into an executable python project. My understanding is that this was a natural evolution of the spec, which started as mark down and slowly became more explicit, until the point where if the code snippets were concatenated, they could actually run and generate tests. Since we're starting from scratch, we can make an unbiased decision. While we agree that a "narrative" spec is desirable, we are confident that Sphinx will give us complete control over the look and flow of the spec. It will require more effort than markdown, but we believe it will drastically simplify other portions of the toolchain (e.g. type checking and linting), make the raw spec more readable and maintainable, and allow us to use more tools that already exist instead of writing our own.
• non-forking code -- the eth2 spec generally understands the concept of "forks" and handles them accordingly. We would like the eth1 spec to completely ignore the concept of forks and instead allow it to be "the latest version of ethereum". We believe this will lead to a simpler spec and simpler proposals for core changes. Forks are an unavoidable part of Ethereum though, so we'd like to support them via a release mechanism. For example, 1.x.x would be Frontier, 2.x.x would be Homestead, etc. We plan to write a handler program that runs specific releases up until a fork block and then shuttle the current state of the chain into the next release.

So, with that said, we are currently working on implementing the Frontier release of Ethereum. This is very much a work-in-progress still and everything is up for discussion. We feel the sooner this work is in the open, the sooner we can get feedback from the community and potentially find additional contributors.

As of this PR, we've successfully:

• generated the mainnet genesis state root
• passed a load of RLP and trie tests
• passed a simple add + sstore test

We'll generally try to avoid writing our own tests wherever possible and instead rely on the ethereum/tests format. We plan to support the t8n interface so that the spec can generate test cases. We'd also like to eventually sync mainnet, but that may require some work arounds.

We're excited to hear people's thoughts and feedback :)