debug_traceCall against "pending" uses empty state

[Anti83]

System information

Version: 1.10.17-stable
Git Commit: 25c9b49
Architecture: amd64
Go Version: go1.18

Expected behaviour

Expected to traceCall pending transaction in context of pending block. I know about double exectution problem, but still need to trace against pending.

Actual behaviour

Every transaction I try to debug_traceCall against "pending" fails with "tracing failed: insufficient funds for gas * price + value: address 0x.. have 0 want 7149415673190000". It's always have 0 even when address has a lot.

Steps to reproduce the behaviour

Get transaction from subscription to pendingTransactions, try to debug_traceCall against "pending".
debug_traceCall against "latest" works fine.
eth_call against "pending" also works fine.
but debug_traceCall against "pending" always fails.

Backtrace

[backtrace]

When submitting logs: please submit them as text and not screenshots.

UPDATE:
eth_call against "pending" also does NOT work right. I think it uses "latest" not "pending" state. At least it uses maxFeePerGas from latest not pending

[holiman]

Repro:

[user@work go-ethereum]$ geth --dev console
...
> debug.traceCall({from: eth.accounts[0], to: eth.accounts[0], value:"0x1", gasPrice: "0xffffffff", gas: "0xffff"}, "latest")
{
  failed: false,
  gas: 21000,
  returnValue: "",
  structLogs: []
}
> debug.traceCall({from: eth.accounts[0], to: eth.accounts[0], value:"0x1", gasPrice: "0xffffffff", gas: "0xffff"}, "pending")
WARN [05-11|16:47:47.443] Served debug_traceCall                   reqid=23 duration=8.628038ms  err="tracing failed: insufficient funds for gas * price + value: address 0x8fbf6B1D5f2Aa3ce6cfB2B8247909802BE916F71 have 0 want 281470681677826"
Error: tracing failed: insufficient funds for gas * price + value: address 0x8fbf6B1D5f2Aa3ce6cfB2B8247909802BE916F71 have 0 want 281470681677826
        at web3.js:6365:37(47)
        at send (web3.js:5099:62(35))
        at <eval>:1:16(21)

[holiman]

Heh.. so what happens is that we do a tracing with the 'pending' block, with the following data;

block=1 hash=f97f11..637fc2 root=000000..000000

The stateroot is 0x000..00.
Later on, we try to get the state for this stateroot, by calling

		statedb, err = eth.blockchain.StateAt(block.Root())

Which returns a statedb, no errors!

Why? Because when opening a trie and resolving the root:

	if root != (common.Hash{}) && root != emptyRoot {
		rootnode, err := trie.resolveHash(root[:], nil)
		if err != nil {
			return nil, err
		}
		trie.root = rootnode
	}

So it returns a totally empty statedb, since root == (common.Hash{})

[Anti83]

eth_call against "pending" also does NOT work right. I think it uses "latest" not "pending" state. At least it uses maxFeePerGas from latest not pending.
UPDATE: eth_call against "pending" uses block number of pending but maxFeePerGas from latest...

[holiman]

My 5c is that we should either make it work, or explicitly reject it with an error.

[holiman]

IMO we should take a holistic approach with all the RPC call types, and try to be consistent in handling pending.
https://gist.github.com/holiman/427dde9faf552e2f01db27a8879ab331
Please help me fill out the gist with all of them

[holiman]

It seems debug_traceCall is the odd one out, since the api backend for that doesn't have the method StateAndHeaderByNumber(ctx, blockNr), which contains a shortcut to retrieve the pending. Should be not too difficult (and not totally trivial either) to make it work for that method, if we want it to.

[Anti83]

debug_traceCall against pending would be a life saver for me.
I am monitoring several MEV contracts. Trying to trace(understand what it is doing) their transactions while it is still pending. Before I was just making debug_traceCall against latest(transactions were behaving in same manner in latest like in execution), but recently these contracts added "protection" against such tracing(comparing blockNumber and/or timestamp), so in tracing against latest its doing one thing, but in reality doing another.
So my option was using hardhat/ganache, forking every block and executing transaction in fork, this was buggy and slow.
Another option is wait until interested transaction will get into my pending block(can take several seconds) and make debug_traceBlockByNumber, but that also slow.
Maybe there is another way to trace transaction in the context of pending block?

[holiman]

Tracing on pending will be quirky too. For one thing, after a while "interested transaction will get into my pending block" -- and this will make the tracing starting to fail, because it cannot be traced on top of itself.

debug_traceTransaction already supports state overrides, the idea being that you can tell it "balance of X is Y, and storage slot A has value C".

Sounds to me that what would be better in this particular usecase would be to extend the override capabilities, so you can, on top of latest state, also supply override block-context fields (timestamp, number, difficulty etc).

If we add that, it would (I think) make the override-capability pretty much complete. And if we had that, then we could just legitimately return an error when trying to trace on pending.