list of RPC calls used by hive rpc simulator

[jangko]

This is a list of rpc calls used by hive rpc simulator we need to focus on: see https://ethereum.org/en/developers/docs/apis/json-rpc/ for what are expected output from these calls.

Implemented but not tested thoroughly -- already understand where to get the information and how to implement it correctly:

• [x] BlockNumber / eth_blockNumber(true)
• [x] BlockByNumber / eth_getBlockByNumber(true)
• [x] BlockByHash / eth_getBlockByHash
• [x] NonceAt / eth_getTransactionCount
• [x] CodeAt / eth_getCode
• [x] BalanceAt / eth_getBalance
• [x] StorageAt / eth_getStorageAt
• [x] HeaderByHash / eth_getBlockByHash(false)
• [x] HeaderByNumber / eth_getBlockByNumber(false)
• [x] TransactionInBlock / eth_getTransactionByBlockHashAndIndex
• [x] TransactionByHash / eth_getTransactionByHash
• [x] TransactionCount / eth_getBlockTransactionCountByHash
• [x] TransactionReceipt / eth_getTransactionReceipt

Implemented but incomplete and maybe wrong -- poorly understood:

• [ ] SyncProgress / eth_syncing -- where the information can obtained? in eth node + validator?
• [x] SendTransaction / eth_sendTransaction -- need #474 and #469, but how to process the next step?
• [ ] EstimateGas / eth_estimateGas -- where is the formula/equation from? EVM?

Not implemented -- no idea yet -- How the subscription works?

• [ ] SubscribeNewHead / EthSubscribe("newHeads") --- from syncing or mining?
• [ ] SubscribeFilterLogs/ EthSubscribe("logs") --- tx logs or header logs?

[jlokier]

• SyncProgress / eth_syncing returns numbers which are updated in BaseChainDB. It's updated by classic sync in our blockchain_sync.nim and persist_blocks.nim. The information is semi-obsolete, because it doesn't make sense for showing real progress with current syncing methods, even in Geth. In Geth, it does at least show when sync has reached the head and is following new blocks. In Nimbus Eth1, at the moment, it may gives a misleading answer because highestBlock isn't actively updated in real time with new blocks.

• SendTransaction / eth_sendTransaction doesn't need Clique PoA consensus engine, so I think that connection should be removed or explained in your list.

• SendTransaction / eth_sendTransaction is for posting transactions to the network pool, for broadcast across the network so that miners will pick it up. It does need a transaction pool, but only the network functionality, there is no need for the pool to check if the transaction has been accepted, or detect its removal in reorgs. That question is pushed up to the application calling eth_sendTransaction: For the application to know when its transaction is accepted, or removed by a reorg, it queries TransactionReceipt / eth_getTransactionReceipt. As you pointed out, that's already implemented.

• EstimateGas / eth_estimateGas are calculated by calling the EVM on current head block state. It's implemented in call_evm.nim as rpcEstimateGas. I don't know if the implemented method accurately replicates what other clients do. I've made sure it does the same as the earlier RPC code did, but there were interesting assumptions and gas processing steps that code, and they should be checked against what Geth does. I believe Infura added some limiting parameters to prevent this call from using too many resources, and limits were later added to Geth, where they are configurable.

• SubscribeNewHead / EthSubscribe("newHeads") is to report new canonical chain heads received from the network, after they are validated. It's meant for real-time updates after the initial sync is complete. It can report more than one new block if there's a reorg, as the new chain will have multiple blocks the subscriber hasn't seen yet. The documentation at Infura describes it quite well.

• SubscribeFilterLogs / EthSubscribe("logs") is about transaction logs. It's related to eth_getLogs, eth_newFilter, eth_getFilterLogs and eth_GetFilterChanges. Especially the last one, as that's the polling equivalent to SubscribeFilterLogs. See Why use filters - eth_getLogs vs eth_newFilter.