Problem: eth tx sender recovery is slow

[yihuang]

Solution:

• update ethermint dependency, do the recovery once in ante handler and cache the result

Benchmark result improve from 1.3s -> 0.9s, 1k+ erc20 transfer TPS achived in this benchmark ;D

$ go test -run=^$ -bench=BenchmarkERC20Transfer -benchmem ./app -count=3
goos: darwin
goarch: amd64
pkg: github.com/crypto-org-chain/cronos/v2/app
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
BenchmarkERC20Transfer/memdb-12         	       2	 898359140 ns/op	275876728 B/op	 4689863 allocs/op
BenchmarkERC20Transfer/memdb-12         	       2	 918545580 ns/op	275865808 B/op	 4689827 allocs/op
BenchmarkERC20Transfer/memdb-12         	       2	 915937210 ns/op	275905872 B/op	 4690029 allocs/op
BenchmarkERC20Transfer/leveldb-12       	       2	 985876458 ns/op	277770568 B/op	 4688924 allocs/op
BenchmarkERC20Transfer/leveldb-12       	       2	1050278982 ns/op	277757240 B/op	 4688916 allocs/op
BenchmarkERC20Transfer/leveldb-12       	       1	1192915378 ns/op	276416192 B/op	 4679697 allocs/op
PASS
ok  	github.com/crypto-org-chain/cronos/v2/app	28.915s

👮🏻👮🏻👮🏻 !!!! REFERENCE THE PROBLEM YOUR ARE SOLVING IN THE PR TITLE AND DESCRIBE YOUR SOLUTION HERE !!!! DO NOT FORGET !!!! 👮🏻👮🏻👮🏻

PR Checklist:

• Have you read the CONTRIBUTING.md?
• Does your PR follow the C4 patch requirements?
• Have you rebased your work on top of the latest master?
• Have you checked your code compiles? (make)
• Have you included tests for any non-trivial functionality?
• Have you checked your code passes the unit tests? (make test)
• Have you checked your code formatting is correct? (go fmt)
• Have you checked your basic code style is fine? (golangci-lint run)
• If you added any dependencies, have you checked they do not contain any known vulnerabilities? (go list -json -m all | nancy sleuth)
• If your changes affect the client infrastructure, have you run the integration test?
• If your changes affect public APIs, does your PR follow the C4 evolution of public contracts?
• If your code changes public APIs, have you incremented the crate version numbers and documented your changes in the CHANGELOG.md?
• If you are contributing for the first time, please read the agreement in CONTRIBUTING.md now and add a comment to this pull request stating that your PR is in accordance with the Developer's Certificate of Origin.

Thank you for your code, it's appreciated! :)

[codecov]

Codecov Report

Merging #928 (876f82c) into main (392eee6) will increase coverage by 15.93%.
The diff coverage is 23.07%.

@@             Coverage Diff             @@
##             main     #928       +/-   ##
===========================================
+ Coverage   21.56%   37.50%   +15.93%     
===========================================
  Files          48       75       +27     
  Lines        2991     5557     +2566     
===========================================
+ Hits          645     2084     +1439     
- Misses       2285     3251      +966     
- Partials       61      222      +161     

Impacted Files	Coverage Δ
app/upgrades.go	22.22% <23.07%> (+0.79%)	⬆️

... and 40 files with indirect coverage changes

[mmsqe]

wait, upgrade test fails

[yihuang]

wait, upgrade test fails

I see, also looking at it.

[mmsqe]

wait, upgrade test fails

I see, also looking at it.

not sure why get failed to load latest version: version of store gravity mismatch root store's version; expected 28 got 0

[yihuang]

wait, upgrade test fails

I see, also looking at it.

not sure why get failed to load latest version: version of store gravity mismatch root store's version; expected 28 got 0

we have something wrong in upgrade handler, and that's the exact mistake that's checked in new sdk version ;D

[yihuang]

wait, upgrade test fails

I see, also looking at it.

not sure why get failed to load latest version: version of store gravity mismatch root store's version; expected 28 got 0

should be fixed, let's see.