forked from DecentralizedClimateFoundation/DCIPs
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":83}'
|
||
|
|
|
||
|
|
// 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](../LICENSE.md).
|