Skip to content

Method to check if a chainID is valid at a specific block Number #1965

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

Merged
merged 8 commits into from
May 19, 2019
Merged

Method to check if a chainID is valid at a specific block Number #1965

Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
8de9d32
Merge pull request #2 from ethereum/master
wighawag Feb 25, 2019
45ef215
Merge pull request #3 from ethereum/master
wighawag Apr 9, 2019
f1de490
EIP-1965
wighawag Apr 24, 2019
fa11e8d
discussion link
wighawag Apr 24, 2019
8de9d1d
make it a precompile
wighawag Apr 28, 2019
f15f340
remove opcode from title
wighawag May 9, 2019
0f1303f
fixes
wighawag May 9, 2019
26c9940
fix EIP-1344 link
wighawag May 17, 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
Prev Previous commit
Next Next commit
make it a precompile
  • Loading branch information
@wighawag
wighawag committed Apr 28, 2019
commit 8de9d1df273fbbb5c9cf857c60ba3d0449a78c07
8 changes: 4 additions & 4 deletions EIPS/eip-1965.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ created: 2019-04-20
---

## Abstract
This EIP adds an opcode that returns whether a specific chainID (EIP-155 unique identifier) is valid at a specific blockNumber. ChainID are assumed to be valid up to the blockNumber at which they get replaced by a new chainID.
This EIP adds an precompile that returns whether a specific chainID (EIP-155 unique identifier) is valid at a specific blockNumber. ChainID are assumed to be valid up to the blockNumber at which they get replaced by a new chainID.

## 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).
Expand All @@ -20,17 +20,17 @@ This EIP adds an opcode that returns whether a specific chainID (EIP-155 unique
[EIP-1959](https://github.com/ethereum/EIPs/pull/1959) solves the issue of EIP-1344 but do not attempt to protect from minority-led hardfork as mentioned in the rationale. We consider this a mistake, since it remove some freedom to fork. We consider that all fork should be given equal oportunities. And while there will always be issues we can't solve for the majority that ignore a particular fork, **users that decide to use both the minority-fork and the majority-chain should be protected from replay without having to wait for the majority chain to update its chainID.**

## Specification
Adds a new opcode ```VALID_CHAINID``` at 0x46, which uses 2 stack argument : a uint256 value that represent the chainID to test and a uint256 value representing the blockNumber at which the chainID is tested. It will push ```true``` onto the stack if the chainID is valid at the specific blockNumber, ```false``` otherwise. Note that chainID are considered valid up to the blockNumber at which they are replaced. So they are valid for every blockNumber past their replacement.
Adds a new precompile which uses 2 argument : a uint256 value that represent the chainID to test and a uint256 value representing the blockNumber at which the chainID is tested. It return ```true``` if the chainID is valid at the specific blockNumber, ```false``` otherwise. Note that chainID are considered valid up to the blockNumber at which they are replaced. So they are valid for every blockNumber past their replacement.

The operation costs `G_blockhash` to execute.
The operation costs `G_blockhash` + `G_verylow` to execute.

The cost of the operation might need to be adjusted later as the number of chainID in the history of the chain grows.

## Rationale

The rationale at EIP-1959 applies here as well too :

- An opcode is better than a caching system for past chainID, it is safer and do not include gaps.
- An opcode is better than a caching system for past chainID, It is cheaper, safer and do not include gaps.
- Direct access to the latest chainID is dangerous since it make it easy for contract to use it as a replay protection mechanism while preventing otherwise valid old messages to be valid after a fork that change the chainID. This can have disastrous consequences on users.
- all off-chain messaged signed before a fork should be valid across all side of the fork.

Expand Down