Improve publishing DX for deploying contracts

[kriskowal]

What is the Problem Being Solved?

The current process for deploying a contract involves an agoric run script which generates some artifacts and recommends shelling out to agd to do the actual work. These agd commands can fail if the message sizes exceed the maximum configured for the designated RPC node. A particularly pernicious failure mode is when one accidentally submits a package.json instead of a bundle.json, in which case the chain not only cannot process the request, but also can’t identify the request in a way that the requester can observe. (The response topic is keyed on the expected bundle identifier, inside the JSON envelope.)

Description of the Design

To holistically address these problems, we need to streamline the submission process and ensure that messages to the chain are consistently smaller than the maximum message size. We need a solution that continues to leverage the expressiveness of the agd command line tool, particularly interfacing with hardware wallets and secret storage (ergo, march back from pure JavaScript CosmJS APIs and back to agd subprocesses in agoric publish). We can leverage a module Content Address Store to reduce duplication between bundles, but should continue to disincentivize duplication. Even if we do eliminate duplication between overlapping contract dependencies, we must still fragment submissions across multiple messages to the chain when the new material is too large for a single message.

• Fragmented bundle to chain transport #5096
• Command line flag parity for agoric publish with agd tx swingset install-bundle #8554
• agoric publish uses poor, bespoke key management #8785

Adjacent

• change zoe/etc tests to use bundlecaps, not bundles #4487
• change all dapp deploy scripts to install by hash bundle, not source bundle #4564
• add controller.getBundle(bundleID) -> bundle API #4954
• drop zoe.install(bundle) #8083

@warner and I propose a process (#5096) that herds the DX through a single agoric subcommand that shells out to agd as many times as necessary to submit the entire contract, spanning multiple messages if necessary. This will give us the freedom to make the protocol more interactive: The tool would take a bundle, extract it into memory, submit the compartment-map.json to the chain, watch for a response from the chain that includes the hashes of the modules it does not already have, then follow up with one or more messages to deliver those modules.

The chain would then use a variation on importBundle to assemble a contract from just its compartment-map.json and a CAS for the individual modules, keyed on their integrity sha512 hash.

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations