Hi, I reviewed the current rationale and from the discussion we had here and on EIP-1959, I think you should update to mention the following points :
- the fact that contract can naively check chainID == message’s chainID makes the opcode potentially dangerous to use
- It already mention the need for a caching system but it would be good to indicate that alternative solution do not need it
- It also does not mention the minority-led hardfork situation (as described here) . In particular:
- with such caching system, it is actually not possible to properly protect from replay in case of a minority-led hardfork since the caching system will not accurately save the blockNumber at which the chainID became the latest. As such during the gap, messages signed with a blockNumber present in that gap, from the majority chain will be replayable on the minority chain even though they should not
- Even then, it does not mention the minority-led fork situation where the messages will need to include the blockNumber representing the time it was signed so that the contract can prevent it from being used across such forks
- And it also does not mention that it suffice only one important application to not protect using blockNumber for the minority-led fork to be at a disadvantage as such application will suffer from replay in that fork.
- I would also mention as I did in EIP1959, the potential benefit in separating chainID from the domain separator since the chainID will change (but as mentioned a domain separator caching mechanism could work too)