Goal
- Identify what state of readiness the implementation of state-ful precompiles here is
- evm module (x/evm)
- Replicates geth EVM logic for EVM txs
- creates a
StateDB adapter to store EVM state as cosmos-sdk state (so not actually stored as merkle-patricia tree) (x/evm/statedb)
- Applies / reads state updates from this adapter (Keeper)
- Each tx spawns a new instance of an
EVM w/ the updated cached-stateDB and executes against that state
- In this process, the set of
CustomPrecompiles are instantiated
- Utilizes transient stores for block-bloom tx-indices etc
- transient here meaning that this state only exists between begin / end-block
- state
- code
- Key: contract addy
- Value: contract byte-code
- storage
- Stores state for smart-contract storage
- block bloom / tx-index
- state-transitions
- lifecycle
- Node receives bcast
- via eth-jsonRPC (this is a standard ethereum tx)
- The ingressed tx is converted to an sdk-tx and inserted into a block
- via comet broadcast
- tx is directly inserted to a block
- EVM
msg_handler actually applies the tx to state, and caches updates
- PostTxProcessing
- Logic to execute directly after the tx-execution of an EVM Tx
- Executed in the same context as the tx
- If this logic fails, the whole tx-fails
- Example
- ERC-20 transfers in EVM are reflected in the cosmos-side via this mechanism
- what are we missing of value?
- IBC → evmos has additional features to enable IBC sending erc20 tokens?
- precompiles → evmos has the ability for SCs to interact w/ cosmos
- erc20 module → ERC20s in the EVM are treated as cosmos-sdk tokens