fix(levm): fix interaction with cache and db

[JereSalo]

Motivation

Description

TLDR: We don't want to interact directly with the db without consulting before with the cache. This won't fix nor break tests because in every EFTest we send the cache empty, but it is a necessary fix for executing multiple transactions within a block. As a side effect we have to move contract creation and insertion to cache to transact(), so that we can revert if address is already occupied.

Idea:

• Move contract creation and insertion to cache to transact(), not to new().
  • This is because we really want to check if the contract already exists both in the cache and in the db, and if when you want to create it you see that it already exists in one of those 2 there you revert. Currently we only check it in the db but the tests work because they test only one transaction each, so the cache always starts empty.
• The idea is to stop using db.get_account_info() in the VM::new(), we want to query the cache first and then the DB. For this we have the get_account() method in VM, but in VM::new() it doesn't work because there is no vm created yet. The idea is to grab that behavior and take it to a get_account(address, mut cache, db) function that has the same behavior as now. The VM get_account method can be a handrail to call this, which does get_account(address, self.cache, self.db).

Additional Changes:

• Remove unnecessary stuff in VM::new()
• Remove receiver account every time a transaction reverts, independently of it's type.

Closes #issue_number

[lima-limon-inc]

LGTM

[damiramirez]

LGTM

[maximopalopoli]

LGTM

[maximopalopoli]

Maybe we could have a different name for the two functions, since having the same one could lead to confusion.

[JereSalo]

hmm maybe, the arguments are different though. They have the same name because they do the same thing but the VM one is like a wrapper. A better name doesn't come to my mind, what do you suggest?

[maximopalopoli]

It's true that there isn't a good name for both, maybe it could be get_account_cache_or_db, but it says more about implementation than anything else. Actual version looks good to me in that sense 👍