-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Add RPC eth_chainId for querying the current blockchain chain ID #6329
Conversation
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
It looks like @sorpaas hasn'signed our Contributor License Agreement, yet.
You can read and sign our full Contributor License Agreement at the following URL: https://cla.parity.io Once you've signed, plesae reply to this thread with Many thanks, Parity Technologies CLA Bot |
67ef961
to
7f8f215
Compare
[clabot:check] |
It looks like @sorpaas signed our Contributor License Agreement. 👍 Many thanks, Parity Technologies CLA Bot |
+1 on this PR, I faced with this problem when using web3.js which is using the getId by default |
Just created a EIP694 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A small grumble regarding types.
Also this pollutes eth_*
namespace and it has been agreed that those namespaces are reserved only for cross-client compatbile RPC methods that preferrable has gone through the EIP process.
rpc/src/v1/impls/eth.rs
Outdated
@@ -284,6 +284,11 @@ impl<C, SN: ?Sized, S: ?Sized, M, EM> Eth for EthClient<C, SN, S, M, EM> where | |||
Ok(format!("{}", version)) | |||
} | |||
|
|||
fn chain_id(&self) -> Result<String, Error> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Chain id in the transactions is serialized as Option<u64>
, would be best to keep it constistent.
IMHO using a generic String
response is a bit misleading. If we want to return a hex-encoded value then Option<U64>
would be a right choice.
Note that using Option
indicates that in case the chain id is missing null
will be returned.
I also disagree with polluting the |
Agree, an int in string type would be better for extension and compatibility here, how about changing it in EIP694 @sorpaas & @whilei, any thoughts? In this case we need to modify the etc geth implementation accordingly. |
@tcz001 I've created an EIP-rpc_chain_id as a PR (since it should be a PR rather than an issue) which is almost exactly like your issue EIP694 -- maybe we can switch to using the PR as a reference? I used a bigint in hexadecimal because that's in line with the rest of the |
Thx, will close that issue |
Build failure seems unrelated. Will be happy to merge under |
Tests fail with |
u64 returns decimal integer, and there seems to be no type called U64. So here I use U256 to return the hex integer.
Before EIP155 fork number, chainID should be null.
rpc/src/v1/impls/parity.rs
Outdated
@@ -200,6 +200,10 @@ impl<C, M, U> Parity for ParityClient<C, M, U> where | |||
Ok(self.settings.chain.clone()) | |||
} | |||
|
|||
fn chain_id(&self) -> Result<Option<U256>, Error> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- minor:
U64
would be enough - As mentioned earlier
chain_id
is already returned as decimal (u64
) in transactions and I'd prefer consistency (either allU64
(hex) or allu64
(decimal)).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tomusdrw Where's the U64 struct defined?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thought we already have it, but seems we only have U128 and U256. You can create U64
in types/uint.rs
.
This makes it consistent that all chain ids returned are hex string.
rpc/src/v1/types/uint.rs
Outdated
|
||
impl serde::Serialize for U64 { | ||
fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error> where S: serde::Serializer { | ||
serializer.serialize_str(&format!("0x{}", self.0)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't think this will actually format as hex. maybe {:h}
? @tomusdrw should it be left-padded with zeros?
|
* ethereum/EIPs#695 * Original PR is openethereum#6329
* ethereum/EIPs#695 * Original PR is openethereum#6329
* ethereum/EIPs#695 * Original PR is openethereum#6329
* Support eth_chainId RPC method * ethereum/EIPs#695 * Original PR is #6329 * rpc: remove parity_chainId
Currently although we can use
net_version
RPC call to get thecurrent 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