Feature Request: `x/evm` indexing EvmBlock for faster Json-RPC

[VictorTrustyDev]

Problem: RPC is complex with fetching data from everywhere in order to build response for Json-RPC queries. That can down performance.

Solution: build entire EVM block then indexes it during EndBlock. Later can just get block and return corresponding result for related Json-RPC endpoints.

Props:

• Enhance response time, instead of going around to query and build result.

Cons:

• Cost disk for Archival Nodes. Full Nodes are not effected much, since they have pruning enabled. Probably should remove ABCI events emitted to reduce disk size. Because current receipts & logs are being saved as ABCI events so removing this save the amount of space similar to the added.

Backward compatible for existing chains:

• Must keep current query implementation (legacy)
• Add a query to x/evm keeper to see if block is available or not
• If not, check height of when feature is deployed
  • < enabled => fallback to legacy implementation.
  • >= enabled => it is pruned, returns error.

Steps:

• Save Evm Block & Txs & Receipts & Logs into x/evm store
• Index Block bloom into EVM Tx Indexer
• Remove old ABCI events that used to store data
• Compute & use ETH-block hash as defined Problem: current ETH block hash is not computed and inherit Cosmos block hash #88

Children tasks:

• Problem: Block bloom is missing information in some cases #91
• imp(test): add some edge test cases + benchmark tests #100

[VictorTrustyDev]

WIP!!!

Problems need to be solved:

• ETH block hash currently inherits Cosmos Block Hash.
• ETH block stateRoot (a.k.a AppHash on Cosmos) needed to compute ETH-block hash: can not be obtained during block execution => Append on next block, during ABCI BeginBlock event.

x/evm new design relates to store & module:

Module ABCI events:

• Begin block:
  • Finalize previous block by recording AppHash, compute BlockHash, store them.
  • Emit finalized ETH-block hash event for mapping purpose (is this needed? Why not just eth_getBlockByNumber ?)
• DeliverTx:
  • Store some needed information to transient store, to be used at EndBlock
• End block:
  • Fetch cached values from transient store, persist to actual store like:
    • transactions (many bytes, MarshalBinary will truncates data WARNING)
    • receipts (which include logs) (many bytes, MarshalBinary will truncates data WARNING)
    • transactionsRoot (32 bytes)
    • receiptRoots (32 bytes)
    • blockBloom (256 bytes)
    • miner (optional, 20 bytes, target: no need to fetch tm BlockResult and ResultBlockResults)
    • gasLimit (optional, 8 bytes, target: no need to fetch tm ConsensusParams)
    • gasUsed is the final cummulative gas (8 bytes)
    • timestamp (optional, 8 bytes, target: no need to fetch tm BlockResult.Header)
    • Total optional fields need 36 bytes per block, unknown size after proto marshalled, permanent cost on Archival nodes. OK?

Store:

• Introduce new stores
  • Current ETH-Block information (fixed key 1 bytes + per-block value many bytes)
  • Previous ETH-Block's Finalize information:
    • ETH-Block Hash (fixed key 1 byte + per-block value 32 bytes)
    • ETH-Block State Root (aka AppHash) (fixed key 1 byte + per-block value 32 bytes)

By using fixed key for new stores, data is prune-able on prune-nodes.

Events:

• Remove all current x/evm's events. (I bet this cost more than storing new values on x/evm since txs and receipts are truncated by MarshalBinary while events are Json-text)

New specs:

• ETH-block are queriable at block N+1, where stateRoot is clearly visible, thus enough input for computing ETH block hash.

RPC endpoints are targeted to only fetch from

• x/evm store for block header & information, one query, one read
• And next block for the finalized block (hash), or from EVMTxIndexer, which should index the ETH-block hash & ETH-state root (aka AppHash) after Cosmos-block finished (have enough information for computing).

EVMTxIndexer:

• Now compute and index ETH-block hash during indexing blocks.
• Clone interface to a new name, eg EthBlockIndexer with since, I guess, the indexing and store will change alot

Backward compatible:

• Evermint is for R&D, does not support backward compatible usually, in this case, when implementation, probably we will drop the events which make legacy Json-RPC implementation won't work. But...
• For existing chain, if any one wants to inherit this design, can just add an params of block height during migration, which used to detect context and routing to correct implementation version.

Unknown result:

• ETH block size?

[VictorTrustyDev]

Spec changed by the spec defined in 2nd post (above):

• No longer tracking logs indexes as it should be built from scratch upon query.
• Removed a lot of events
• Deprecated EVMTxIndexer, promote the new child EthereumBlockIndexer
• Only accept one MsgEthreumTx per transaction (TODO check again)
• Trace now fetch list of txs from store and execute them.