Ethereum Stack Exchange is a question and answer site for users of Ethereum, the decentralized application platform and smart contract enabled blockchain. It only takes a minute to sign up.
Sign up to join this community
Multiple JSON-RPC API functions take an optional block number argument:
eth_getBalanceeth_getCodeeth_getTransactionCounteth_getStorageAteth_callMy questions is this: for historical blocks, is the result of the function call guaranteed to be the value after the block? Or it can also return values during, or at the start of that block?
For the JSON-RPC API functions you mentioned (eth_getBalance, eth_getCode, eth_getTransactionCount, eth_getStorageAt, and eth_call), the result of the function call with a historical block number specified is guaranteed to be the state of the blockchain after the execution of transactions in that block.
When you provide a historical block number as an argument to these functions, you are asking for the state of the blockchain at that point in time. The result of the function call will be based on the state of the blockchain after all transactions in that block have been executed.
For example, if you use eth_getBalance to query the balance of an account at a historical block number, the result will be the balance of that account after all transactions in that block have been executed. Similarly, if you use eth_getTransactionCount to query the number of transactions sent from an account at a historical block number, the result will be the number of transactions sent from that account after all transactions in that block have been executed.
Therefore, you can rely on the result of the function call with a historical block number specified to accurately reflect the state of the blockchain at that point in time, after all transactions in that block have been executed.
The result is based on the state at the end of the previous block.
This means the start of the block.
Edited:
Sorry I need to be more specific here. For historical transactions, you need to specify the block number as the previous block.
For example, if you want to simulate a transaction using eth_call from block 123, you need to specify blockNumber as 122 in order to obtain the correct result.
JakuAme is right:
The result of the function call will be based on the state of the blockchain after all transactions in that block have been executed.
Edit 2: Taking block 123 as an example
eth_getBalance - returns the balance of the account after executing block 123
eth_getCode - Returns smart contract code after block execution. If a smart contract is deployed in block 123, this will return the deployed code.
eth_getTransactionCount - Get the transaction count of block 123
eth_getStorageAt - Returns value after block execution, if a value is changed in block 123, this will return the updated value.
eth_call - Execution is based on the state after block 123 execution. If you are trying to simulate a transaction from block 123, you need to specify block 122.
For your question:
for historical blocks, is the result of the function call guaranteed to be the value after the block?
I thought you are asking about calling a smart contract function from an old block. Sorry for the confusion caused.
The result of the function call for historical blocks depends on the block number argument provided. When using JSON-RPC API functions that accept an optional block number argument, such as eth_getBalance, eth_getCode, eth_getTransactionCount, eth_getStorageAt, and eth_call, the result will represent the state after the specified block has been processed.
In other words, when you provide a block number as an argument, the function call will return the value at the end of the block execution. It does not return values during or at the start of that block.
It's important to note that for real-time or 'pending' transactions, the results may not be final as they might still be in the process of being added to the blockchain. In such cases, you can use the 'latest' or 'pending' keywords as the block number argument to get the most recent state or pending state, respectively.
