consensus/beacon,core, params, trie: verkle-compatible access list

[gballet]

Augment the interface to accessList to support more use cases that are necessary for verkle, in order to merge more data.

Highlights:

• Functions to check for the presence of an account/slot in the list are removed, as they lose meaning in a verkle context
• Instead, the function to add an account/slot to the list will directly return the consumed gas. This is necessary since the verkle gas model is quite different.
  • As a result, the constantGas is removed and the warm costs are directly returned by AddSlot/AddAddress when needed.
• AddAddress is modified to specify which account item is accessed. This does not matter for 2929 but is necessary for verkle.

https://eips.ethereum.org/EIPS/eip-4762

[gballet]

This change breaks tests. The comment itself says that this should not happen. My preference is to get rid of it and fix the tests: the reason is that in verkle, state and account are dissociated. It would be possible to link them, but it would be work done for a situation that should not occur in the first place.

Otherwise, I can add a addrMod return

[holiman]

Why is e.g. isWrite needed?
For example

statedb.Witness().AddAddress(w.Address, state.ALAllItems, state.AccessListWrite)

Why do we need to specify state.ALAllItems and state.AccessListWrite ?

[gballet]

because verkle charges a different amount of gas whether you are writing or reading the state: https://eips.ethereum.org/EIPS/eip-4762#witness-gas-costs

[holiman]

Couldn't the operation statedb.AddBalance(w.Address, amount) implicitly just add it to the witness without it needing to be done explicitly here?

[gballet]

It can be done in some (but not all) places, but the AddBalance function then has to be modified to return gas.

[holiman]

pls document what these mean / do

[holiman]

pls document these

[holiman]

I have two questions/thoughts

First of all, the goal of these two things are quite different, aren't they?

• The access list is a way to declare "the execution will at some point access X, and I want to pay for that up front, so the execution does not run out of gas at that point".
• The verkle witness serves a totally different purpose, doesn't it?

And a second question

• The access list is journalled: if we enter a scope, access X,Y and Z, and the scope reverts, then we want those to not be in the access list (otherwise there's a backdoor way to add an item to an access list without paying the cost: only paying the cost of a failed call, which may be lower).
• But for a witness building, any access in any scope needs to be preserved. So you intrinsically do not want journalling on a witness builder.

[holiman]

A short summary of my thought from our chat today.

• I don't think we should mix eip2929 access lists and verkle-witnesses. Those are IMO two orthogonal things.
• We should instead change some locations where we now do

if rules.IsBerlin{ 
   // do things with access lists
} 

into

if rules.Is2929Enabled{ 
   // do things with access lists
} 

And make verkle-fork set Is2929Enabled to false.

Most of all witness-building can happen in the dynmic gas functions of the following functions: SSTORE, SLOAD, SELFDESTRUCT, BALANCE, EXTCODESIZE, EXTCODEHASH, CALL, CALLCODE, DELEGATECALL, STATICCALL. The remaining places that adds to the witness are

• Transaction paying: sender and destination. This can be souped up where buyGas for transaction happens
• Block rewards
• Withdrawals

All three location can be handled in state_transition.go, I think.

Intrinsically, the witness-builder is a simpler thing than the access list, since there's no journalling. I think the implementation will be much less messy if it is not mingled with accesslist management.