Is there any reason this EIP is still Draft? cc @sorpaas
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!
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.
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
1 Like
Isaac Ardis, Wei Tang, Fan Torchz, can we please get a PR to move to final here if you will proceed?
1 Like
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
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.
1 Like
Yo what’s up here…
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.
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.
1 Like
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.
2 Likes
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?
What drawback do you see in chainid.network using decimal? It can be converted easily …
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.
1 Like
no - that was not the intention.
great!
1 Like
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.
1 Like
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
2 Likes
@ligi do you recommend that 695 should revert to Draft based on those concerns, or are you just noting them for posterity?
Not sure if we need to move it back to draft for it. I think just explicitly specifying what the behavior should be to avoid problems like the one above should be enough.