change all dapp deploy scripts to install by hash bundle, not source bundle

[warner]

What is the Problem Being Solved?

After #4563 gives Zoe the ability to E(zoe).install(bundleID) (instead of a bundle), and after #4396 gives cosmic-swingset the ability to accept "install bundle" transactions, the next step of the process is to change the deploy scripts in all dapps to use them. Currently, these deploy scripts use bundleSource() on the local contract code, then E(zoe).install(bundle), which creates a large (swingset/mailbox) message to deliver the bundle to the chain and install it. That should change to:

• use bundleSource() to get both a bundle and it's bundleID (hash)
• use a new client-side facility to construct and send the #4396 install-bundle transaction to the chain
• send E(zoe).install(bundleID)

Description of the Design

We need the client-side facility to create the new transaction types.

Security Considerations

On the real chain, for the Mainnet-1 timeframe, there will be a governance process to limit the installation of new contracts. The bundleID must be in an approved list before the install-bundle transaction will be accepted. Test chains won't have such a limitation. I think the real chain process will look like:

• author develops the contract code, test, finalize, publish source code for review
• author bundles and computes the bundleID
• author submits governance proposal to allow the bundleID to be installed
  • voters will look at the alleged source code (a git tag in some repo) for correctness/safety
  • voters will rebuild the bundle, compute the ID, compare against proposal
• voters approve the proposal
  • ID goes onto the approved-IDs list
  • E(zoe).install(ID) is called by the proposal code, waits for bundle to be installed
• author runs deploy script
  • deploy script constructs install-bundle txn, signs, submits
  • txn goes into block, accepted by approved-IDs list, causes controller.validateAndInstallBundle()
  • E(zoe).install() wakes up because the #4521 "bundle is now installed" promise fires
  • proposal code adds installation handle to.. the Board?
  • installation complete, available for instantiation

Test Plan

cc @michaelfig

[Tartuffo]

@kriskowal Is this something you could take on?

[kriskowal]

I can. I would bump the estimate to 5. I’ll need to get up-to-speed on @warner’s bundle caps API and some kernel layers I haven’t touched yet. The extra time is probably a good investment.

[Tartuffo]

Estimate bumped.

[Tartuffo]

This needs to happen for the RUN Protocol Review release, but not for all DApps, just for the scripts that deploy the proposal(s) to start RUN protocol. We need someone to pick up this work. FYI @dckc

[michaelfig]

The current plan that @kriskowal is working on does not require any code changes to deploy scripts. We may still change deploy scripts for other reasons (captured in other issues), but this is not one of them.

[kriskowal]

The plan has changed. Dapps will need to performa a migration like: https://github.com/Agoric/dapp-fungible-faucet/pull/46

This is because bundleSource and publishBundle are orthogonal concerns. bundleSource should be pinned in yarn.lock, and cannot be pinned down if agoric-sdk is linked and not installed. publishBundle has an optional ConnectionSpec argument shouldn’t be threaded through bundleSource implicitly.

These aren’t absolute constraints, but I think strong enough to make the separation between the two functions clear in dapp deploy scripts.