core: Implement EIP 1153

[wbl]

This implements EIP 1153: I've made it a draft because I would like guidance on the following points.

1. This really needs some tests exercising the new logic via bytecode sequences, I'm not sure where tests like that should live
2. I don't know if I did all the work to enable turning this on on a testnet correctly
3. The shadowstack approach works, but relies on having an address of the contract: during creation it won't work right. This is probably OK, but should be called out in the EIP.
4. We don't disable this feature during readonly calls.
5. Haven't approach compiler support at all on this.

[moodysalem]

Would be great to compare with Mark Tyneway's impl here which he wrote at ETHDenver tynes/go-ethereum@master...eip1153 @tynes

[wbl]

So the big difference is philosophical: I treat the transient state as closely tied to the VM, Mark seems to treat it as near the storage DB. Otherwise they look pretty similar. I think Mark's costing is wrong: a transient write should be a lot cheaper than a dirty write, but that's literally a one line difference, doesn't matter too much.

[moodysalem]

So the big difference is philosophical: I treat the transient state as closely tied to the VM, Mark seems to treat it as near the storage DB

I agree with your framing. I made a similar comment here: ethereumjs/ethereumjs-monorepo#1768 (comment)

I think Mark's costing is wrong: a transient write should be a lot cheaper than a dirty write, but that's literally a one line difference, doesn't matter too much

I think that's a separate task though because any repricing of transient writes and reads should also be applied to dirty storage writes and reads, given they otherwise have the exact same semantics.

[wbl]

You've convinced me on the pricing, I think I misunderstood what dirty meant. I can go edit this PR to fix that.

Pending that, do you think it's ready to open as a real PR/do you have ideas for where i can add extra tests.

[holiman]

Thanks for making this PR. In the end, we prefer the approach made in #26003, where the tracking / revertal is tied to the statedb journal. So closing this in favour of #26003