Refactor chain configuration

[holiman]

Our chain is configured a bit spread out across several different abstractions, one of them being a gastable. This PR ries to make the configuration more coherent, and remove the need to keep a separate gastable and instead encapsulate everything inside the instruction sets.

This PR makes use of a previously unused recent change, the division between constantGas and dynamicGas for an operation, and the fact that an operation can have both, which makes certain simplifications possible.

The end goal is to simplify for a future PR where we can more easily add features (EIPS) to an existing defined fork, to make it simpler to execute state tests which focus on a particular feature (e..g Constantinople+1884) even if the whole (future) fork is still not defined.

[holiman]

This unstable-326b20e1-20190619 is now running on mon08, versus Geth/v1.9.0-unstable-3271a5af-20190619 (master) on mon09. Speed improvements are not really to be expected, mainly to check that it can process the forks correctly.

[holiman]

This PR now made it through all forks including byzantium, will take some more time for it to reach Constantinople.

[holiman]

This is no longer considered 'wip', although we should wait with merging until the node has synced up to head.

[holiman]

This PR now made it past all forks, including Constantinople. It's about 3h ahead of master, but that's probably just due to differences on the machines (exp is usually a tiny bit faster)

[karalabe]

Nit, lets rename Suicide everywhere to Selfdestruct. Now's a good time imho.

[holiman]

I've renamed it everywhere where I've already touched things, so param names and opcode internals. It's still in use within e.g. statedb and stateobject. I figure it's better to do that change in a PR which does not contain any functional changes.

[karalabe]

Generally LGTM. I've enumerated some insignificant nits. One thing that I'm pondering about is an introduced slight confusion in the gas method now.

Previously all opcodes either cost a constant, or if they were dynamic, they had a fully encompassing method. Now we have three combos: fully constant, fully dynamic, or constant + dynamic. This last class seems a bit error prone, because looking at the method name gasSStore vs gasSha3, both seem to convey that they are standalone, whereas the latter actually has a constant component outside.

Would it perhaps make sense to have gasXYZ be the naming convention if it's fully self contained, or dyngasXYZ if it's just part of the gas. That would make the code clearer that there's something funky going on there.

[holiman]

I've addressed the nitpicks. Regarding the other slight confusion, one thing to have in mind is that most of these contants are named to be (somewhat) consistent with the YP, which defines things like Gsha3, and Gsha3word which then became Sha3Gas and Sha3WordGas in go-ethereum, which were used in the method gasSha3. It all seems pretty random to me, and if we want to change it, we should have some good underlying logic for how to name these things, so that

• it's not so confusing internally,
• it still somewhat consistent with YP
• The name should also contain what fork it is relevant from.

For reference btw, there aren't many cases where things have only dynamic gas any more; SLOAD and LOGX, EXP, RETURN,REVERT, and SELFDESTRUCT.

LOGX could be rewritten to have a static portion (params.LogGas).
EXP is also only dynamic as of now, but could also be split up (params.ExpGas being constant)

If you want to, I can change all the methods that are only the dynamic part into dynGasXX/dynGasXXFrontier/dynGasXXEIP150.

[karalabe]

LGTM

[holiman]

I'll do the updates later this evening (you won't be able to push to my branch, so it'll be easier if I do it myself, but thanks for the offer!)

[rjl493456442]

LGTM

[holiman]

Nits fixed. Some follow-up work that might be worth doing in other PRs is to ...

• Extend the same logic to precompiles, so EIPs that modify (add/reprice) precompiles can be treated in a similar fashion,
• Split up LOGX + EXP (and possibly others) into static + dynamic parts
• Use a block context, and reuse the context across all txs in a block (same instructionset, same chainrules, same blocktime, number etc)