Look, I agree that this will make things a little trickier than before. However, there will still be ways to perform the immutability check without looking at the history:
- Ensure that no
selfdestruct,delegatecallorcallcodeopcodes appear in the contract, - If there are
delegatecallorcallcodeopcodes, ensure that it’s not possible to somehow reach aselfdestructopcode, - Enforce that the contract has been created by some trusted source (such as an established
CREATE2factory contract that maintains a mapping of deployed contract addresses and will not allow a contract to be redeployed) via arequirestatement in the constructor or some other means.
The need for upgradeable contracts has been well-established at this point, and many of the most high-impact issues in Ethereum’s history thus far could have been mitigated with adequate upgradeability mechanisms in place. Obviously it’s not a paradigm that should be forced onto everyone, but if there are ways to implement it more efficiently, it will greatly benefit those that do need it. Both the proxy pattern and ENS resolution result in increased overhead vs. a direct equivalent, but an optimal upgradeable contract would operate on par with a standard contract from an efficiency standpoint. This could be a way to achieve that aim, assuming the corresponding risks can be properly addressed.