Pyspec framework

[lightclient]

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 :)

[pipermerriam]

I would nominate that this get merged soon so that additional changes can be done in smaller units and directly targeting this repository rather than the quilt fork.

[SamWilsn]

Agreed! None of us can actually do the merge though.

[pipermerriam]

Still seeing a stream of commits coming in. You wanna give me a poke when you're ready with something stable.

[lightclient]

@pipermerriam we can keep it stable until Monday if someone wants to merge this. I'm guessing by then, we'll have some more PRs that we'll want to get merged.

[timbeiko]

@lightclient happy to merge this now if you think it's ready to go!

[lightclient]

@timbeiko it's ready! :)