core/{.,state,vm},miner,ethr/tracers: implement 7709 #31015
Conversation
gballet
requested review from
MariusVanDerWijden,
holiman,
fjl,
rjl493456442 and
s1na
as code owners
Co-authored-by: Ignacio Hagopian <[email protected]> Signed-off-by: Guillaume Ballet <[email protected]>
gballet
force-pushed
the
implement-7709
branch
from
0081ab6 to
dd5ff82
Compare
|
If I understand correctly, in EIP 7709, the main differences are: However, only the third point is implemented in this PR right? |
| ringIndex := (evm.Context.BlockNumber.Uint64() - 1) % params.HistoryServeWindow | ||
| var key common.Hash | ||
| binary.BigEndian.PutUint64(key[24:], ringIndex) | ||
| evm.StateDB.SetState(params.SystemAddress, key, prevHash) |
There was a problem hiding this comment.
Why to use SystemAddress here?
There was a problem hiding this comment.
because that's what is used on the testnet, it's older than the current 2935 address.
| binary.BigEndian.PutUint64(key[24:], ringIndex) | ||
| evm.StateDB.SetState(params.SystemAddress, key, prevHash) | ||
| evm.StateDB.AccessEvents().SlotGas(params.SystemAddress, key, true) | ||
| evm.StateDB.Finalise(false) |
There was a problem hiding this comment.
I am wondering if it's necessary.
If Verkle is enabled, SStore will be replaced with SStore4762, the slot gas charging and warming will be done automatically if we register the block hash via invoking the contract, right?
There was a problem hiding this comment.
I guess this doesn't actually invoke any contract, just does the ugly and sets the slot. Which necessitates also setting the access-event.
There was a problem hiding this comment.
But why not invoking the contract? The gas charging, slot warming can all be done automatically in this way.
There was a problem hiding this comment.
so you might have missed the gist of conversations I had over this topic. There are several issues with invoking a contract:
- it's slower and uglier as you have to instantiate an evm each time, and copy/paste the code to do so all over the place
- it's more brittle, since it can revert. Also, what if there is a bug in the contract? Not as easy to fix as a bug in a client.
- it's not extensible, if you need to change the behavior, you need to deploy another contract
- you must filter the keys that bloat the witness a posteriori
- You need to keep a list of system contracts and check that list for each call, as they have a different behavior (see eip 4762)
Only 3 and 4 are relevant to this issue, but system contracts are generally a bad idea in my view.
There was a problem hiding this comment.
The conclusion was that, we would deprecate calling system contracts in verkle.
nope, it does all three, which is why it calls |
This is the implementation of 7709 as currently running on the verkle testnet. While this is not the final version, the final changes will be minor tweaks:
HistoryServeWindowto 8191