Fix eip2929 implementation

[RomarQ]

Includes a fix related to EIP-2929, where some addresses were incorrectly considered cold and consumed extra gas. I identified this issue when running the tests located at ethtests/GeneralStateTests/Cancun/stEIP1153-transientStorage, which were failing because the gas costs did not match.

[RomarQ]

@sorpaas can you have a look at these changes?

I splitted these changes from the #278 to make the review easier.

[koushiro]

@RomarQ could you split this PR into three PRs?

• PR1: fix eip1559
• PR2: fix eip2929 (and update jsontests in CI)
• PR3: add cancun config

[koushiro]

Could you add ethtests/GeneralStateTests/Cancun/stEIP1153-transientStorage into jsontests in CI

[RomarQ]

@RomarQ could you split this PR into three PRs?

• PR1: fix eip1559
• PR2: fix eip2929 (and update jsontests in CI)
• PR3: add cancun config

Done

• feat: burn base fee when eip-1559 is enabled (>= london fork) #289: fix eip1559
• Fix eip2929 implementation #280: fix eip2929 (and update jsontests in CI)
• feat: add Cancun configuration #288: add cancun config

[RomarQ]

Could you add ethtests/GeneralStateTests/Cancun/stEIP1153-transientStorage into jsontests in CI

This depends on #288.

We can test it this way:

cargo run --release --verbose -p jsontests -- jsontests/res/ethtests/GeneralStateTests/Cancun/stEIP1153-transientStorage --debug

[RomarQ]

Once we enable tests for Cancun fork here:

evm/jsontests/src/run.rs

Line 106 in 8168ca1

Fork::Berlin => Config::berlin(),

if we run all the tests, some will fail, mainly because there are still a few incompatibilities after berlin (gas related). I only fixed a few, there are more.

[koushiro]

Once we enable tests for Cancun fork here:

evm/jsontests/src/run.rs

Line 106 in 8168ca1

Fork::Berlin => Config::berlin(),

if we run all the tests, some will fail, mainly because there are still a few incompatibilities after berlin (gas related). I only fixed a few, there are more.

We could fix those incompatibilities in future PRs, let's merge this PR first

[sorpaas]

I wonder is this move (from interpreter to gasometer), related to the fix?

The reason why it was put in interpreter because the code is supposed to support custom gasometers. Otherwise with this change, any custom meters will not properly mark hot/cold.

[RomarQ]

Yes, in some circumstances, the addresses were not being considered as warm when they should. If the objective is to have the code as customisable as possible, probably having it in the gasometer is not that bad.