core: implement EIP-2935

[s1na]

Copied over and adapted from https://github.com/gballet/go-ethereum/tree/kaustinen-with-shapella, following the latest changes to the spec: https://eips.ethereum.org/EIPS/eip-2935

[jsign]

@s1na, pinging you to be aware of some extra changes that happened on Kaustinen after you pulled the work from the other branch, see: https://github.com/gballet/go-ethereum/pull/411, which some days after where also updated in the EIP https://github.com/ethereum/EIPs/pull/8166/commits/2b73ecb9660f005ec76894700b09294c01a0632d

[s1na]

Updated to the devnet-1 spec changes.

[rjl493456442]

We should also deploy it for dev mode

[s1na]

We should also deploy it for dev mode

@rjl493456442 I believe it does https://github.com/ethereum/go-ethereum/pull/29465/files#diff-1272116434e5549f278a940767af52ed2d1abc91c44fa04ec48d8835a3774036R599

[holiman]

EIP still says

At the start of processing any block where block.timestamp >= FORK_TIMESTAMP (ie. before processing any transactions), update the state directly in the following way:

[holiman]

The EIP is under-specified. It says to update directly (as in, do not invoke contract). And then

Alternatively clients can also choose to do a system update via a system call to the contract set mechanism defined in the following sections.

But those are not two equivalent alternatives. In case the code does not exist, those two scenarios will differ wildly.

1. Direct-Update: If no code exists, the direct update will be reverted (so a no-op). Unless there happens to be some eth on the address, in which case the slots will be persisted (a actual-op).
2. Call-update: if no code exists, it will be a no-op.

I don't see how EIP-2935 can be scheduled for inclusion with the EIP so ambiguous. cc @gballet

[s1na]

Here's my proposed changes to the EIP: https://github.com/ethereum/EIPs/pull/8816