Client JSON-RPC Support

[ryanio]

This is a tracking issue for JSON-RPC support in the client.

Endpoint	Status
eth_accounts
eth_blockNumber	:white_check_mark:
eth_call	:white_check_mark:
eth_coinbase	:white_check_mark:
eth_compileLLL
eth_compileSolidity
eth_estimateGas	:white_check_mark:
eth_feeHistory
eth_gasPrice	:white_check_mark:
eth_getBalance	:white_check_mark:
eth_getBlockByHash	:white_check_mark:
eth_getBlockByNumber	:white_check_mark:
eth_getBlockTransactionCountByHash	:white_check_mark:
eth_getBlockTransactionCountByNumber	:white_check_mark:
eth_getCode	:white_check_mark:
eth_getCompilers
eth_getFilterChanges
eth_getFilterLogs
eth_getLogs	:white_check_mark:
eth_getStorageAt	:white_check_mark:
eth_getTransactionByBlockHashAndIndex
eth_getTransactionByBlockNumberAndIndex
eth_getTransactionByHash	:white_check_mark:
eth_getTransactionCount	:white_check_mark:
eth_getTransactionReceipt	:white_check_mark:
eth_getUncleByBlockHashAndIndex
eth_getUncleByBlockNumberAndIndex
eth_getUncleCountByBlockHash
eth_getUncleCountByBlockNumber	:white_check_mark:
eth_getWork
eth_hashrate
eth_mining
eth_newBlockFilter
eth_newFilter
eth_newPendingTransactionFilter
eth_protocolVersion	:white_check_mark:
eth_sendRawTransaction	:white_check_mark:
eth_sendTransaction
eth_sign
eth_signTransaction
eth_submitHashrate
eth_submitWork
eth_syncing	:white_check_mark:
eth_uninstallFilter
net_listening	:white_check_mark:
net_peerCount	:white_check_mark:
net_version	:white_check_mark:
web3_clientVersion	:white_check_mark:
web3_sha3	:white_check_mark:

Namespace: Real-time Events (Publish-Subscribe)

Endpoint	Status
eth_subscribe
eth_unsubscribe

Namespace: Engine API

Endpoint	Status
eth_newPayloadV1	:white_check_mark:
eth_forkchoiceUpdatedV1	:white_check_mark:
eth_getPayloadV1	:white_check_mark:
eth_exchangeTransitionConfiguration	:white_check_mark:

Namespace: Admin

Endpoint	Status
admin_addPeer	:white_check_mark:
admin_datadir
admin_nodeInfo	:white_check_mark:
admin_peers
admin_startRPC
admin_startWS
admin_stopRPC
admin_stopWS

Click to expand...Additional Namespaces

Namespace: Debug

Endpoint	Status
debug_backtraceAt
debug_blockProfile
debug_cpuProfile
debug_dumpBlock
debug_getBlockRlp
debug_memStats
debug_seedHash
debug_setHead
debug_setBlockProfileRate
debug_stacks
debug_startCPUProfile
debug_stopCPUProfile
debug_traceBlock
debug_traceBlockByNumber
debug_traceBlockByHash
debug_traceBlockFromFile
debug_standardTraceBlockToFile
debug_standardTraceBadBlockToFile
debug_traceTransaction	:white_check_mark:
debug_verbosity
debug_vmodule
debug_writeBlockProfile
debug_writeMemProfile

Namespace: LES

Endpoint	Status
les_serverInfo
les_clientInfo
les_priorityClientInfo
les_addBalance
les_setClientParams
les_setDefaultParams
les_latestCheckpoint
les_getCheckpoint

Namespace: Clique

Endpoint	Status
clique_getSnapshot
clique_getSnapshotAtHash
clique_getSigners
clique_proposals
clique_propose
clique_discard
clique_status

Namespace: Miner

Endpoint	Status
miner_getHashrate
miner_setExtra
miner_setGasPrice
miner_start
miner_stop
miner_setEtherbase

Namespace: Personal

Endpoint	Status
personal_importRawKey
personal_listAccounts
personal_lockAccount
personal_newAccount
personal_unlockAccount
personal_sendTransaction
personal_sign
personal_ecRecover

Namespace: TxPool

Endpoint	Status
txpool_content	:white_check_mark:
txpool_inspect
txpool_status

[holgerd77]

