Eth JSON-RPC API: "latest" block does not include logs or state updates because of deferred execution

[jaeaster]

Because Filecoin tipsets do not execute messages until the next tipset, you cannot view logs or view state updates in the "latest" block.

There's a core assumption with many EVM tools and applications that "latest" implies latest mined + executed block. There are many issues and edge cases that could arise when an application believes it is reading the latest state, when in fact the state it's reading could be stale. Moreover, if you are fetching logs for each block as the block is reported by the RPC, you will actually never see any logs.

I think it would be wise to hide this detail of deferred execution from users so that existing applications and tools will work as they do with other EVM implementations.

I propose 2 changes:

1. Add another special string value to refer to latest-but-not-executed, perhaps "pending-execution"
   "latest" = block is produced and executed
   "pending-execution" = block is produced but not executed
   "pending" = mempool or equivalent
   "earliest" = origin block

2. eth_blockNumber should return "latest" as defined above

[Stebalien]

Latest generally refers to the latest tipset, and we execute that tipset on-demand. That should "just work" and the logs should exist.

[jaeaster]

Ahh ok - so what I'm seeing is not intended behavior. To be fair, I haven't verified state updates so this could just be happening with logs. And could also be related to this issue:

filecoin-project/lotus#10196

[raulk]

@jaeaster is right here.

• Ethereum latest refers to the last block recognized, accepted, and executed by the network. In Filecoin/Lotus lingo, this is the parent tipset of the head tipset (HEAD - 1).
• Ethereum pending refers to the current unexecuted block that the node is mining (or would be mining on)

There are basic expectations to respect here:

• The block height returned by eth_blockNumber == latest.
• The block returned by eth_getBlockByNumber(eth_blockNumber()) must be an executed block (have transaction outputs like receipts and logs).
• eth_getBlockByNumber(eth_blockNumber()) == eth_getBlockByNumber('latest')

[raulk]

@jaeaster I don't see the need to introduce a third enum param (pending-execution). AFAIK the pending block does not refer to "all pending transactions", but rather to a speculative block containing a subset of messages from the mempool, which the HEAD tipset in Filecoin already is.

[jaeaster]

Agreed about the lack of need for adding pending-execution since pending means the same thing in the context of RPC methods that return block-level information

[raulk]

Tracked in #1135, and fixed in filecoin-project/lotus#9837.