internal/ethapi: eth_simulateV1

[s1na]

This is a successor PR to #25743. This PR is based on a new iteration of the spec: ethereum/execution-apis#484.

eth_multicall takes in a list of blocks, each optionally overriding fields like number, timestamp, etc. of a base block. Each block can include calls. At each block users can override the state. There are extra features, such as:

• Include ether transfers as part of the logs
• Overriding precompile codes with evm bytecode
• Redirecting accounts to another address

Breaking changes

This PR includes the following breaking changes:

• Block override fields of eth_call and debug_traceCall have had the following fields renamed
  • coinbase -> feeRecipient
  • random -> prevRandao
  • baseFee -> baseFeePerGas

[wjmelements]

There's no reason to have a multicall interface. Either you can have one call do the multicalls or you can use batch jsonrpc.

Please reject this PR.

[s1na]

you can use batch jsonrpc.

No.

Either you can have one call do the multicalls

I believe you're referring to https://github.com/mds1/multicall. You're not able to set msg.sender to an arbitrary address there. eth_multicall simply provides much more flexibility for different simulation scenarios, allowing users to customize various EVM context fields.

[s1na]

I've seen this test fail locally and on CI. But only every once in a while. Which is confusing for me because there is no concurrent element here. I expected any failure to be persistent.

--- FAIL: TestSimulateV1 (0.16s)
    --- FAIL: TestSimulateV1/transfer-logs (0.00s)
        api_test.go:2194: test transfer-logs, result mismatch, have
            [{0xb 0x47e7c4 0xd978 0x000000000000000000000000000000000000ffff 0x0 [{0x { 0} [{0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE [0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef 0x00000000000000000000000003812438bebd2b531fb8be4c0a0b0d500318ee31 0x00000000000000000000000016a7ae22a8f1429e4a7126fadae1c6e5806d95d9] 0x0000000000000000000000000000000000000000000000000000000000000032 0xb 0x0 0x0} {0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE [0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef 0x00000000000000000000000016a7ae22a8f1429e4a7126fadae1c6e5806d95d9 0x0000000000000000000000005d412c285f9900d954dcc4751a3026782d97a492] 0x0000000000000000000000000000000000000000000000000000000000000064 0xb 0x0 0x1}] 0xd978 0x1}]}]
            , want
            [{0xb 0x47e7c4 0xd984 0x000000000000000000000000000000000000ffff 0x0 [{0x { 0} [{0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE [0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef 0x00000000000000000000000003812438bebd2b531fb8be4c0a0b0d500318ee31 0x00000000000000000000000016a7ae22a8f1429e4a7126fadae1c6e5806d95d9] 0x0000000000000000000000000000000000000000000000000000000000000032 0xb 0x0 0x0} {0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE [0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef 0x00000000000000000000000016a7ae22a8f1429e4a7126fadae1c6e5806d95d9 0x0000000000000000000000005d412c285f9900d954dcc4751a3026782d97a492] 0x0000000000000000000000000000000000000000000000000000000000000064 0xb 0x0 0x1}] 0xd984 0x1}]}]
FAIL

The difference is 12 used gas.

[s1na]

I have updated the flaky test to use a fixed address instead of random. My hunch is that it was sometimes reporting a different gas used because the random address could have had a 0 in the beginning resulting in a different txdata cost.

[holiman]

LGTM

[s1na]

Merged in master. It was a clean merge 👍

[holiman]

# github.com/ethereum/go-ethereum/internal/ethapi [github.com/ethereum/go-ethereum/internal/ethapi.test]
Error: internal/ethapi/api_test.go:3294:26: not enough arguments in call to state.NewDatabase
	have (ethdb.Database)
	want (*triedb.Database, *snapshot.Tree)
Error: internal/ethapi/api_test.go:3295:47: too many arguments in call to state.New
	have ("github.com/ethereum/go-ethereum/common".Hash, *state.CachingDB, nil)

This PR needs to be re-merged with master, following the state reader merge. I could've rebased it for you, but I know you prefer merging... :)