Vat upgrade: 14 mintHolders #10410
Assignees
Labels
Comments
Chris-Hibbert
added
enhancement
|
@Chris-Hibbert says "pick a number of vats and upgrade them, no need to upgrade all" |
|
That was intended to be pick a number of vats and upgrade them in upgrade 19, and leave the rest for upgrade 20." |
mergify bot
added a commit
that referenced
this issue
Dec 12, 2024
#10617) closes: #10410 ## Description This pull request intends to ensure that the mintHolder contract continues to function as expected after a null upgrade. Key Changes: - A new `core-eval` was built, which acordingly to the agoric chain variant, will select a list of vbankAsset and execute a null upgrade to the respective mintHolder contract of each suitable asset. - A new acceptance test, `mintHolder.test.js`, has been added to the a3p-integration to verify the core-eval behaviour. MintHolder Test Plan: - Provision a receiver wallet with the respective assets - Confirm the initial balance matches expectations - Perform a null upgrade for the mintHolder contracts - Execute a core-eval to: - Mint a payment for each selected asset - Deposit the payment into the receiver's depositFacet - Verify that the balance has increased by the expected amount - Execute a PSM swap for selected assets with IST ### Security Considerations The execution of `mintHolder.test.js` had to be done prior to the `./genesis-test.sh` acceptance test. Otherwise it would trigger the error `bundle ${id} not loaded` during the `evalBundle` call. See this issue for more detail: #10620 ### Scaling Considerations This PR does not introduce any change to the mintHolder source code, or how it is being consumed. For this reason that are no scaling considerations to be made. ### Documentation Considerations ### Testing Considerations The implemented test design is expecting to have a core-eval for each mintHolder being updated. If desired, this could be refactored to have a single core-eval executing a null upgrade to a predefined list of assets. The second approach has the advantage of reducing the number of files being created, although it may hinder the testing flexibility. Which approach is more desirable? ### Upgrade Considerations
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the Problem Being Solved?
As mentioned in #8158, we need the ability to restart or replace all vats. This issue is concerned with upgrading the 14 existing mintHolder contracts.
Description of the Design
The source code is mintHolder.js. These are not Zoe contracts. upgrade-vats.test.ts shows that They are upgradeable, though it doesn't test functionality. We should upgrade a mintHolder in
a3p-integrationand show that it continues to function correctly.We should upgrade a few at first, and more over time.
Security Considerations
mintHolders are the foundation for a lot of assets on our chain.
Scaling Considerations
Not significant. Measurements haven't shown any indication of problems.
Test Plan
As above. test in a3p-integration.
Upgrade Considerations
As above. Don't upgrade them all at once.
The text was updated successfully, but these errors were encountered: