core/state: remove notion of fake storage

[holiman]

This PR fixes #24456 .

This PR removes the notion of fakeStorage from the state objects, and instead, for any state modifications that are needed, it simply makes the changes and commits it.

I'm not fully certain if there are any tangible negative side-effects of doing a Commit (such as, does it have potential to flush stuff to disk? I think not).

One other change is that this change makes it not possible to replace the entire storage in one go, rather we can only update slots explicitly. I don't know how much of a biggie that is.

[karalabe]

That will actually write into the trie database, which is a big nono. It might still be "just in ram", but it will compete with the memory cache of real trie nodes. I'd wager it also creates a diff layer on top of the snapshots if one exists.

[holiman]

Gotcha! Using finalize seems to work too

[karalabe]

I'm not following this deprecation warning? It didn't fully replace all the slots before either.

[karalabe]

Can't we just delete this altogether if there's a better alternative?

[karalabe]

The change now seems ok, apart from the notes

[holiman]

Triage discussion: we need to somethow fix the SetStorage too

[zzh1996]

Could you please explain what that parameter affects and why it should be false?

[holiman]

I've made a stab at fixing this PR now, so that it should be possible to override the whole state. I haven't added any test for it yet.

[rjl493456442]

I will take a look tomorrow.

[holiman]

Test added!

[rjl493456442]

Hmm, it's not enough. State can still be hit in snapshot. e.g. https://github.com/ethereum/go-ethereum/blob/master/core/state/state_object.go#L216

[holiman]

No, I think we're executing snapshot-free when we're tracing

[rjl493456442]

My feeling is: this approach is OK, but in the future we should introduce some extra notions:
(1) StateReader
(2) StateReadWriter

The former mostly be used for serving requests and read-only actions(of course, state can be mutated but change should never be committed), and latter is used for state mutation.

[holiman]

Lifting this out

@rjl493456442 said:

Hmm, it's not enough. State can still be hit in snapshot. e.g. https://github.com/ethereum/go-ethereum/blob/master/core/state/state_object.go#L216

@holiman said:

No, I think we're executing snapshot-free when we're tracing

---

The state overrides come from two places, either ethapi/api.go DoCall:

	state, header, err := b.StateAndHeaderByNumberOrHash(ctx, blockNrOrHash)
	if state == nil || err != nil {
		return nil, err
	}
	if err := overrides.Apply(state); err != nil {

This one uses

		stateDb, err := b.eth.BlockChain().StateAt(header.Root)

->

// StateAt returns a new mutable state based on a particular point in time.
func (bc *BlockChain) StateAt(root common.Hash) (*state.StateDB, error) {
	return state.New(root, bc.stateCache, bc.snaps)
}

So, if the b.eth.Blockchain() has snapshots, then so does the state we're tracing on.

---

Or eth/tracers/api.go, API.TraceCall

	statedb, release, err := api.backend.StateAtBlock(ctx, block, reexec, nil, true, false)
	if err != nil {
		return nil, err
	}
	defer release()

	vmctx := core.NewEVMBlockContext(block.Header(), api.chainContext(ctx), nil)
	// Apply the customization rules if required.
	if config != nil {
		if err := config.StateOverrides.Apply(statedb); err != nil {

This one is a bit different, though, because StateAtBlock explicitly creates a new state without snapshots, for tracing.

TL;DR

For tracing, we are (probably) trie-only, and don't have to worry about snapshot. For eth_Call variants, however, we do, and this PR will not work properly.

[rjl493456442]

@holiman I think we shouldn't implicitly hold the assumption that snapshot is not available. Theoretically, if a state is for reading, both trie and snapshot might be available.

[holiman]

@holiman I think we shouldn't implicitly hold the assumption that snapshot is not available. Theoretically, if a state is for reading, both trie and snapshot might be available.

Yeah, that makes a lot of sense

[holiman]

I think we shouldn't implicitly hold the assumption that snapshot is not available.

I think this PR now respects this idea. One might consider the way it's done to be slightly hacky, but I really do not see a better way to achieve the same effect.

[MariusVanDerWijden]

LGTM