I’d like here to bring my objection to EIP-1344 being included in the Istanbul hard-fork. The concerns behind the objections have already be mentioned on the EIP-1344 discussion thread but since this EIP is being finalized and discussion on each EIP are meant to be about technical soundness, the best place to raise my concerns seemed to be here in this discussion thread.
My concerns are as follow :
-
EIP-1344 opcode can be easily misused as can be shown in the discussion thread and explained partially in the rationale of EIP-1344.
Simply doing an equality check is indeed not enough since after a contentious hard fork (that change the chainID), messages signed before hand (with an older chainID) will fail to be valid, breaking signer’s expectation. EIP-1344 rationale propose thus a contract based caching solution to remedy the problem. -
EIP-1344 requires thus a contract based solution to be used properly in most use-case. This is due to the design of the solution EIP-1344 proposes (namely only letting access the tip of the chainID history). This increase complexity and gas cost for no benefit.
-
In case of minority-led hardfork as described here in details, the contract based caching is insufficient as there will be a gap where a message signed with a past chainID will not be protected from replay.
Note that while I agree with the importance to have a replay protection mechanism for off-chain messages included in the next hardfork, it should not be EIP-1344.
All the concerns mentioned above are non-existent with EIP-1965 which achieve full replay protection without requiring added complexity from the users.
EIP-1965 should be thus chosen for off-chain message replay-protection instead of EIP-1344 in the next hardfork.
Why not have both ? Because EIP-1344 has no useful purpose of its own if EIP-1965 was included.
As PR 1965 is not merged in yet though, I can’t add it to proposed list yet. If anyone reading here could help on that, that would be great. Thanks