Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

EIP-1344: Update uint256 field size to uint64 #2263

Closed
wants to merge 2 commits into from
Closed

EIP-1344: Update uint256 field size to uint64 #2263

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4114ba5
EIP-1344: Update uint256 field size to uint64
fubuloubu Sep 6, 2019
1a8973a
EIP-1344: Typo
fubuloubu Sep 7, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion EIPS/eip-1344.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,10 +17,12 @@ This EIP adds an opcode that returns the current chain's EIP-155 unique identifi
[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. Chain ID is a 256-bit value. The operation costs `G_base` to execute.
Adds a new opcode `CHAINID` at 0x46, which uses 0 stack arguments. It pushes the current chain ID onto the stack. Chain ID is a 64-bit value. The operation costs `G_base` to execute.

The value of the current chain ID is obtained from the chain ID configuration, which should match the EIP-155 unique identifier a client will accept from incoming transactions. Please note that per EIP-155, it is not *required* that a transaction have an EIP-155 unique identifier, but in that scenario this opcode will still return the configured chain ID and not a default.

**NOTE**: A 64-bit value was chosen as a reasonably-sized value that works with the EIP-155 formatting for the `v` field (where `v = CHAIN_ID * 2 + 36`). The max value that can be used for chain ID is `MAX_CHAIN_ID = MAX_UNIT256 / 2 - 36` in order to have the math fit inside the RLP encoding for the `v` field in a transaction (as is currently expected by all production RLP encoders).
fubuloubu marked this conversation as resolved.
Show resolved Hide resolved

## 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.
Expand Down