Store tx hash index separately to get rid of full tendermint tx indexes

[yihuang]

Proposal: Store tx hash index separately to get rid of full tendermint tx indexes

Current behavior:

rely on full nodes to turn on tendermint tx indexer, cost extra storage space, and slow down consensus state machine.

Desired behavior:

• Use a standalone kv db to store eth tx hash -> cosmos tx hash.
• The eth tx hash index will include all the eth msgs in the block, no matter the execution result.
• Support the unlucky tx that exceeds block gas limit into the json-rpc apis, since user fee is deducted in this case, it should leave a trace in json-rpc responses.

Use case:

• Reduce storage cost, because the db size increase fast. Problem: db size increase too fast crypto-org-chain/cronos#451 (comment)
• Support some failed transactions in json-rpc responses.

[yihuang]

This will also solve the failed tx hash not found issue, we don't need to manipulate the events anymore: #1062

[fedekunze]

I feel that we should we try to prioritize the modular hasher ADR: tendermint/tendermint#6539. Any other solution will involve additional maintenance and overhead

[yihuang]

I feel that we should we try to prioritize the modular hasher ADR: tendermint/tendermint#6539. Any other solution will involve additional maintenance and overhead

Can modular hash handle multiples messages(eth tx) in one tm tx?

[JayT106]

I feel that we should we try to prioritize the modular hasher ADR: tendermint/tendermint#6539. Any other solution will involve additional maintenance and overhead

Can modular hash handle multiples messages(eth tx) in one tm tx?

From the Tendermint dev's decision, they would prefer to do it in ABCI++ during prepareproposal .

https://github.com/tendermint/tendermint/pull/8033/files#diff-d4c2afdd9920a19ba459ab66bb2ffa4e732447831618f6e8777e811314ef76e7R155

[yihuang]

crypto-org-chain/cronos#451 (comment)

BTW, there's an option to fine turn what events to index, we can use that to shrink the tx indexer db size, so db size is less of a motivation for this proposal.

The other potential motivations are:

• to cover more tx than tm tx indexer, this may also be solved by emitting an eth tx hash event at the very beginning of ante handlers for eth tx, so the failed tx can be indexed too.
• I've seen the /tx_search call shown as hotspot in json-rpc api profiling, there's an expression parser there, so using a simply kv db query will improve performance.

[tomtau]

One more motivation is not having the the indexer affected by unrelated tm issues that may take some time to diagnose and fix: tendermint/tendermint#5281

[yihuang]

I think we can implement this extra indexer as an optional feature, like if the extra indexer is not initialized, the json-rpc can fallback to current logic.
and the indexing process can run asynchronously, monitoring the chain progress with the tm client api.
it'll workaround two known issues:

• tx is missing when it exceeds block gas limit
• tendermint includes duplicated txs which overrides the tx result

[JayT106]

Found the discussion from the slack TM sharing channel, this is a workaround for the duplicate tx indexing issue
terra-money/tendermint#76

[yihuang]

By doing a reindexing for the old blocks, we can deprecate some old json-rpc fallback logic which is ugly and inefficient:
https://github.com/tharsis/ethermint/blob/main/rpc/namespaces/ethereum/eth/api.go#L904