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
Split loading of account to its component but allow for it to be fully loaded if needed.
The Account contains the nonce, balance, code_hash and bytecode. In most client nodes nonce, balance and code hash are grouped in one table while bytecode is in a separate one. So current abstraction has separate loads for Account and Bytecode.
For parallel evm we would like to go even granular to see what exactly is used inside EVM, example of this is EXTBALANCE opcode where only the balance of a external account is needed. With better granularity, we have a better view of the points of the conflict
We still need to load it and consider it warm inside the EVM journaled state, but every field inside AccountInfo would be an Option<>.
So loading account info would additionally contain a Enum that would tell us what we want to load, in return, we could return AccountInfo which could contain every field or it could contain just the info that we requested. This would allow partial loading if the user wants that behaviour.
Maybe introduce two types of accounts, one internal to EVM and one for State
The text was updated successfully, but these errors were encountered:
Split loading of account to its component but allow for it to be fully loaded if needed.
The Account contains the nonce, balance, code_hash and bytecode. In most client nodes nonce, balance and code hash are grouped in one table while bytecode is in a separate one. So current abstraction has separate loads for Account and Bytecode.
For parallel evm we would like to go even granular to see what exactly is used inside EVM, example of this is EXTBALANCE opcode where only the balance of a external account is needed. With better granularity, we have a better view of the points of the conflict
We still need to load it and consider it warm inside the EVM journaled state, but every field inside AccountInfo would be an
Option<>
.So loading account info would additionally contain a Enum that would tell us what we want to load, in return, we could return AccountInfo which could contain every field or it could contain just the info that we requested. This would allow partial loading if the user wants that behaviour.
Maybe introduce two types of accounts, one internal to
EVM
and one forState
The text was updated successfully, but these errors were encountered: