Bug in eth_simulateV1 JSON-RPC: Can not simulate historical transaction as expected.

[xuht724]

System information

Geth version: `Version: 1.14.13-unstable
CL client & version: e.g. lighthouse/
OS & Version: Linux

Expected behaviour

I am trying to use eth_simulateV1 api to simulate historical transactions and I meet unexpected revert. Here is my code:

import axios from "axios";
import { parseUnits } from "viem";

async function main() {
  const response = await axios.post(
    'http://localhost:8545',
    {
      'jsonrpc': '2.0',
      'method': 'eth_simulateV1',
      'params': [
        {
          'blockStateCalls': [
            {

              'calls': [
                {
                  'from': '0x8e90675E889fcf027d47B04D859aA537f7052626',
                  'to': '0x00000688768803Bbd44095770895ad27ad6b0d95',
                  'maxFeePerGas': '0x' + parseUnits('7.725034766', 9).toString(16),
                  'data': '0xf497df75e26b997716bc2fe71aa3286e0665c7d2301190e3e5e3d676f179aa7ab81eeb8400000000000000000000000050fc97526ba0878eb9aa87812b2074f4e600f9e9000000000000000000000000000000000000000000000000000000000000000000000000000000000000000062d0a8458ed7719fdaf978fe5929c6d342b0bfce000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2000000000000000000000000000000000000000000006678ec0dbc575c20000000000000000000000000000000000000000000000000000035058159c62ca9e24a80000000000000000000000000000000006767d82a00000000000000000000b3e76cb88f37002141d6a54af40ee6aa2ae915f0edec20b5939534cc94cdc19ecdcff026298a528223ceeb6852423f237024bba7284fc34e2db9918a4eae84c80000000000000000000000000000000000000000000028f5d1f68737b4fca91a8000010f0003740000000000000000000000000000000000154c4676b3e329ca00000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000483000000ef0000005e0000005e0000005e0000005e0000002f0000000000000000fb2809a5314473e1165f6b58018e20ed8f07b840000c92000014df6767d76a0000b400d0ed00bccf0090000c920024fb2809a5314473e1165f6b58018e20ed8f07b840000c92000014df6767d76a0000b400d0ed00bccf0090000c920024fb2809a5314473e1165f6b58018e20ed8f07b8406767d752b09498030ae3416b66dc0000b8394f2220fac7e6ade60000339fb574bdc56763f9950000d18bd45f0b94f54a968f0000d61b892b2ad6249011850000ade19567bb538035ed360000617556ed277ab3223378000095770895ad27ad6b0d9500006a637b6b08ebe78b9da500006de5e0e428ac771d77b500005000000688768803bbd44095770895ad27ad6b0d9500000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000002644dcebcba000000000000000000000000000000000000000000000000000000006767d7e000000000000000000000000000000688768803bbd44095770895ad27ad6b0d95000000000000000000000000807cf9a772d5a3f9cefbc1192e939d62f0d9bd38000000000000000000000000000000000000000000000000181374bb9c0866f400000000000000000000000062d0a8458ed7719fdaf978fe5929c6d342b0bfce000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc20000000000000000000000000000000000000000000028f5d1f68737b4fca91a00000000000000000000000000000000000000000000000015526314823acae400000000000000000000000000000688768803bbd44095770895ad27ad6b0d950000000000000000000000000000000000000000000000000000000000000000fb9be256d0bc2a1aa87c773fd95a4df00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000004198c6fc4439fb19b8beb90d01c6fc967301fb5617821c8e080bfb34e0a6cfa5bf6af36783ad7d0ce3f177e35199f459b654587be5b528463ba75270af1990b32f1c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
                },
              ]
            }
          ],
          "traceTransfers":true,
        },
        '0x' + (21457054).toString(16)
      ],
      'id': 1
    },
    {
      headers: {
        'Content-Type': 'application/json'
      }
    }
  );
  console.log('get response:', response)
  console.log('result:', JSON.stringify(response.data.result, null, 4))
  let txStatus = parseInt(response.data.result[0].calls[0].status, 16)
  if (txStatus) {
    console.log('success !')
    console.log('gas used:', response.data.result[0].gasUsed)
  }
  else {
    console.log('failed')
  }
}
main()

This transaction is a trx to fill 1inch order and has been included in block 21457055.
The simulation result is below and this error is caused by the price slippage. I guess this may be caused by uncorrect setting of block timestamp environment variable.

    {
        "baseFeePerGas": "0x0",
        "blobGasUsed": "0x0",
        "calls": [
            {
                "returnData": "0x",
                "logs": [],
                "gasUsed": "0xe89d",
                "status": "0x0",
                "error": {
                    "message": "execution reverted",
                    "code": -32000,
                    "data": "0xfb8ae129"
                }
            }
        ],
        "difficulty": "0x0",
        "excessBlobGas": "0x1f20000",
        "extraData": "0x",
        "gasLimit": "0x1c9c380",
        "gasUsed": "0xe89d",
        "hash": "0x1b3a217ed483cc9cfecc737756fed458763a3aaffb9266f04484fd22e6a9453b",
        "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
        "miner": "0x4838b106fce9647bdf1e7877bf73ce8b0bad5f97",
        "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "nonce": "0x0000000000000000",
        "number": "0x147689f",
        "parentBeaconBlockRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "parentHash": "0xc8d4bcd2f1558f9c7a4648644969348f31aae36fc048be1b4d984e89ef51d9c5",
        "receiptsRoot": "0x482f6b57b3028ec19a3effce63f4d43ee181ff999fd4a026a118dbd672b8e8e4",
        "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
        "size": "0x8e7",
        "stateRoot": "0x87bb2cb73962353c90f6c75b75df6ca2025a4cdcd94bd7eca365c9a7b3bd1b0f",
        "timestamp": "0x6767d780",
        "transactions": [
            "0x5c839cd87d99b65d1fb4b48128868b1ecfcd9cba283c9929fe66f71d9027c87f"
        ],
        "transactionsRoot": "0x5653fefe5c891487778f72908f50c1d51ff3435214010fcd376adf62df3161a6",
        "uncles": [],
        "withdrawals": [],
        "withdrawalsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421"
    }

Actual behaviour

The transaction has been included in block. Therefore, the simulation result should be successful.

Steps to reproduce the behaviour

You can use my code to test, if the state is expired, please use archive node.

[s1na]

The tx in question has position 6 in the block. Is it not possible that one of the prior txes has changed relevant parts of state?

[xuht724]

The tx in question has position 6 in the block. Is it not possible that one of the prior txes has changed relevant parts of state?

I have checked before trxs, those trxs do not change the related state before.

[xuht724]

The tx in question has position 6 in the block. Is it not possible that one of the prior txes has changed relevant parts of state?

We find if we pass a block timestamp + 100s, the trx will be simulated successfully, therefore, we think it may be the block timestamp setting error?

[s1na]

The tx in question has position 6 in the block. Is it not possible that one of the prior txes has changed relevant parts of state?

We find if we pass a block timestamp + 100s, the trx will be simulated successfully, therefore, we think it may be the block timestamp setting error?

That is helpful info. Indeed it's possible. eth_simulateV1 will default to "baseBlock.timestamp +1". This is about to change, i.e. the increment will be 12s: #30981. Can you try if you provide block timestamp + 12 will it work?

[holiman]

Assuming this is fixed, closing. Feel free to reopen if the issue persists