mirror of https://github.com/status-im/EIPs.git
44 lines
3.6 KiB
Markdown
44 lines
3.6 KiB
Markdown
---
|
|
eip: 1344
|
|
title: ChainID opcode
|
|
author: Richard Meissner (@rmeissner), Bryant Eisenbach (@fubuloubu)
|
|
discussions-to: https://ethereum-magicians.org/t/add-chain-id-opcode-for-replay-protection-when-handling-signed-messages-in-contracts/1131
|
|
category: Core
|
|
type: Standards Track
|
|
status: Last Call
|
|
created: 2018-08-22
|
|
review-period-end: 2019-04-30
|
|
---
|
|
|
|
## Abstract
|
|
This EIP adds an opcode that returns the current chain's EIP-155 unique identifier.
|
|
|
|
## Motivation
|
|
[EIP-155](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md) proposes to use the chain ID to prevent replay attacks between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling signatures, especially for Layer 2 signature schemes using [EIP-712](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md).
|
|
|
|
## Specification
|
|
Adds a new opcode `CHAINID` at 0x46, which uses 0 stack arguments. It pushes the current chain ID onto the stack. The operation costs `G_base` to execute.
|
|
|
|
## Rationale
|
|
The current approach proposed by EIP-712 is to specify the chain ID at compile time. Using this approach will result in problems after a hardfork, as well as human error that may lead to loss of funds or replay attacks on signed messages.
|
|
By adding the proposed opcode it will be possible to access the current chain ID and validate signatures based on that.
|
|
|
|
Currently, there is no specification for how chain ID is set for a particular network, relying on choices made manually by the client implementers and the chain community. There is a potential scenario where, during a "contentious split" over a divisive issue, a community using a particular value of chain ID will make a decision to split into two such chains. When this scenario occurs, it will be unsafe to maintain chain ID to the same value on both chains, as chain ID is used for replay protection for in-protocol transactions (per EIP-155), as well as for L2 and "meta-transaction" use cases (per EIP-712 as enabled by this proposal). There are two potential resolutions in this scenario under the current process: 1) one chain decides to modify their value of chain ID (while the other keeps it), or 2) both chains decide to modify their value of chain ID.
|
|
|
|
In order to mitigate this situation, users of the proposed `CHAINID` opcode **must** ensure that their application can handle a potential update to the value of chain ID during their usage of their application in case this does occur, if required for the continued use of the application. A Trustless Oracle that logs the timestamp when a change is made to chain ID can be implemented either as an application-level feature inside the application contract system, or referenced as a globally standard contract. Failure to provide a mitigation for this scenario could lead to a sudden loss of legitimacy of previously signed off-chain messages, which could be an issue during settlement periods and other longer-term verification events for these types of messages. Not all applications of this opcode may need mitigations to handle this scenario, but developers should provide reasoning on a case-by-case basis.
|
|
|
|
## Backwards Compatibility
|
|
This EIP is fully backwards compatible with all chains which implement EIP-155 chain ID domain separator for transaction signing.
|
|
|
|
## References
|
|
This was previously suggested as part of [EIP901](https://github.com/ethereum/EIPs/issues/901).
|
|
|
|
## Test Cases
|
|
TBD
|
|
|
|
## Implementation
|
|
A sample implementation was attempted here: https://github.com/fubuloubu/py-evm/commit/eaab5ffa2164d4cc06ae5c855a49d030965be828
|
|
|
|
## Copyright
|
|
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|