all vats that will be deployed in Vaults Release must be upgradable

[dckc]

What is the Problem Being Solved?

Analogous to #5666:

We need all of these to be upgradable, so we don't find ourselves stuck later when we want to add a feature or fix a bug. That means replacing their Far objects with instances of a durable Kind.

Description of the Design

based on a quick audit it looks like the gaps are:

Tasks

Beta Give feedback

1. vat: zoe (feat(ertp): durability #5283)
2. feat(vats): upgradeable mintHolder contract #6894
   automerge:no-update +1
3. feat(vats): upgradeable board #6903
   automerge:no-update bypass:integration +2
   
4. contract: provisionPool is upgradable #7494
   vaults_triage +1
   
5. Rename vat-chainStorage to vat-bridge and make it upgradable #7107
   automerge:no-update contract-upgrade cosmic-swingset +3
   
6. vat: priceAuthority is upgradable #7495
   oracle vaults_triage +2
   
7. make vat-bank reachably durable #5885
   ERTP cosmic-swingset enhancement vaults_triage wallet +5
   
8. Bootstrap ocaps are stored durably in vat-bootstrap #4548
   7 of 7
   cosmic-swingset enhancement vaults_triage +3
   
9. vaults bootstrap includes extra bundle: vat-network #7044
   bug cosmic-swingset vaults_triage +3
   
10. make vat-bank upgradable #7633
    enhancement vaults_triage +2
    

indicentally, not in pismoA nor vaults:

• make vat-network upgradable #5696

note related issues covering some startup vats/contracts not in the @agoric/vats package:

• walletFactory make Smart Wallet contract durable #5894
• zoe store Zoe state in durable/virtual objects/collections #4383
• PSM (and presumably, psmCharter): verify by end-to-end test a contract on-chain can be upgraded #6099
• governance make governance system allow governed contracts to be upgradable #7248
  • committee
  • contractGovernor
  • binaryVoteCounter

and there's perhaps some overlap in scope with #4511

Security Considerations

?

Test Plan

CI test (swingset or bootstrap) of each vat

cc @JimLarson @turadg @michaelfig @Chris-Hibbert

[dckc]

@Chris-Hibbert are the committee, contractGovernor and binaryVoteCounter contracts in the scope of #5200?

perhaps it's better to scope this to packages/vats/; #4983 covers packages/inter-protocol. #4511 isn't scoped to any package(s)... hm...

[Chris-Hibbert]

are the committee, contractGovernor and binaryVoteCounter contracts in the scope of #5200?

Yes.

[warner]

That means replacing their Far objects with instances of a durable Kind.

To be picky (I was too glib in the issue that this line was copied from), it also requires:

• those KindHandles are kept in durable storage
• the startup process of each vat/contract uses Baggage and more defineKind calls to reassociate behavior with every Kind (defineKind must be called at the start of every incarnation, so once per upgrade)
• it also uses provide patterns to ensure that each exported object is only created once (in the first incarnation), not once-per-upgrade
• everything that behavior needs to do its job is kept in durable storage

But for sure, if you see Far in the code for a vat, and that object isn't explicitly marked as "subject to abandonment during upgrade, clients will observe the trauma and must be prepared to deal with it", then that vat is probably not really upgradable.

[dckc]

... it also requires: ...

Is that list collected anywhere for reference? Is #5708 still a good summary?

In any case, perhaps it's good input to Agoric/documentation#750

[turadg]

@dckc I've replaced 5200 in the description with #7248 which is about upgradability per se. That the state of governance is durable (#5200) is not strictly a requirement.

[turadg]

Treating this ticket as an epic, removing its estimate. Made each bare checklist item into an issue and estimated.

[dckc]

The last of the items on the checklist here is done:

• make vat-bank upgradable #7633