feat(state): Intercept Database creation

[alarso16]

Why this should be merged

For Firewood, there's many places in libevm where it uses these methods to construct a state.Database, but we need a different implementation. Since this is separate from the StateDB interfaces (I don't want to have to register for each test, but rather in a single init function), I made it a separate registration for simplicity.

The ultimate goal is for ava-labs/avalancheg#5314, so if this approach is not correct to enable that, this PR should not be merged.

How this works

Intercept each creation with the possibility of wrapping the state cache if it is registered.

How this was tested

Added some no-op unit tests.

[ARR4N]

For Firewood, there's many places in libevm where it uses these methods to construct a state.Database, but we need a different implementation.

1. What is "it" in the sentence above? libevm does, or Firewood does?
2. Why does Firewood need this different caching database? What happens if the wrong one is used? My understanding was that Firewood replaceds the triedb.Database, on which the state.Database relies as its source of truth. This change suggests an inversion of the dependency.

[alarso16]

For Firewood, there's many places in libevm where it uses these methods to construct a state.Database, but we need a different implementation.

1. What is "it" in the sentence above? libevm does, or Firewood does?

In core/genesis.go, state.NewDatabaseWithConfig and state.NewDatabaseWithNodeDB is called. The implementation of state.Database returned from the libevm function is incompatible with Firewood. This is purely to allow testing Firewood in vm/saevm without a custom genesis implementation.

2. Why does Firewood need this different caching database? What happens if the wrong one is used? My understanding was that Firewood replaceds the triedb.Database, on which the state.Database relies as its source of truth. This change suggests an inversion of the dependency.

There's a few things going on here. Firewood does replace the triedb.Database, and asking what's wrong with using the cachingDB implementation is appropriate. Specifically, it's three functions:

• OpenTrie
• OpenStorageTrie
• CopyTrie

These return the state.Trie interface, of which, libevm uses one implementation: trie.StateTrie. This uses the triedb.Reader interface to load individual nodes from disk into an in-memory trie for hashing.

This doesn't work with Firewood for a lot of reasons: this relies on a two-tier trie structure (each account has a storage trie), Firewood doesn't expose intermediate nodes, and Firewood "automatically" hashes the trie on insertion. Because of this, we need to replace the state.Trie implementation that will be returned from the methods above.

[ARR4N]

Note

You're right that the comment is out of date. Can you please do some archaeology to determine when the comment was added and what happened to the function it references? If it's completely gone (probably moved to the ephemeral package in avalanchego) then all good otherwise please add the change to this PR and DM me to take a look if you think further review is necessary.

[alarso16]

Note

You're right that the comment is out of date. Can you please do some archaeology to determine when the comment was added and what happened to the function it references? If it's completely gone (probably moved to the ephemeral package in avalanchego) then all good otherwise please add the change to this PR and DM me to take a look if you think further review is necessary.

It was removed in #238, just as you described. I'll update all other comments to accurately reflect use patterns