You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor(levm): use ethrex account types in LEVM (#2629)
**Motivation**
- Stop using the Account and AccountInfo types defined in LEVM and start
using the ones defined in the L1 client.
- Biggest changes are that AccountInfo no longer has code, so we can't
use it with that purpose and also we don't have our struct StorageSlot
anymore, so we have to keep track of original values somewhere else.
**Description**
- Now we use the structs of the L1 client but they are different from
the ones that we used so I had to make changes:
- `get_account_info` is now `get_account` because we also need the code
of the account and `AccountInfo` has the `code_hash` only. This makes
changes on every structure that implements `LevmDatabase` trait.
- Now that we don't have `StorageSlot` that had the `current_value` and
`original_value` of a storage slot (`original_value` being the value
pre-tx) I had to make some changes to logic and store those original
values into an auxiliary `HashMap` on `VM`.
- Added new function `get_original_storage()` for getting the original
storage value.
- Make some tiny changes in SSTORE, mostly organize it better.
Storage changes deep description:
- Now every time we want to get the `original_value` we will look up in
the original values stored in the VM struct. These intends to store the
storage values previous to starting the execution of a particular
transaction. For efficiency and performance, we only update this new
field when actually getting the original value.
- Let me clarify: At the beginning of the transaction the `CacheDB`
could have a lot of accounts with their storage but the
`VM.storage_original_values`will start empty on every transaction. When
`SSTORE` opcode is executed and we actually care for the original value
of a storage slot we will look at `storage_original_values` and it won’t
find it (the first time), so then it will see what the value in the
`CacheDB` is, and if it’s not there it will finally check on the actual
`Database`. After retrieving the value, it will be added to
`storage_original_values` , but ONLY the FIRST time. That means that if
the value keeps on changing the `original_value` won’t change because
once it’s added it’s not modified.
<!-- Link to issues: Resolves#111, Resolves#222 -->
Closes #issue_number
0 commit comments