This repository has been archived by the owner on Oct 4, 2019. It is now read-only.
implement 'eth_chainId' JSON-RPC method #336
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
solution: do it - update changelog fixes ethereumproject#335
sorpaas
approved these changes
Aug 18, 2017
There was a problem hiding this comment.
I think what currently proposed would be good. Not every client would be able to return the fork block number. For example, in Parity chainID is hardcoded.
I would also suggest we try to get chainID RPC into Parity and ETH's go-ethereum. This would help a lot in helping apps such as MetaMask to support multi-chain.
sorpaas
added a commit
to sorpaas/parity
that referenced
this pull request
Aug 18, 2017
Currently although we can use `net_version` RPC call to get the current network ID, there's no RPC for querying the chain ID. This makes it impossible to determine the current actual blockchain using the RPC. An ETH/ETC client can accidentally connect to an ETC/ETH RPC endpoint without knowing it unless it tries to sign a transaction or it fetch a transaction that is known to have signed with a chain ID. This has since caused trouble for application developers, such as MetaMask, to add multi-chain support. The same RPC endpoint is also about to be merged for ETC's go-ethereum: ethereumproject/go-ethereum#336
gavofyork
pushed a commit
to openethereum/parity-ethereum
that referenced
this pull request
Sep 26, 2017
* Add RPC eth_chainId for querying the current blockchain chain ID Currently although we can use `net_version` RPC call to get the current network ID, there's no RPC for querying the chain ID. This makes it impossible to determine the current actual blockchain using the RPC. An ETH/ETC client can accidentally connect to an ETC/ETH RPC endpoint without knowing it unless it tries to sign a transaction or it fetch a transaction that is known to have signed with a chain ID. This has since caused trouble for application developers, such as MetaMask, to add multi-chain support. The same RPC endpoint is also about to be merged for ETC's go-ethereum: ethereumproject/go-ethereum#336 * Add eth_chainId to js's web3 interface * Add a mocked test for eth_chainId * Add chainId in js's jsonrpc interfaces * Change return type for eth_chainId to `Option<u64>` * Change name eth_chainId to parity_chainId * Wrong test name and missed var for rpc_parity_chain_id test * Use U256 to return chainId and fix for master u64 returns decimal integer, and there seems to be no type called U64. So here I use U256 to return the hex integer. * Fix chainID test Before EIP155 fork number, chainID should be null. * Change both parity_chainId and transaction::chainId to use U64 This makes it consistent that all chain ids returned are hex string. * Fix wrong U64 serialization
2 tasks
This was referenced Oct 19, 2018
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rel #335
I chose to return the number in hexadecimal format because that's consistent with the other
eth_call returning a *big.Inteth_gasPrice. I'm not set on this; it may be better to return as a plain int since there's no need for _big_ness. Another option would be to return as a string, akin tonet_version, which returns"1"and"2".In case no chain id is configured, it will return 0.
Finally, it may be useful to also include the fork number at which EIP155 is implemented for the given configuration; Morden -> 1915000, Mainnet -> 3000000, custom/private -> n
Eg:
Current proposed:
{ "jsonrpc": "2.0", "id": 1, "result": "0x3d" }or possibly with fork number:
{ "jsonrpc": "2.0", "id": 1, "result": { "chainId": "0x3d", "blockNumber": "0x2dc6c0" } }Thoughts welcome.