This is an interesting proposal, thank you.
So, I’m not sure about this as a requirement, but let’s explore.
Assume a truly contentious fork occurs, and chainId
is eventually resolved such that the fork of lesser community size is socially coerced to adopt a different value (if they refuse, this proposal does not add value). Also assume that a subset of applications that rely on the value of chainId
either prefer the minority chain, or wish to continue supporting both chains in the fork.
Therefore, messages signed on the majority chain only require the domain separator for the old chainId
, which has the hash 0x1234
. The minority chain must accept the old hash 0x1234
, or the domain separator includes the new value for chainId
, which has the hash 0xABCD
.
On the minority chain, both should be accepted, although to be strictly accurate we should ensure that only those messages signed after the fork date use the domain separator hash 0xABCD
or else we can replay a user’s signed messages from after the change on the majority fork. So, we need to delegate to an oracle to ensure that we have proper ordering of time for these signed messages, or we risk the above happening (another opcode would be too complex to specify).
I think all in all, this is too improbable a scenario to try and design some explicit mechanism to handle. I think the added friction of this scenario occuring would ensure that the minority chain has little support from the builders of these applications, because users will have to jump through some hoops to get their old signed messages processed in the case of a contentious split like that described above.
The only alternative I can think of where this is not true is the one where the Ethereum Foundation, who has registered the trademark, is the supporter of the minority chain, meaning they forced a split that community does not find to be legitimate. However, the trademark has nothing to do with the value of chainId
and I would think the majority fork community would not prefer to modify their value if a hostile fork occurs, and instead try to socially coerce the minority chain (in this scenario, run by the EF and very few other parties) to change theirs because the community does not recognize the minority chain as legitimate.
This is way down in the weeds, I hope you’ll agree. 99% of the use case for this opcode is for replay protection of testnet transactions.