EIP-695: Create `eth_chainId` method for JSON-RPC

sorpaas · November 8, 2018, 3:50pm

Discussion thread for EIP-695: https://eips.ethereum.org/EIPS/eip-695

ligi · November 8, 2018, 9:14pm

Quantity in this context feels wrong - it’s not really a quantity - it’s an ID:

pedrouid · December 4, 2018, 3:34pm

I think this thread is relevant for the discussion of the EIP-1637

pedrouid · May 21, 2019, 1:22pm

Is there any reason this EIP is still Draft? cc @sorpaas

sorpaas · June 20, 2019, 11:08am

Just moved EIP-695 to last call status (https://github.com/ethereum/EIPs/pull/2128) with a review period of 4 weeks. Any comments appreciated!

sorpaas · June 20, 2019, 11:20am

I think it’s just naming convention for Ethereum JSON-RPC. We probably should have named everything as “Hex Numbers”, but for historical reasons they’re all named “QUANTITY” in current JSON-RPC docs.

fulldecent · June 22, 2019, 7:08pm

I have completely reviewed this EIP and fully endorse it to go to FINAL status as is.

One potential improvement is this minor correction https://github.com/ethereum/EIPs/pull/2133

fulldecent · July 29, 2019, 2:48pm

Isaac Ardis, Wei Tang, Fan Torchz, can we please get a PR to move to final here if you will proceed?

fubuloubu · July 29, 2019, 7:43pm

This EIP is more relevant considering EIP-1344’s inclusion into Istanbul, which will define a client-side configuration value that is available internally to the EVM, to which this proposal can make use of.

Discussion here: EIP-1344: Add chain id opcode

fubuloubu · August 1, 2019, 7:57pm

Just noticed that, like EIP-1344, it should probably be included in the rationale that the client needs to independently provide the value of Chain ID instead of looking it up from the latest signed transaction. Transactions currently have a corner case where both EIP155 compliant and non-EIP155 compliant transactions will validate, so this is not a reliable source of this value, but rather should be checked against the internally-provided configuration of chain ID.

fulldecent · August 7, 2019, 2:37am

Yo what’s up here…

fubuloubu · August 7, 2019, 12:34pm

I believe both Parity and geth implement this endpoint, so it could probably get finalized on the next ACD call?

Edit: one thing to note is that the quantity should be a uint256 because of the opcode and the future potential scenario where it could be a 32 byte hash.

ajsutton · August 7, 2019, 9:43pm

Pantheon also supports it and I believe MetaMask is already using it. I’m a little surprised this isn’t already final to be honest.

And the spec does explicitly reference the “configured chain ID” although admittedly the meaning of that felt a lot clearer prior to all the discussions around the CHAINID opcode. Mostly because this JSON-RPC method doesn’t execute in the context of a transaction, it’s a big leap to jump to picking some unspecified transaction from the chain and getting the chain ID from there.

fubuloubu · August 7, 2019, 9:57pm

That discussion largely evolved into not having chain ID be set from a transaction, for the specific reason that it’s necessary to validate the EIP-155 v value against some configuration anyways. So, this EIP and EIP-1344 should just returned the configured setting from the client, as I believe they already do.

rekmarks · March 30, 2020, 3:58pm

Is anyone trying to bring this over the finish line at the moment? As @ajsutton noted back in August, MetaMask is already using this.

An unfortunate development while this EIP has been in last call is that some widely used resources in the community have started to list chainIds as decimal numbers, for instance chainId.network.

At MetaMask, we’re inclined to continue returning a hex string per this EIP. Perhaps @pedrouid or @ligi could comment in their capacity as contributors to chainId.network?

ligi · March 30, 2020, 4:29pm

What drawback do you see in chainid.network using decimal? It can be converted easily …

rekmarks · March 30, 2020, 5:08pm

In that case, I take it your intention was not to be prescriptive? I’m fine with that.

Then the remaining question is whether anyone is championing this.

ligi · March 30, 2020, 11:59pm

no - that was not the intention.

great!

pedrouid · March 31, 2020, 5:43pm

Basically going to repeat what @ligi said already. The chainId’s on chainid.network using decimal is purely informative.

I agree that eth_chainId JSON-RPC response should be in hexadecimal format. In fact, that should just be a rule for all values of Ethereum’s JSON-RPC API.

ligi · April 9, 2020, 8:44am

it could make sense to to specify exactly what "describing the currently configured CHAIN_ID" means. As there are 2 edge cases:

what is with chains that did not start with EIP-155
what is with chains that changed the chainID in a fork

this was leading to an issue here:

Also I think we should add eth_chanId to: https://github.com/ethereum/wiki/wiki/JSON-RPC