You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It isn't clear from the spec whether estimateGas should run in the context of the block hash/num provided, or if it should treat it as its parent. By accepting block overrides, we can remove the ambiguity and allow callers to choose exactly what the environment their call executes in.
The text was updated successfully, but these errors were encountered:
“next” is a cool idea, especially if (at least from what I’ve heard) “pending” may be retired soon.
It would also be useful for other methods such as eth_call et al. as a way to simulate something as “what if this transaction were executed as the first transaction in the upcoming block” (which is semantically distinct from “latest”).
A use-case that came up regarding ☝️ was in the context of linear vesting where I wanted to query how much vesting was available in the upcoming block (which is the earliest block in which a transaction would execute) instead of how much is available on the “latest” block. With some execution nodes, this worked with “pending” (but not all - notably not Nethermind).
It isn't clear from the spec whether
estimateGas
should run in the context of the block hash/num provided, or if it should treat it as its parent. By accepting block overrides, we can remove the ambiguity and allow callers to choose exactly what the environment their call executes in.The text was updated successfully, but these errors were encountered: