From 9c69c82c9a88b28ea0398dd5f40267f0b1bd68f7 Mon Sep 17 00:00:00 2001 From: Wighawag Date: Wed, 24 Apr 2019 10:48:35 +0100 Subject: [PATCH 1/6] EIP-1959 --- EIPS/eip-1959.md | 70 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 EIPS/eip-1959.md diff --git a/EIPS/eip-1959.md b/EIPS/eip-1959.md new file mode 100644 index 00000000000000..7b018c1ca8a73e --- /dev/null +++ b/EIPS/eip-1959.md @@ -0,0 +1,70 @@ +--- +eip: 1959 +title: Valid ChainID opcode +author: Ronan Sandford (@wighawag) +category: Core +type: Standards Track +discussions-to: https://ethereum-magicians.org/t/eip-1959-valid-chainid-opcode/3170 +status: Draft +created: 2019-04-20 +--- + +## Abstract +This EIP adds an opcode that returns whether the specific number passed in has been a valid chainID (EIP-155 unique identifier) in the history of the chain (including the current 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). + +[EIP-1344](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1344.md) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insuficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work arround the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. + +## Specification +Adds a new opcode ```VALID_CHAINID``` at 0x46, which uses 1 stack argument : a uint256 value that represent the chainID to test. It will push ```true``` onto the stack if the uint256 value is part of the history of chainIDs of that chain, ```false``` otherwise. + +The operation costs `G_blockhash` 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 current approach proposed by EIP-712 is to specify the chain ID at compile time. Using this approach will result in problems after a contentious hardfork as the contract can't accept message signed with a new chainID. + +The approach proposed by EIP-1344 is to give access to the latest chainID. This is in itself not sufficient and pose the oposite of the problem mentioned above since as soon as a hardfork that change the chainID happens, every L2 messages signed as per EIP712 (with the previous chainID) will fails to be accepted by the contracts after the fork. + +That's why in the rationale of EIP-1344 it is mentioned that users need to implement/use a mechanism to verify the validity of past chainID via a trustless cache. + +> 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. + + +While this works (except for a temporary gap where the immediatly previous chainID is not considered valid), this is actually a required procedure for all contracts that want to accept L2 messages since without it, messages signed before an hardfork that updated the chainID would be rejected. In other words, EIP-1344 expose such risk and it is easy for contract to not consider it by simply checking ```chainID == CHAIN_ID()``` without considering past chainIDs. + +Indeed letting contracts access the latest chainID for L2 message verification is dangerous. The latest chainID is only the tip of the chainID history. As a changing value, the latest chainID is thus not appropriate to ensure the validity of L2 messages. + +Users signing off-chain messages expect their messages to be valid from the time of signing and do not expect these message to be affected by a future hardfork. If the contract use the latest chainID as is for verification, the messages would be invalid as soon as a hardfork that update the chainID happens. For some applications, this will require users to resubmit a new message (think meta transaction), causing them potential loss (or some incovenience during the hardfork transition), but for some other applications (think state channel) the whole off-chain state become innaccessible, resulting in potentially disastrous situations. + +In other words, we should consider all off-chain messages (with valid chainID) as part of the chain's offchain state. The opcode proposed here, offer smart contracts a simple and safe method to ensure that the offchain state stay valid across fork. + +As for replay protection, the idea of considering all of the off-chain messages signed with valid chainID as part of the chain's offchain-state means that all of these off-chain messages can be reused on the different forks which share a common chainID history (up to where they differ). This is actually an important feature since as mentioned, users expect their signed messages to be valid from the time of signing. From that time onwards these messages should be considered as part of the chain's offchain state. A hardfork should not thus render them invalid. This is similar to how the previous on-chain state is shared between 2 hardforks. + +The wallets will make sure that at any time, a signing message request use the latest chainID of the chain being used. This prevent replay attack onto chain that have different chainID histories (they would not have the same latest chainID). + +Now it is argued in the [EIP1344 discussion](https://ethereum-magicians.org/t/eip-1344-add-chain-id-opcode/1131) that when a contentious hardfork happen and one side of the fork decide to not update its chainID, that side of the chain would be vulnerable to replays since users will keep signing with a chainID that is also valid in the chain that forked. An issue also present in EIP-1344. + +This is simply a natural consequence of using chainID as the only anti-replay information for L2 messages. But this can indeed be an issue if the hardfork is created by a small minority. In that case if the majority ignore the fork and do not update its chainID, then all new message from the majority chain (until they update their chainID) can be replayed on the minority-led hardfork since the majority's current chainID is also part of the minority-led fork's chainID history. + +To fix this, every message could specify the block number representing the time it was signed. The contract could then verify that chainID specified as part of that message was valid at that particular block. + + +While EIP-1344 can't do that accurately as the caching system might leave a gap, this proposal can solve it if it is modified to return the blockNumber at which a chainID become invalid. Unfortunately, this would be easy for contracts to not perform that check. And since it suffice of only one important applications to not follow this procedure to put the minority-led fork at a disadvantage, this would fail to achieve the desired goal of protecting the minority-led fork from replay. + +Since a minority-led fork ignored by the majority means that the majority will not keep track of the messages to be submitted (state channel, ...), if such fork get traction later, this would be at the expense of majority users who were not aware of it. As such this proposal assume that minority-led fork will not get traction later and thus do not require to be protected. + + +## Backwards Compatibility +This EIP is fully backwards compatible with all chains which implement EIP-155 chain ID domain separator for transaction signing. + +Similary to EIP-1344, it might be beneficial to update EIP-712 (still in Draft) to deal with chainID separatly from the domain separator. Indeed since chainID is expected to change, if the domain separator include chainID, it would have to be dynamically computed. A caching mechanism could be used by smart contract instead though. + +## References +This was previously suggested as part of [EIP1344 discussion](https://ethereum-magicians.org/t/eip-1344-add-chain-id-opcode/1131/39). + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). \ No newline at end of file From 07f2e49a8a840f2c6b2a51c12c79cefa385200fd Mon Sep 17 00:00:00 2001 From: Wighawag Date: Thu, 9 May 2019 18:55:39 +0100 Subject: [PATCH 2/6] fixes --- EIPS/eip-1959.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/EIPS/eip-1959.md b/EIPS/eip-1959.md index 7b018c1ca8a73e..8d0f6065f8531f 100644 --- a/EIPS/eip-1959.md +++ b/EIPS/eip-1959.md @@ -1,38 +1,38 @@ --- eip: 1959 -title: Valid ChainID opcode +title: Method to check if a chainID is part of the history of chainIDs author: Ronan Sandford (@wighawag) category: Core type: Standards Track discussions-to: https://ethereum-magicians.org/t/eip-1959-valid-chainid-opcode/3170 status: Draft created: 2019-04-20 +requires: 155 --- ## Abstract This EIP adds an opcode that returns whether the specific number passed in has been a valid chainID (EIP-155 unique identifier) in the history of the chain (including the current 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). +[EIP-155](http://eips.ethereum.org/EIPS/eip-155) 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](http://eips.ethereum.org/EIPS/eip-712). -[EIP-1344](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1344.md) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insuficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work arround the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. +[EIP-1344](http://eips.ethereum.org/EIPS/eip-1344) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insuficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. ## Specification -Adds a new opcode ```VALID_CHAINID``` at 0x46, which uses 1 stack argument : a uint256 value that represent the chainID to test. It will push ```true``` onto the stack if the uint256 value is part of the history of chainIDs of that chain, ```false``` otherwise. +Adds a new opcode ```VALID_CHAINID``` at 0x46, which uses 1 stack argument : a 32 bytes value that represent the chainID to test. It will push ```0x1``` onto the stack if the uint256 value is part of the history of chainIDs of that chain, ```0x0``` otherwise. The operation costs `G_blockhash` 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. +Note though that the alternative to keep track of old chainID is to implement a smart contract based caching solution as EIP-1344 proposes comes with an overall higher gas cost. As such the gas cost is simply a necessary cost for the feature. + ## 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 contentious hardfork as the contract can't accept message signed with a new chainID. +The only approach available today is to specify the chain ID at compile time. Using this approach will result in problems after a contentious hardfork as the contract can't accept message signed with a new chainID. The approach proposed by EIP-1344 is to give access to the latest chainID. This is in itself not sufficient and pose the oposite of the problem mentioned above since as soon as a hardfork that change the chainID happens, every L2 messages signed as per EIP712 (with the previous chainID) will fails to be accepted by the contracts after the fork. -That's why in the rationale of EIP-1344 it is mentioned that users need to implement/use a mechanism to verify the validity of past chainID via a trustless cache. - -> 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. - +That's why in the rationale of EIP-1344 it is mentioned that users need to implement/use a mechanism to verify the validity of past chainID via a trustless cache implemented via smart contract. While this works (except for a temporary gap where the immediatly previous chainID is not considered valid), this is actually a required procedure for all contracts that want to accept L2 messages since without it, messages signed before an hardfork that updated the chainID would be rejected. In other words, EIP-1344 expose such risk and it is easy for contract to not consider it by simply checking ```chainID == CHAIN_ID()``` without considering past chainIDs. From 5bc39a634af6e1bd4715cfe4ee4fffffb19d30c0 Mon Sep 17 00:00:00 2001 From: Wighawag Date: Mon, 20 May 2019 19:40:36 +0100 Subject: [PATCH 3/6] tweaks --- EIPS/eip-1959.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-1959.md b/EIPS/eip-1959.md index 8d0f6065f8531f..67ef02d76bccb4 100644 --- a/EIPS/eip-1959.md +++ b/EIPS/eip-1959.md @@ -19,7 +19,7 @@ This EIP adds an opcode that returns whether the specific number passed in has b [EIP-1344](http://eips.ethereum.org/EIPS/eip-1344) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insuficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. ## Specification -Adds a new opcode ```VALID_CHAINID``` at 0x46, which uses 1 stack argument : a 32 bytes value that represent the chainID to test. It will push ```0x1``` onto the stack if the uint256 value is part of the history of chainIDs of that chain, ```0x0``` otherwise. +Adds a new opcode ```VALID_CHAINID``` at 0x46, which uses 1 stack argument : a 32 bytes value that represent the chainID to test. It will push ```0x1``` onto the stack if the uint256 value is part of the history (since genesis) of chainIDs of that chain, ```0x0``` otherwise. The operation costs `G_blockhash` to execute. @@ -30,7 +30,7 @@ Note though that the alternative to keep track of old chainID is to implement a ## Rationale The only approach available today is to specify the chain ID at compile time. Using this approach will result in problems after a contentious hardfork as the contract can't accept message signed with a new chainID. -The approach proposed by EIP-1344 is to give access to the latest chainID. This is in itself not sufficient and pose the oposite of the problem mentioned above since as soon as a hardfork that change the chainID happens, every L2 messages signed as per EIP712 (with the previous chainID) will fails to be accepted by the contracts after the fork. +The approach proposed by EIP-1344 is to give access to the latest chainID. This is in itself not sufficient and pose the oposite of the problem mentioned above since as soon as a hardfork that change the chainID happens, every L2 messages signed as per EIP-712 (with the previous chainID) will fails to be accepted by the contracts after the fork. That's why in the rationale of EIP-1344 it is mentioned that users need to implement/use a mechanism to verify the validity of past chainID via a trustless cache implemented via smart contract. @@ -59,7 +59,7 @@ Since a minority-led fork ignored by the majority means that the majority will n ## Backwards Compatibility -This EIP is fully backwards compatible with all chains which implement EIP-155 chain ID domain separator for transaction signing. +This EIP is fully backwards compatible with all chains which implement EIP-155 chain ID domain separator for transaction signing. Existing contract are not affected. Similary to EIP-1344, it might be beneficial to update EIP-712 (still in Draft) to deal with chainID separatly from the domain separator. Indeed since chainID is expected to change, if the domain separator include chainID, it would have to be dynamically computed. A caching mechanism could be used by smart contract instead though. From c744e82f427e5b5a9c0f7f3e52aba970d3c3b07d Mon Sep 17 00:00:00 2001 From: Wighawag Date: Wed, 22 May 2019 12:34:03 +0100 Subject: [PATCH 4/6] tweaks --- EIPS/eip-1959.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/EIPS/eip-1959.md b/EIPS/eip-1959.md index 67ef02d76bccb4..a8d4601cd45393 100644 --- a/EIPS/eip-1959.md +++ b/EIPS/eip-1959.md @@ -10,6 +10,10 @@ created: 2019-04-20 requires: 155 --- + +## Simple Summary +To protect off-chain messages from being reused across different chain, a mechanism need to be given to smart contract to only accept messages for that chain. Since a chain can change its chainID, the mechanism should consider old chainID valid. + ## Abstract This EIP adds an opcode that returns whether the specific number passed in has been a valid chainID (EIP-155 unique identifier) in the history of the chain (including the current chainID). @@ -57,6 +61,11 @@ While EIP-1344 can't do that accurately as the caching system might leave a gap, Since a minority-led fork ignored by the majority means that the majority will not keep track of the messages to be submitted (state channel, ...), if such fork get traction later, this would be at the expense of majority users who were not aware of it. As such this proposal assume that minority-led fork will not get traction later and thus do not require to be protected. +## Test Cases +TBD + +## Implementation +TBD ## Backwards Compatibility This EIP is fully backwards compatible with all chains which implement EIP-155 chain ID domain separator for transaction signing. Existing contract are not affected. From 1afab7b12e692933771af97e9f24d883ae469489 Mon Sep 17 00:00:00 2001 From: Wighawag Date: Wed, 22 May 2019 12:38:23 +0100 Subject: [PATCH 5/6] spell-check --- EIPS/eip-1959.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-1959.md b/EIPS/eip-1959.md index a8d4601cd45393..41c90b4d402f4d 100644 --- a/EIPS/eip-1959.md +++ b/EIPS/eip-1959.md @@ -20,7 +20,7 @@ This EIP adds an opcode that returns whether the specific number passed in has b ## Motivation [EIP-155](http://eips.ethereum.org/EIPS/eip-155) 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](http://eips.ethereum.org/EIPS/eip-712). -[EIP-1344](http://eips.ethereum.org/EIPS/eip-1344) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insuficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. +[EIP-1344](http://eips.ethereum.org/EIPS/eip-1344) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insufficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. ## Specification Adds a new opcode ```VALID_CHAINID``` at 0x46, which uses 1 stack argument : a 32 bytes value that represent the chainID to test. It will push ```0x1``` onto the stack if the uint256 value is part of the history (since genesis) of chainIDs of that chain, ```0x0``` otherwise. @@ -34,15 +34,15 @@ Note though that the alternative to keep track of old chainID is to implement a ## Rationale The only approach available today is to specify the chain ID at compile time. Using this approach will result in problems after a contentious hardfork as the contract can't accept message signed with a new chainID. -The approach proposed by EIP-1344 is to give access to the latest chainID. This is in itself not sufficient and pose the oposite of the problem mentioned above since as soon as a hardfork that change the chainID happens, every L2 messages signed as per EIP-712 (with the previous chainID) will fails to be accepted by the contracts after the fork. +The approach proposed by EIP-1344 is to give access to the latest chainID. This is in itself not sufficient and pose the opposite of the problem mentioned above since as soon as a hardfork that change the chainID happens, every L2 messages signed as per EIP-712 (with the previous chainID) will fails to be accepted by the contracts after the fork. That's why in the rationale of EIP-1344 it is mentioned that users need to implement/use a mechanism to verify the validity of past chainID via a trustless cache implemented via smart contract. -While this works (except for a temporary gap where the immediatly previous chainID is not considered valid), this is actually a required procedure for all contracts that want to accept L2 messages since without it, messages signed before an hardfork that updated the chainID would be rejected. In other words, EIP-1344 expose such risk and it is easy for contract to not consider it by simply checking ```chainID == CHAIN_ID()``` without considering past chainIDs. +While this works (except for a temporary gap where the immediately previous chainID is not considered valid), this is actually a required procedure for all contracts that want to accept L2 messages since without it, messages signed before an hardfork that updated the chainID would be rejected. In other words, EIP-1344 expose such risk and it is easy for contract to not consider it by simply checking ```chainID == CHAIN_ID()``` without considering past chainIDs. Indeed letting contracts access the latest chainID for L2 message verification is dangerous. The latest chainID is only the tip of the chainID history. As a changing value, the latest chainID is thus not appropriate to ensure the validity of L2 messages. -Users signing off-chain messages expect their messages to be valid from the time of signing and do not expect these message to be affected by a future hardfork. If the contract use the latest chainID as is for verification, the messages would be invalid as soon as a hardfork that update the chainID happens. For some applications, this will require users to resubmit a new message (think meta transaction), causing them potential loss (or some incovenience during the hardfork transition), but for some other applications (think state channel) the whole off-chain state become innaccessible, resulting in potentially disastrous situations. +Users signing off-chain messages expect their messages to be valid from the time of signing and do not expect these message to be affected by a future hardfork. If the contract use the latest chainID as is for verification, the messages would be invalid as soon as a hardfork that update the chainID happens. For some applications, this will require users to resubmit a new message (think meta transaction), causing them potential loss (or some inconvenience during the hardfork transition), but for some other applications (think state channel) the whole off-chain state become inaccessible, resulting in potentially disastrous situations. In other words, we should consider all off-chain messages (with valid chainID) as part of the chain's offchain state. The opcode proposed here, offer smart contracts a simple and safe method to ensure that the offchain state stay valid across fork. @@ -70,10 +70,10 @@ TBD ## Backwards Compatibility This EIP is fully backwards compatible with all chains which implement EIP-155 chain ID domain separator for transaction signing. Existing contract are not affected. -Similary to EIP-1344, it might be beneficial to update EIP-712 (still in Draft) to deal with chainID separatly from the domain separator. Indeed since chainID is expected to change, if the domain separator include chainID, it would have to be dynamically computed. A caching mechanism could be used by smart contract instead though. +Similarly to EIP-1344, it might be beneficial to update EIP-712 (still in Draft) to deal with chainID separately from the domain separator. Indeed since chainID is expected to change, if the domain separator include chainID, it would have to be dynamically computed. A caching mechanism could be used by smart contract instead though. ## References -This was previously suggested as part of [EIP1344 discussion](https://ethereum-magicians.org/t/eip-1344-add-chain-id-opcode/1131/39). +This was previously suggested as part of [EIP-1344 discussion](https://ethereum-magicians.org/t/eip-1344-add-chain-id-opcode/1131/39). ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). \ No newline at end of file From c6c4e2b9c46f782a5a3448ee29ccb91e1ae7c234 Mon Sep 17 00:00:00 2001 From: Wighawag Date: Fri, 24 May 2019 00:23:53 +0200 Subject: [PATCH 6/6] tweaks --- EIPS/eip-1959.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-1959.md b/EIPS/eip-1959.md index 41c90b4d402f4d..40af70b401ca76 100644 --- a/EIPS/eip-1959.md +++ b/EIPS/eip-1959.md @@ -1,6 +1,6 @@ --- eip: 1959 -title: Method to check if a chainID is part of the history of chainIDs +title: New Opcode to check if a chainID is part of the history of chainIDs author: Ronan Sandford (@wighawag) category: Core type: Standards Track @@ -18,9 +18,9 @@ To protect off-chain messages from being reused across different chain, a mechan This EIP adds an opcode that returns whether the specific number passed in has been a valid chainID (EIP-155 unique identifier) in the history of the chain (including the current chainID). ## Motivation -[EIP-155](http://eips.ethereum.org/EIPS/eip-155) 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](http://eips.ethereum.org/EIPS/eip-712). +[EIP-155](https://eips.ethereum.org/EIPS/eip-155) 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://eips.ethereum.org/EIPS/eip-712). -[EIP-1344](http://eips.ethereum.org/EIPS/eip-1344) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insufficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. +[EIP-1344](https://eips.ethereum.org/EIPS/eip-1344) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insufficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. ## Specification Adds a new opcode ```VALID_CHAINID``` at 0x46, which uses 1 stack argument : a 32 bytes value that represent the chainID to test. It will push ```0x1``` onto the stack if the uint256 value is part of the history (since genesis) of chainIDs of that chain, ```0x0``` otherwise. @@ -34,7 +34,7 @@ Note though that the alternative to keep track of old chainID is to implement a ## Rationale The only approach available today is to specify the chain ID at compile time. Using this approach will result in problems after a contentious hardfork as the contract can't accept message signed with a new chainID. -The approach proposed by EIP-1344 is to give access to the latest chainID. This is in itself not sufficient and pose the opposite of the problem mentioned above since as soon as a hardfork that change the chainID happens, every L2 messages signed as per EIP-712 (with the previous chainID) will fails to be accepted by the contracts after the fork. +The approach proposed by EIP-1344 is to give access to the latest chainID. This is in itself not sufficient and pose the opposite of the problem mentioned above since as soon as a hardfork that change the chainID happens, every L2 messages signed as per [EIP-712](https://eips.ethereum.org/EIPS/eip-712) (with the previous chainID) will fails to be accepted by the contracts after the fork. That's why in the rationale of EIP-1344 it is mentioned that users need to implement/use a mechanism to verify the validity of past chainID via a trustless cache implemented via smart contract.