fix: trace tx/block gas meter to make it consistent with execution

[GAtom22]

Description

---

Closes ENG-1942

[linear]

ENG-1942 Precompile Txs: Inconsistent response on `debug_traceTransaction`

Reported by: VictorTrustyDev (escan team)

This happens in txs to precompiled contracts

The information returned on the debug_traceTransaction method of the JSON-RPC API is inconsistent with the tx information returned on the cosmos API.

It was reported that when calling the debug_traceTransaction of a successful transaction, the response shows an out of gas error and the gasUsed == gasWanted. This information is not consistent to the information returned when querying as cosmos transaction.

Example:

https://testnet.mintscan.io/evmos-testnet/txs/75520684066CDFFF0784C0DA88C343CFF7435BA6F748EF9A9955A091C3379E3E?height=15264861

Ethereum TX Hash 0xbc8f8009488ea61f62f96fd527e83857fb359f631b742c5f50d5c59c8fdee36b
Success Yes
Gas Used 176,914 | 56.39 %

curl https://eth.bd.evmos.dev:8545 \
-X POST \
-H "Content-Type: application/json" \
--data '{"method":"debug_traceTransaction","params":["0xbc8f8009488ea61f62f96fd527e83857fb359f631b742c5f50d5c59c8fdee36b", {"tracer": "callTracer" } ], "id":1,"jsonrpc":"2.0"}' | jq

{
 "jsonrpc": "2.0",
 "id": 1,
 "result": {
 "error": "out of gas",
 "from": "0x21310d53e6d828ba8e9570c7dccfc0c28795b182",
 "gas": "0x47121",
 "gasUsed": "0x47121",
 "input": "0xb6039895000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000094596e300000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000232f636f736d6f732e7374616b696e672e763162657461312e4d736744656c65676174650000000000000000000000000000000000000000000000000000000000",
 "to": "0x0000000000000000000000000000000000000800",
 "type": "CALL",
 "value": "0x0"
 }
}

Other txs reported with this issue:

15762891    0x63ea782d0f204bd2ab64a3f797e607f4c9f6ea65764dcf6413179c58014ffd61 call to 0x0000000000000000000000000000000000000802
15399327    0x4c0752fb38f4684eae694d2925ee0d0d854ab465f594f7681d566a8ca958b4f4 call to 0x0000000000000000000000000000000000000802
15390158    0x770b6ad1586a5770e485402d8c66e1fb83eaa07bc35c58892818b8cc3e46ce2f call to 0x0000000000000000000000000000000000000801
15264880    0x90d5e8cd6079975b11ddca485197e6fbd57d63988fc9104d25031d946cdf498d call to 0x0000000000000000000000000000000000000800
15264861    0xbc8f8009488ea61f62f96fd527e83857fb359f631b742c5f50d5c59c8fdee36b call to 0x0000000000000000000000000000000000000800
15264852    0xd7f97dcfaec014a7fb81eaa00953f275b72757fe379af4ffd02185664fd23bf3 call to 0x0000000000000000000000000000000000000800
15225439    0x6c7bec2e3ad459ffba1ecd85787fd44458b5a4232c6a8e93ede99ade1a224800 call to 0x4C3c09c59ce5B9FAa1314ee2D8860129346edE52 which invoke 0x0000000000000000000000000000000000000800
15167475    0xb72a78d1ee6be2c6073db0669b8a0e344bc20b5febd12c3358977b8d48a26ce2 call to 0x0000000000000000000000000000000000000800
15160604    0xc44de19910be2cd4b21cf69e1818a216e31c9e4e97308e435b255d07ecf8a132 call to 0xb45Cc7BB5Edd3e93E499a9E58f5db82e998664F5 which invoke 0x0000000000000000000000000000000000000800
15159890    0x3bd4075750a1afd55db53c919faf406236e6496aa40e4eaba3b07d5a96f4b0fc call to 0xb45Cc7BB5Edd3e93E499a9E58f5db82e998664F5 which invoke 0x0000000000000000000000000000000000000800
15027197    0xc35a71d3d1ac71a22198756fd978ab307148dd2bdcdef3f8a9cc548d25f41de4 call to 0xE926a257816E1B7083F71074Dd8A02CcF1eBb27C which invoke 0x0000000000000000000000000000000000000801
15026802    0x2fdbd576aa40240f28c3e60f699285aafa7e2aab9fc93ed2066001ca688a5062 call to 0xE926a257816E1B7083F71074Dd8A02CcF1eBb27C which invoke 0x0000000000000000000000000000000000000801
14958053    0xd2d8ad456bca0203b9949f0fbc585e068d6d3c3503eca7caeb07aabfd85b4eb9 call to 0xa2354A026DfE759082e286097baDFFBe94b28974 which invoke 0x0000000000000000000000000000000000000800
14904147    0xcf8a37a9a87ae0e68d10c7e5a69f41d6bc47dc08dce1de1aad7447dc447c7b59 call to 0x314675FA5ce801c1181c5F52e1b4a841642D671c which invoke 0x0000000000000000000000000000000000000800

Additional comments from Victor:

The error comes from the RunSetupfunction

image.png

Seems to be related on how the gas is estimated:

Setup New gas meter: contract.Gas=143336 and consume initialGas=298823

image.png

about consume 298823 when gas only 143336

https://testnet.mintscan.io/evmos-testnet/txs/0x4c0752fb38f4684eae694d2925ee0d0d854ab465f594f7681d566a8ca958b4f4
Gas (used / wanted) 83,680 / 167,360

somehow initial gas already greater than gas limit

Could be related to the logic in the TraceTx , there it seems to stack the gas from the predecessors
Tracing iterator and apply previous messages, thus consume gas
thus gas meter in the sdk context got stacked

image.png

[codecov]

Codecov Report

Merging #1676 (d3316d1) into main (99c577e) will increase coverage by 0.02%.
The diff coverage is 72.00%.

❗ Current head d3316d1 differs from pull request most recent head 01e16f2. Consider uploading reports for the commit 01e16f2 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1676      +/-   ##
==========================================
+ Coverage   70.22%   70.24%   +0.02%     
==========================================
  Files         296      296              
  Lines       22059    22096      +37     
==========================================
+ Hits        15491    15522      +31     
- Misses       5818     5820       +2     
- Partials      750      754       +4     

Files Changed	Coverage Δ
x/feemarket/keeper/params.go	60.00% <20.00%> (-5.00%)	⬇️
rpc/backend/tracing.go	61.02% <40.00%> (-1.67%)	⬇️
x/evm/keeper/grpc_query.go	86.69% <100.00%> (+0.79%)	⬆️
x/evm/keeper/keeper.go	88.88% <100.00%> (+1.95%)	⬆️

[VictorTrustyDev]

@GAtom22, On legacy blocks, the params MinGasPrice of x/feemarket is nil, thus panic here when tracing.

#1670

[facs95]

Great work @GAtom22! LGTM

[VictorTrustyDev]

Please shorten the NewInfiniteGasMeterWithLimit lines to increase readability