PaulRBerg
Problem caused by deterministic deployments when modifying only PRBProxyRegistry
Description
If we already have a set of contracts deployed to a chain, and we modify only the PRBProxyRegistry contract, we run into trouble. The PRBProxy and PRBProxyFactory contracts cannot be redeployed at other addresses, due to how the deterministic deployment proxy works.
Imagine we pass a salt, say 0x01, to the deployFor function in PRBProxyRegistry v1.0.0. The contract creation will go through. Now we upgrade the registry to a v1.0.1, which is pointed to the same PRBProxyFactory contract.
If we pass the same 0x01 salt to the v1.0.1 contract, the contract creation will revert. The clone function will revert with a PRBProxyFactory__CloneFailed custom error, because the address of the factory contract is the same and the salt is the same.
The good news is that this won't likely affect any production errors. We don't expect to make frequent upgrades (if any) after we ship to Ethereum Mainnet, Polygon, etc.
Possible Solution
I can't think of anything better than forcefully making a change to PRBProxy or PRBProxyFactory as well, such that the factory starts afresh too when the registry is upgraded.
This is not great, but the change can be minor enough so that it is redundant. E.g. a change in the NatSpec comments, or a slight tweak of the number of times the compiler optimizer runs.
Link to a transaction which failed because of this problem:
https://rinkeby.etherscan.io/tx/0xb3e52f52a329c6406743d864df4bc84d29df13107c053cce363554121e8e1990
Marking this as "backlog" since I don't think that this issue applies now since users cannot pass custom salts anymore.