Implement evm module

[bkolad]

We will use the following evm implementation: https://github.com/bluealloy/revm
List of tasks

• Create a simple sov-evm module with a unit test that executes a simple contract in revm using the CachedDb
• Implement the Database trait (from revm) for WorkingSet and update the aforementioned test to work with the WorkingSet.
• Transform the second point into a separate module.
• Implement eth_sendRawTransaction RPC Method
• Determine how to handle block_hash, coinbase, block_number, etc.
• Ensure that the RPC functions work with standard wallets.

Related issues:
#425, #425

[LukaszRozmej]

Options and issues after doing some research:

We need to have the functionality of:

• Evm
• Some subset of eth RPC module for wallets
• Evm sequencer and TxPool
• Chain of latest blocks and their receipts (for RPC)
• Way to keep Ethereum-like state with some tree-like structure and state root.

Unknown:

• Do we need tracers?
• Do we need archive?

Way of integrating with rollup

Evm module single transaction could encode:

• Whole Evm block
  + Similar to Ethereum
  + Maps to RPC directly
  - Potentially big data set.

• Single Evm transaction
  + simple 1:1 mapping
  + fairly small
  + EVM works on transaction level
  - RPC expects blocks, need to create an artificial block-like thing

After executing Evm transaction the rollup would keep:

• Ethereum-like state in terms of Accounts, Storage Slots, contract ByteCode and some kind of state tree
• Blocks (quaryable by number or by hash)
• Receipts (quaryable by number or by block hash)
• Transactions (quaryable by hash)
• AccountChangeSets? (if archive needed)
• StorageSlotsChangeSets? (if archive needed)

Implementation options

• Minimal dependency - use Revm and implement rest ourselves.
  • Need to implement:
    • Storage for Blocks, Receipts, Transactions
    • All the needed RPC
    • Sequencer and TxPool
  • Most flexible
    • Can utilize our storage model for state
    • Easily customizable implementation
    • Easy read-only access to the data from other modules (potentially even write access)
• Including Reth in rollup
  • Only need integrations to implement
  • Need to reuse Reth databases for Blocks/Transactions/Receipts (or at least schemas, maybe we could integrate our database)
  • JSON RPC, TxPool already implemented. Not sure about the sequencer but it would be easy to build.
• Hybrid
  • Keep everything in the different process using Reth code where we can
  • In rollup keep only Revm + state
    • Other modules can only access state in read-only mode
• Hybrid + light
  • As above but also do not keep the state for Revm in rollup, instead add witnesses to the block and execute based on the witness
  • Minimal in-rollup module
  • Other modules cannot easily access any EVM state
  • EVM cannot easily access other modules

[joshuacheong]

@bkolad @LukaszRozmej looking into Sovereign SDK, correct me if I am wrong, my understanding is that it uses RISC Zero's ZKVM.

Why not use Zeth instead which has the prover system completed?

Zeth is also based on revm
https://www.risczero.com/news/zeth-release

[bkolad]

Hey @joshuacheong we need a ZkEVM that is implemented as sov-module so it can interact with other sov modules.
Zeth would be an overkill for us as the architecture is different from sov-module architecture and we already have the generic proving infra in place.

[bkolad]

The EVM module is currently undergoing stabilization