Just a reminder on this issue, it would be good if new RPC calls added would be checked here. Eventually we might also want to add the Merge RPC calls (//cc @gabrocheleau).

[holgerd77]

Is this issue still helpful or should we rather close and let this continuously evolve from what we have now?

[jochem-brouwer]

I think this is a helpful tracking issue! 😄

[ryanio]

I've been trying to keep the list updated over time as we add endpoints :)

I am planning to open a PR next week to add a bunch of missing ones from the ETH namespace that are easy, for completeness sake.

I also want to implement websockets with eth_subscribe and eth_unsubscribe and have some starting code for it but haven't prioritized finishing it yet.

[rodrigoherrerai]

Hello ! I would love to work on this, is the list updated ?

[acolytec3]

Hello ! I would love to work on this, is the list updated ?

Thanks for your interest. It certainly looks to be up to date. If you wanted to take some low hanging fruit, there are several RPC methods that I've done first draft implementations that are outlined in #2362 for our Shandong testnet that are probably good candidates to pull into master since the Shandong branch won't be merged in its current form.

[holgerd77]

Hello ! I would love to work on this, is the list updated ?

Yeah, can second this, that's great to hear! 👍

Alternatively you can also just suggest 1-3 methods you would want to implement and then we can see if there are some caveats you are eventually not yet aware of (e.g. some internal implementation details or limitations) and give you some first-round guidance if needed.

[rodrigoherrerai]

Thanks!

I was thinking of implementing 'eth_gasPrice' but as I can see @acolytec3 already has it done ?

Another option could be to start with 'eth_getBlockTransactionCountByNumber'.

[acolytec3]

I was thinking of implementing 'eth_gasPrice' but as I can see @acolytec3 already has it done ?

I don't think my implementation is "done". I just hacked something together so our client would support eth_gasPrice on the Shandong test net (since Metamask doesn't work at all otherwise). So, if you want to take what I did as purely a proof of concept and make it more robust, that would be a big win. But your other one sounds great too!

[rodrigoherrerai]

Great !

[rodrigoherrerai]

@acolytec3 One question, for eth_gasPrice, what should it return if the chain does not support 1559?

[acolytec3]

@acolytec3 One question, for eth_gasPrice, what should it return if the chain does not support 1559?

I'd do something simple like just take the average gas price from transactions in the last block or 1, whatever is greater.

[acolytec3]

Or alternatively, the average gas price of transactions in our txpool if there are any but that might be too complex for something that will be seldom used.

[holgerd77]

Or alternatively, the average gas price of transactions in our txpool if there are any but that might be too complex for something that will be seldom used.

Or maybe at least iterate over a couple of blocks (something like 15-20), maybe with a breaking condition to stop once a certain number of txs is included in the calculation (for performance reason, to not overload on heavy-load networks like mainnet, so e.g. stop with 1000 txs or so)?

We (EthereumJS client) are often operating on low-usage testnets, and we would otherwise pretty often fall back to the 1 answer, e.g. now on Shandong as well sinc - mostly - the block before is just empty.

When looking at the Shandong blocks at https://explorer.shandong.ethdevops.io/blocks, maybe 20 is even a bit low and we still can do something like 100 (open for any other suggestion) together with this 1000 txs cap? 🤔

I think it would be worth to optimize here a bit so that we can - in the majority of cases - provide at least a somewhat useful answer/estimate here.

[holgerd77]

Update: ah, sorry, didn't take "chain with no 1559" too much into account. Then suggestion might be a bit over-engineered, not sure. On the other hand, this should also not be too laborious to add/implement, so might be a nice extra.

[JowieXiang]

Hello! I would like to work on this. I'm quite new to EVM and might take more time to finish a PR. Please suggest an Endpoint so I can get started :)

[acolytec3]

eth_getTransactionByBlockHashAndIndex

If you are just starting into this, maybe eth_getTransactionByBlockHashAndIndex or eth_getUncleCountByBlockHash. These should both be relatively straightforward to implement, basically just pulling a block from the DB and either getting the transaction (simple array index lookup) or getting the length of the uncle header array and returning it.

[JowieXiang]

eth_getTransactionByBlockHashAndIndex

If you are just starting into this, maybe eth_getTransactionByBlockHashAndIndex or eth_getUncleCountByBlockHash. These should both be relatively straightforward to implement, basically just pulling a block from the DB and either getting the transaction (simple array index lookup) or getting the length of the uncle header array and returning it.

Hi @acolytec3 thanks! I'll look into them.

[JowieXiang]

@acolytec3 I've added eth_getTransactionByBlockHashAndIndex here #2443. Haven't added tests yet, will add them in a following commit in case there's still some issue with the implementation.

[JowieXiang]

@acolytec3 tests added. #2443