params, core/vm: Istanbul EIP-1108 gas costs implementation

[Shadowfiend]

This PR implements the gas cost adjustments in EIP-1108. Commit messages outline how this is done; currently the Istanbul block is nil in all cases, and precompiles are not hooked up to the tracer isPrecompiled check. It's not immediately clear where Istanbul should be switched to “on” before the relevant block, basically, so this PR adds the plumbing and switching on it, but doesn't activate it anywhere.

Opening this a touch early as to see whether this direction makes sense (it is based it on feedback from last year's #17644 from @ngrinkevich), or if there's a different approach worth pursuing.

[karalabe]

There's a fairly significant PR pending from @holiman that reorganizes stuff a bit around fork handling and EIPs. Please wait until that's merged, this will need to be reworked on top. #19735

[karalabe]

Although I think there's fairly little overlap.

[Shadowfiend]

Ah! Thanks for pointing that out, I must have missed it when I rummaged to see if there was anything fork-related for Istanbul (maybe because it was at a higher level). I'll spend some cycles looking at it as well and see how it might affect my approach here.

[holiman]

In my PR, what I've done for those cases that change value over time, is the opposite of what you did in this PR.
Example:

	// EXP has a dynamic portion depending on the size of the exponent
	ExpByteFrontier uint64 = 10 // was set to 10 in Frontier
	ExpByteEIP158   uint64 = 50 // was raised to 50 during Eip158 (Spurious Dragon)

So instead of having preIstanbulXX and XX, I'd prefer <validFromFork>XXX , so byzantiumBn256AddGas (where it was introduced) and istanbulBn256AddGas

[Shadowfiend]

Mmm, fair. I took this approach because it seemed like it would be easier over the long term to understand what the “current” value was... But of course the value doesn’t become current until the hardfork.

I’ll make that change, thanks!

[Shadowfiend]

Ok, I have a rebased version here that swaps to the *<fork> naming and uses configParams. I'll push it once #19735 is merged!

[karalabe]

Please rebase

[Shadowfiend]

Ok, rebased. Had a few tripups with conflicts, sorry. Let me know what you think!

[karalabe]

I've pushed a tiny commit on top to move the declared fork field in the chain config to it's correct chronological position. I also reordered the bn256 precompile cost constants to follow Martin's previous scheme (it it easier to understand the changes if they are enumerated one after the other vs. in fork batches).

Thank you very much for the PR, clean and elegant. LGTM

[holiman]

LGTM

[Shadowfiend]

Thanks y’all, and thanks for the tweaks @karalabe... Definitely got my fork ordering mixed up 🤦‍♂️