separate production vat bootstrap from testing mechanisms

What is the Problem Being Solved?

The initial conditions for all the vats in our system are in vats/src/bootstrap.js. Currently, it mixes a bunch of testing / demo mechanisms in a way that makes it difficult to be confident that we aren’t vulnerable to excess authority.

Description of the Design

bootstrap.js currently interacts with a large set of features:

• setting up zoe
• setting up the vaults and AMM
  • getBootstrapPayment (note plans to remove this in Agoric/agoric-sdk#4021)
  • for testing: create “fake” price authorities
    • note plans to use something like coinmarketcap in Agoric/documentation#664
  • for testing: setting up liquidity in the AMM
• setting up dapp facilities including http API endpoints and plugins
• provisioning user accounts
  • creating vattp and comms remote / egress
  • creating IBC ports
  • creating the home bundle and connecting it to the REPL and http
  • for testing / devnet: minting tokens so that users start with assets to work with

@michaelfig @warner what’s missing in that list? Can you think of any that we should get rid of?

My inclination is to start with a simple bootstrap that establishes the connections suitable for production and then layer testing mechanisms on top of that. Perhaps more of the functionality should be installed via Zoe? For example, the LINK and ATOM we use for testing could come from a contract that creates a new zcfMint and uses the mint to add liquidity to the AMM and to provide each new user with some funds to play with.

cc @erights @Chris-Hibbert @rowgraus

Security Considerations

Code such as vat-mints.js, which mints tokens freely, is useful for demos, but should be clearly segregated from code used in production.

cc @jessysaurusrex

Documentation Considerations

The home API is somewhat under-documented. (Separate issues: Agoric/agoric-sdk#4347 , Agoric/agoric-sdk#3154).

Test Plan

Review the current bootstrap.js looking for features that we don’t currently have automated tests for and if we want to keep them, add tests.

[warner]

One tiny note: the need to connect vats.comms and vats.vattp, plus the need to connect devices.mailbox to vats.vattp, are common to all swingset installations, rather than being a specific feature of the Agoric chain or ag-solo instances. I haven’t been able to think of a clean way to have swingset do this wiring itself (#51), so it remains as a “some assembly required” wart that host apps (chain/ag-solo) must deal with.

I’d suggest encapsulating that part of the initialization into a separate function, to at least make it clear that this is a part that ought to be swingset’s responsibility, but unfortunately is not yet.

[dckc]

rather than edit description to re-summarize history back to Dec 2021, let’s make a new issue: #6687