15f61ed0fd
I have gone through and updated all existing EIPs to match this rule, including EIP-1. In some cases, people were using markdown citations, I suspect because the long-form was a bit verbose to inline. Since the relative path is quite short, I moved these to inline but I wouldn't be opposed to putting them back to citation format if that is desired by the authors. In doing the migration/cleanup, I found some EIP references to EIPs that don't actually exist. In these cases I tried to excise the reference from the EIP as best I could. It is worth noting that the Readme actually already had this rule, it just wasn't expressed properly in EIP-1 and the "Citation Format" section of the readme I think caused people a bit of confusion (when citing externally, you should use the citation format).
3.0 KiB
| eip | title | author | discussions-to | type | category | status | created | requires |
|---|---|---|---|---|---|---|---|---|
| 695 | Create `eth_chainId` method for JSON-RPC | Isaac Ardis <isaac.ardis@gmail.com>, Wei Tang (@sorpaas), Fan Torchz (@tcz001), Erik Marks (@rekmarks) | https://ethereum-magicians.org/t/eip-695-create-eth-chainid-method-for-json-rpc/1845 | Standards Track | Interface | Final | 2017-08-21 | 155 |
Simple Summary
Include eth_chainId method in eth_-namespaced JSON-RPC methods.
Abstract
The eth_chainId method should return a single STRING result
for an integer value in hexadecimal format, describing the
currently configured CHAIN_ID value used for signing replay-protected transactions,
introduced by EIP-155.
Motivation
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.
Specification
eth_chainId
Returns the currently configured chain ID, a value used in replay-protected transaction signing as introduced by EIP-155.
The chain ID returned should always correspond to the information in the current known head block. This ensures that caller of this RPC method can always use the retrieved information to sign transactions built on top of the head.
If the current known head block does not specify a chain ID, the client should treat any
calls to eth_chainId as though the method were not supported, and return a suitable
error.
Parameters
None.
Returns
QUANTITY - integer of the current chain ID.
Example
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
// Result
{
"id": 83,
"jsonrpc": "2.0",
"result": "0x3d" // 61
}
Rationale
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.
Backwards Compatibility
Not relevant.
Security Considerations
Consumers should prefer eth_chainId over net_version, so that they can reliably identify chain they are communicating with.
Implementers should take care to implement eth_chainId correctly and promote its use, since the chain ID is critical in replay attack prevention as described in EIP-155, and consumers will rely on it to identify the chain they are communicating with.
Implementation
Reference
Return value QUANTITY adheres to standard JSON RPC hex value encoding, as documented in the Ethereum Wiki.
Copyright
Copyright and related rights waived via CC0.