Evermint is fork of Evmos v12.1.6 for research & development purpose

Currently, Evermint is using EthAccount as the default proto account and the only type of account supported.
That causes some limit:

• Use Cosmos-SDK x/vesting module
• Limit potential of integrate new features from CosmosSDK
• Wasting storage to store evmtypes.EmptyCodeHash 32 bytes value that also exists in every non-contract EthAccount (see prove).

Request:

• Remove EthAccount
• Make authtypes.BaseAccount as default proto account, compatible with EVM module.
• All current testcases must be kept to make sure the implementation is fully compatible.
• x/evm non-genesis account now only support export/import only accounts with either code or storage
• Optimize store by only store code hash which len(code_hash) > 0 && code_hash <> evmtypes.EmptyCodeHash instead of saving it into every EthAccount record. This change will slightly lower gas fee required to read from store in non-evm Txs

Aware:

• x/auth keeper RemoveAccount
• Account bytes compatible: currently Cosmos supports 20 & 32 bytes address (ICA)

Mindset changes:

• Contract account is now accounts that has CodeHash record (len(code_hash) == 0 || code_hash == evmtypes.EmptyCodeHash will be removed from store)
• ETH-compatible account is now accounts those are not contract accounts, plus len(address_bytes) == 20. If it is in blockedAddrs by x/bank, will be an error in stateDb.Commit() phrase.
• When doing account migration, remember to consider migrate code hash, if needed.

Migration aware (if any chain planned to implement this):

• Must define migration to be able to upgrade Ethermint/Evmos chains.
• Must test query historical data and data must be matched pre and after upgrade.

Cosmos behavior: let say 3 txs:

• Tx 1 (Cosmos)
• Tx 2 (EVM)
• Tx 3 (EVM)

When Tx 1 & Tx 2 consumed all block gas, the rest txs (Tx 3) will be immediately marked as failure without executing, nonce not changed so open an ability to resend later, thus tx exists in multiple block.

Side effect: eth_getBlockBy*** returns txs list contains the Tx of a higher block, which it executed, that totally wrong.

Solution 1:
Prevent the tx to be executed again (eg by increase sender nonce without charges gas fee)

Solution 2:
Exclude the tx from eth_getBlockBy***

Currently transactionsRoot and receiptsRoot is not computed and returned a constant of empty hash.

