Current State

State of Ethermint

Ethermint is an evm-based application built using the Cosmos SDK. In fact, a bulk of the core implementation is just an SDK module -- x/evm. In its current state, Ethermint can parse and validate Ethereum txs and persist them via a modified version of StateDB that is backed by an SDK IAVL store. In addition, there is a mechanism to replay and check the validity of Ethereum mainnet txs.

StateDB

Ethermint also uses go-ethereum for functionality such as addresses, keypairs, common utilities, and implementing various interfaces. Most notably, go-ethereum has a structure called StateDB which facilitates state management and persistence of accounts and their respective storage. However, instead of using the Merkle-Patricia Tree, Ethermint utilizes the IAVL store implemented in the Cosmos SDK. In order to do so, go-ethereum was forked in order to turn StateDB into an interface where the implementation of that interface resides in x/evm. In the long run, this fork should not be maintained but instead a permanent solution should be found. The original goal here was to have turbo-geth maintain this interface along with various performance improvements.

The implementation of the StateDB interface is very similar to the implementation found in go-ethereum except for the following:

• There is no need for preimages because we use an AVL+ tree.
• There is no need for a storage trie. The StateDB implementation uses KVStore access-control keys to access both an IAVL account code store and an IAVL account storage store. The account storage store uses the account address as a prefix. This also means during commitment, we do not store or track the account storage root.

Ethermint utilizes the standard SDK account module which is passed to the StateDB implementation. This means that account balances should be reflected in the evm module.

Transactions

Like any application built using the SDK, Ethermint currently first passes transactions through an ante-handler for signature verification and other light weight non-message dependent checks. The SDK defines a Tx interface that all transactions must implement where within this Tx, an implementation contains messages that must implement the Msg interface. A transaction can have one or more messages.

Ethermint represents an Ethereum transaction as both a Tx and a Msg where a transaction will only ever contain a single message -- an Ethereum transaction. The implementation is essentially complete and supports signature and signature recovery along with RLP serialization.

The current implementation of Ethermint's ante-handler processes transactions in one of two ways. If the transaction is a non-ethereum based tx (ie. an auth.StdTx), then the traditional SDK ante-handler is executed. Otherwise, it is routed through a specific ethAnteHandler ante-handler where the main difference is that ethAnteHandler verifies inartistic gas and performs signature verification slightly differently.

Work to be Done

• Upgrading to the latest version of the SDK and making any necessary adjustments (most likely ante-handler).
• Reviewing the StateDB implementation and making sure it's in line with the latest version of geth. Essentially, completing any remaining work needed in the x/evm module.
  • One thing to keep in mind here is the role of receipts and logs as these concepts have yet to be ironed out.
• Full web3 JSON-RPC compatibility. Currently stubs exist in server/rpc, but further implementation details will need to be fleshed out with regards to Tendermint (eg. getting certain objects by hash or querying for logs, bloom filters, etc).
• Reviewing ethermint.go and making sure everything is wired together correctly and the correct calls are made in each respective ABCI method.
• Determine fee mechanisms
• Determine distribution mechanisms