Discussion thread for EIP-695: https://eips.ethereum.org/EIPS/eip-695
Quantity in this context feels wrong - it’s not really a quantity - it’s an ID:
I think this thread is relevant for the discussion of the EIP-1637
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
Isaac Ardis, Wei Tang, Fan Torchz, can we please get a PR to move to final here if you will proceed?
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.
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.
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.
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.
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.
no - that was not the intention.
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.
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