• snapshot command (completed by #12)
• inspect command & sub commands (completed by #14)
  • inspect block
  • inspect latest-block-number

The following issues are known but not fixed in Evmos v12 known in Evmos v12 and fixed in Evermint

• evmos#1663 (fixed by #3)
• evmos#1676 (fixed by #5)

I feel wrong about this implementation...

	cumulativeGasUsed := res.GasUsed
	if ctx.BlockGasMeter() != nil {
		limit := ctx.BlockGasMeter().Limit()
		cumulativeGasUsed += ctx.BlockGasMeter().GasConsumed()
		if cumulativeGasUsed > limit {
			cumulativeGasUsed = limit
		}
	}

So I dropped a note here and review later.

No analyze or solution yet, just a quick note to indicate the issue.

Probably solve-able by #90

Current implementation of test for Json-RPC is mostly depends on mock & basic unit-test.
I feel like it's hard to test it correctly.

Not a bug

Problem:

Every Ethermint-based/Evmos-based chains are using eth_secp256k1 and Coin Type=60 so the delivered address will be different with the other non-EVM compatible chains. Two cases can happens:

• Users sending funds from an EVM-compatible chains, so address will be compatible and users can access to their funds.
• Users sending funds from non-EVM-compatible chains, with different eth_secp256k1|| Coin Type, the address is in-compatible so they can not access to their funds.

But, this won't usually happens, can say rare due just from mistake of front-end developers or sometime user when manually convert address.

Solution:

Can choose one of the following options:

1. Re-use x/recovery module from Evmos.
2. Implement a light-weighted module that invokes "refund-to-sender" in certain conditions.
3. Just ignore it.

In case of decided to implement a recover funds method, the following condition should be match.

• Account must not sent any transaction before (nonce = 0).
• Only base accounts are considered as source of funds that recoverable (non-contract, non-module, non-vesting,...)
• Check ERC-20 token pairs to detect balance of already converted by IBC middleware.

EVMTxIndexer as a mandatory service of Json-RPC (:8545) will be an advantage.

• If the node serves Json-RPC, it needed performance and the indexer does help alot.
• If the node does not serve Json-RPC, the indexer is turned off, no extra disk wasted for the indexer. Then when the Json-RPC is turned back to on, the indexer will keep indexing from the last indexed block.

Disadvantage:

1. (Bug) If indexed data not available somehow (like turned off Json-RPC for sometime, then turned on, there is a gap between last indexed block to the latest one. So if a query to the JsonRPC service, the tx might not be found during indexing progress.
2. Currently, indexer if not able to fetch a block result, it will retry infinity so on a prune-node, there is an edge case that indexer is turned of at the past, the data on db is exists, LastIndexedBlock returns positive number but that block is already pruned and the indexer can not back to work.

Steps:

• (commit) Remove option to enable, re-use Json-RPC enable flag.
• Enable from latest indexed block until latest (the same as current behavior, no action needed)
• (commit) Refactor all related Json-RPC endpoints, direct query indexer, remove all the other code logic.
• (commit) Fix the disadvantage no.2 by force assign last indexed block to the node's earliest block returned by Tendermint status and accept that we will give-up about the missing information.
• (commit) Fix the disadvantage no.1 by assign a ready flag to the indexer.
  • Initialized with false
  • Switch to true when indexed to latest height
• (commit) Improve eth_blockNumber by using last request indexed block number from indexer instead of using gRPC call then check header.
• (commit) Json-RPC will wait indexer to be finished before starting service.
  • (commit) Apply a threshold to skip retries index block upon start-up to prevent stuck at specific block that also prevent Json-RPC startup.

For the purpose of consistent testing as well as convenience purpose, need some static test accounts of the same seed phrase to be initialized during genesis initialization.

There are some modules from Evmos code base that kinda business-logic-specific and imo should be removed from Evermint codebase. Target:

• Make code base more light-weight
• Reduce distract for newbies, good for research, focus on the most core and important modules
• Reduce maintenance resource

Candidate modules:

• x/claims is the Air Drop module that business-specific. Completed by #73
• x/inflation is kinda business-specific also and let's use Cosmos-SDK x/mint instead. Completed by #54
• x/incentives is kinda business-specific. Completed by #67
• x/revenue is kinda business-specific. Completed by #68
• x/recovery aims to fix the address derivation issue. Completed by #69
• x/epochs provided hooks for x/inflation and x/incentives. Completed by #70

Optional:

• x/vesting is kinda business-specific, shall we use Cosmos-SDK x/auth/vesting instead? How EthAccount compatible?

Current issue:

• When an account broadcast many transactions at a time (with nonce increament), there is high chance that most of the txs will be failed to execute due to nonce check, that caused by un-ordered by sequence when executing txs.
• When trace transaction, the data is not accurate if there is Cosmos Txs before or in the middle of the txs that modified store and trace tx can not simulate that.

That caused by the reason that current Tendermint/CometBFT version we are using, does not support re-order the transactions.

Possible solution:

• ABCI 2.0. As I understood, PrepareProposal would help us with the ability to modify the txs bytes, that we can used to re-order the txs as the following orders:
  • EVM txs first
  • Within EVM txs, follow Ethereum's order.
  • Any others if applicable

For example this case

	// pass true to commit the StateDB
	res, err := k.ApplyMessageWithConfig(tmpCtx, msg, nil, true, cfg, txConfig)
	if err != nil {
		// Refer to EIP-140 https://eips.ethereum.org/EIPS/eip-140
		// Opcode REVERT provides a way to stop execution and revert state changes, without consuming all provided gas.
		// Thus, all the other failure will consume all gas.
		// That why we are going to consume all gas here because this is not caused-by-REVERT-opcode.
		k.ResetGasMeterAndConsumeGas(ctx, ctx.GasMeter().Limit())

		return nil, errorsmod.Wrap(err, "failed to apply ethereum core message")
	}

EIP-3855: PUSH0 instruction
Introduce a new instruction which pushes the constant value 0 onto the stack

^ this aims to optimize storage

Nothing here, just my notes for tracking

• #74
• #85 (contains TODO)
• #96
• #100

Gas used, what should it be?

• Gas used of the Cosmos-block?
• Or gas used just only by the EVM-txs?

Why this questions? If it is gas used of the Cosmos-block, the data looks invalid because the sum would not be equals if there is Cosmos & EVM txs are mixed within one block.

Currently disabled MsgCreateVestingAccount so the other MsgCreate* should be disabled:

• MsgCreatePeriodicVestingAccount
• MsgCreatePermanentLockedAccount

This is not a bug, just different specification with Ethereum.

But for R&D, I would try to make it compatible with Ethereum to see if any problem.

Steps:

• Enhance EVMTxIndexer to support indexing two types of block hash
• Recompute EVM block hash

Makefile currently pull main/master branches of multiple repositories for swagger gen.

This would cause wrong docs generated, eg: your chain using ibc v7 but latest ibc is v8 thus generated swagger is wrong

Current behavior: it is just the bloom of the receipt of the last MsgEthereumTx executed.

Correct: It should be created from all receipts of all EVM txs (geth>>func CreateBloom(receipts Receipts) Bloom)

Beware: must pay attention of txs that was success but then failed when apply block gas, which will be treated as failed tx so the receipt must be built according.

To be done after #90 because can inherit the design

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 #88

Children tasks:

• #91
• #100