Governance support persistence and contract upgrade #8123
Comments
Chris-Hibbert
added
enhancement
closes: #8049 closes: #8740 closes: #8868 closes: #8918 closes: #8981 closes: #8079 refs: #8400 closes: #8735 closes: #7873 closes: #8726 closes: #7954 closes: #8757 closes: #8728 closes: #8789 ## Description Upgrade **VaultFactory** in A3P, relying on the new PriceFeeds, and auctions. The actual upgrade waits for the priceFeeds to start supplying before doing the upgrade, so there won't be any gap in priceUpdates. When the upgrade is finished, we also update the auctioneerKit and Auction instance in the bootstrap environment. This PR demonstrates that VaultFactory can be upgraded even though governance is not persistent (#8123). ### Security Considerations N/A ### Scaling Considerations This is largely in service of #8400, which reports that priceFeed vats are accumulating garbage. This PR switches to new priceFeeds, which won't have that problem, though cleaning up the existing vats is a task for the future. ### Documentation Considerations No changes to user-visible behavior. ### Testing Considerations A3P tests that verify that vaultFactory has been upgraded, that a new Auctioneer is running and is receiving prices. Verify that when prices drop, assets are sold via the auction, the bidder gets the proceeds, and the vaults are liquidated or reconstituted appropriately. ### Upgrade Considerations Upgrade all the vats!
This is not quite right. The paramManager lives inside the governedContract, so the upgradeability of the governor doesn't control whether param values persist across upgrades. #8981 demonstrates that governance writes the changing parameter values to vstorage, and they can be recovered from there to repopulate the upgraded contract's parameters. It would be more convenient if the paramManager persisted its values inside the contract's baggage, and recovered them on restart. Of course, that won't solve the problem for any existing governed contract's first upgrade. but later upgrades...
|
|
Linear overstepped. This should remain open. |
What is the Problem Being Solved?
Contract Governance is not persistent, so if we were to upgrade contracts, they would lose the state of their governed parameters.
Description of the Design
Add Durability to the necessary components of governance so that contracts can be upgraded and thereafter retain the state of their parameters. Most parameters could be re-initialized to their values as in terms, from which point governance could mutate them further.This is not true of invitations, since
termsonly includes the amount.Security Considerations
Maintain legibility of parameters. If any param values have to be provided via private args during the upgrade, it's crucial that param governance or some other mechanism maintain their visibility.
Scaling Considerations
N/A. contract upgrade is one-at-a-time.
Test Plan
an upgrade test that show two cycles of upgrade, since retaining param values can only be observed on the second refresh.
Upgrade Considerations
It's all upgrade.
The text was updated successfully, but these errors were encountered: