mirror of
https://github.com/status-im/EIPs.git
synced 2025-02-24 12:48:20 +00:00
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).
98 lines
3.0 KiB
Markdown
98 lines
3.0 KiB
Markdown
---
|
|
eip: 695
|
|
title: Create `eth_chainId` method for JSON-RPC
|
|
author: Isaac Ardis <isaac.ardis@gmail.com>, Wei Tang (@sorpaas), Fan Torchz (@tcz001), Erik Marks (@rekmarks)
|
|
discussions-to: https://ethereum-magicians.org/t/eip-695-create-eth-chainid-method-for-json-rpc/1845
|
|
type: Standards Track
|
|
category: Interface
|
|
status: Final
|
|
created: 2017-08-21
|
|
requires: 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](./eip-155.md).
|
|
|
|
## 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](./eip-155.md).
|
|
|
|
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
|
|
|
|
```js
|
|
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](./eip-155.md), and consumers will rely on it to identify the chain they are communicating with.
|
|
|
|
## Implementation
|
|
|
|
- [Parity PR](https://github.com/paritytech/parity/pull/6329)
|
|
- [Geth PR](https://github.com/ethereum/go-ethereum/pull/17617)
|
|
- [Geth Classic PR](https://github.com/ethereumproject/go-ethereum/pull/336)
|
|
|
|
## Reference
|
|
|
|
Return value `QUANTITY` adheres to standard JSON RPC hex value encoding, as documented in the [Ethereum Wiki](https://github.com/ethereum/wiki/wiki/JSON-RPC#hex-value-encoding).
|
|
|
|
## Copyright
|
|
|
|
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|