Contract upgrade tooling: makefile + documentation

[snissn]

No description provided.

[adlrocha]

Can a subnet actor be upgraded if it wasn't initially deployed using hardhat but the ipc-cli? This would mean that the deployment assets are not available for deployment.

[snissn]

I don't know enough about ipc-cli to answer this question.. does ipc-cli end up calling hardhat?

[adlrocha]

Unfortunately not, it makes a transaction to the registry to trigger the deployment of a new subnet actor. Is there a way to artificially generate a desployment.json to help with the upgrade? We may need to come up with a way to allow updates from subnets deployed from the registry.

[snissn]

I think I understand better how this code works and what needs to happen for this to work from doing the internal audit. I think that there's a reasonable way through this where we need to add code in ./src/subnetregistry/RegisterSubnetFacet.sol that includes the diamond cut facets and then we will just need to exapnd the facets on the subnet registry to manage the upgrades. we'll need some sort of management for the equivalent of deployment.json but that might not be so bad and it might make sense to store some of these data items on chain in the registry. One last concern is that we may end up with a system that has too many subnets to upgrade in a single block so we should have a fallback there to paginate and may need to think about whether we need to do this upgrade change in a transaction where contracts are paused during the upgarde if it spans multiple txs

[raulk]

Now tracking here: consensus-shipyard/ipc#497

[adlrocha]

hey @snissn. Do you mind rebasing this one and fixing the conflicts? I think it may be a good idea to get this one merged and address my comment about the subnet upgrade mechanism in a follow-up PR (in order not to leave this one hanging too long).

[raulk]

There seems to be a bunch of improvements still needed here, but let's merge this and continue working on the rest in the ipc-monorepo.