Backporting old HF rules

[holgerd77]

We should really take on backporting the old HF rules rather sooner than later, re-remembered this when @s1na told about his block execution setup in the internal channel. This shouldn't be too hard to do and it would open up the VM to various interesting new use cases if we had a fully HF-supporting code base.

Some context: until mid 2018 the common ground/policy on this library was to "throw away" the old HF code on HF updates (due to economical reasons) and implement the new HF rules. This changed along #304 with the introduction of the overhauled ethereumjs-common library allowing for easier parallel HF integration. Initial integration was on the Byzantium rules, subsequent HFs were then added without deleting the old fork rules.

So the following HFs are currently missing:

• Frontier / Chainstart
• Homestead
• DAO (?)
• TangerineWhistle
• Spurious Dragon

The code is still there (along former merged PRs), so this should actually have some good basis to work on (of course things will need some adoption). This should also be a pretty rewarding work. @ryanio @evertonfraga @marcgarreau eventually this is some good task to get more familiar with the VM code.

Probably we should wait with this for after the monorepo transition since this will be easier to implement then, but might also depend on the specific HF to implement.

[ryanio]

Sounds great, would love to be a part of this work.

[evertonfraga]

I love this idea. Initially, I see lots of fork name comparison to set the correct values. We should first categorize the set of changes required and define a solid plan to implement them.

In a first pass I see these categories of changes. Feel free to add more:

1. New precompiles/opcodes

Should we deny the use of newer opcodes in former HF versions? I guess this behavior is a bit flaky today, but my hunch is yes, we should deny.

2. Opcode repricing

We should make extensive use of the Commons lib to set these values. Today, there's only a fraction of the basic opcodes (chainstart) in the lib. We should have them all in place as the main source of truth.

3. VM optimization/behavior rules, eg: EIP-663

Those can be more complex and need to have fork name comparison to set the new behavior.

[jochem-brouwer]

Progress:

Homestead: #815

TangerineWhistle: #807

SpuriousDragon: #791

[holgerd77]

Fixed by linked PRs, will close.