separate production vat bootstrap from testing mechanisms

[dckc]

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 Remove getBootstrapPayment() from Treasury #4021)
  • for testing: create "fake" price authorities
    • note plans to use something like coinmarketcap in Create a price authority out of the Coingecko API (demo) 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: #4347 , #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.

[Chris-Hibbert]

switch (ROLE) allows one bootstrap to handle production validators, production clients, and fake chains.

[dckc]

The current bootstrap mints 1B RUN out of thin air for a feePurse.
Anybody have thoughts on how this should work in production?

agoric-sdk/packages/vats/src/bootstrap.js

Lines 81 to 86 in 71f8101

	const feeIssuerConfig = {
	name: CENTRAL_ISSUER_NAME,
	assetKind: AssetKind.NAT,
	displayInfo: { decimalPlaces: 6, assetKind: AssetKind.NAT },
	initialFunds: 1_000_000_000_000_000_000n,
	};

agoric-sdk/packages/zoe/src/zoeService/feeMint.js

Lines 40 to 42 in 71f8101

	const initialFeeFunds = feeIssuerKit.mint.mintPayment(
	AmountMath.make(feeIssuerKit.brand, feeIssuerConfig.initialFunds),
	);

[Chris-Hibbert]

If we need a subsidy to get the chain off the ground, we should find a way to keep it small/limited.

As I understand current thinking, at the beginning of the live chain, the only source of capital that's available is BLD tokens. Those could be used to get RUN line of credit, which could be used to pay fees in order to get Vaults (née Treasury) and AMM set up. In order to fund various pools for the AMM, we'd need a source for other tokens. The Vaults really shouldn't be started until their respective AMM pools exist.

The hard part about bootstrapping is that the RUN line of credit can't be started without a little bit of RUN to pay for fees, so I think the start-up subsidy is necessary. Luckily, the feeMintAccess token that we need for Vaults and RUN LoC could also enable a one-time faucet. But the faucet can't run without a source of fees, so whatever work-around we'd use to start the faucet could just be used on the RUN LoC instead.

[dckc]

@dtribble notes that genesis for the JS phase may inherit RUN minted during the cosmos-only phase. Should one of the owners spend that to bootstrap the JS components?

Or... can we just not charge fees for some stuff?

[Chris-Hibbert]

another alternative from this morning's #engineering discussion:

• a big switch to turn fee charging on and off. The simplest version just allows bootstrap to proceed without fees until sufficient parts of the economy are running, and then turn on fees.

[dckc]

idea from chat with @michaelfig : CapTP + spawner + bootstrap namehub

solo: bootstrap object in web.js

[dckc]

It looks like makeFeeCollector(zoe, creatorFacet) was broken in in #4026. There doesn't seem to be a test. The method should map over the array of facets. @Chris-Hibbert says he changed schedulePayments() in distributeFees.js to map over something, but didn't do the same with makeFeeCollector().

I think I fixed it in 71a8b3f, but a bunch of other stuff is mixed in there.

[Chris-Hibbert]

I think I fixed it in 71a8b3f, but a bunch of other stuff is mixed in there.

The lines that seem to be addressing this

    E(vats.distributeFees)
      .buildDistributor(
        [treasuryCreator, ammFacets.creatorFacet].map(cf =>
          E(vats.distributeFees).makeFeeCollector(zoeWUnlimitedPurse, cf),
        ),
        feeCollectorDepositFacet,
        epochTimerService,
        harden(distributorParams),
      )

look right to me.

[dckc]

@michaelfig I rebased the bootstrap-core branch on master: 26d1f6e

esp bootstrap-core.js

[dckc]

Idea: mainnet 1 Genesis names privileged modules to install.

[michaelfig]

Idea: mainnet 1 Genesis names privileged modules to install.

I think that the genesis.json could have something like:

s/Power Snippet/Capsule/g

  "bootstrapCapsules": ["someFunc1", "someFunc2"],

where you define the capsules in bootstrap-core.js something like:

// Trick to reify capsule async function names as properties we can invoke.
import * as capsules from './capsules.js'

// ... thread through the bootstrapCapsules as part of `vatParameters.argv`, then:

// Run all the bootstrap capsules in parallel.
await Promise.all(
  bootstrapCapsules.map(
    cname => Promise.resolve().then(() => capsules[cname]({ ....powers, capsules })),
  ),
);

[dckc]

further refinement (41b9850): let genesis.json say exactly which powers each capsule gets.

export const bootstrapManifest = harden({
  behaviors: {
    connectVattpWithMailbox: true,
    buildZoe: true,
  },
  endowments: {
    connectVattpWithMailbox: {
      vatPowers: { D: true },
      vats: { vattp: true },
      devices: { mailbox: true },
    },
    buildZoe: {
      vats: { vatAdmin: true },
      devices: { vatAdmin: true },
      workspace: true,
    },
  },
});

export const simBootstrapManifest = harden({
  behaviors: { installSimEgress: true, ...bootstrapManifest.behaviors },
  endowments: {
    installSimEgress: {
      vatParameters: { argv: { hardcodedClientAddresses: true } },
      vats: {
        vattp: true,
        comms: true,
      },
      workspace: true,
    },
    ...bootstrapManifest.endowments,
  },
});

2022-01-06T06:39:05.642Z start: swingset running
2022-01-06T06:39:05.643Z outbound: invoking deliverator; 1 new messages for sim-chain
2022-01-06T06:39:05.649Z SwingSet: vat: v1: bootstrap: installSimEgress({"vatParameters":{"argv":{"hardcodedClientAddresses":true}},"vats":{"vattp":true,"comms":true},"workspace":true})
2022-01-06T06:39:05.651Z SwingSet: vat: v1: bootstrap: connectVattpWithMailbox({"vatPowers":{"D":true},"vats":{"vattp":true},"devices":{"mailbox":true}})
2022-01-06T06:39:05.655Z SwingSet: vat: v1: bootstrap: buildZoe({"vats":{"vatAdmin":true},"devices":{"vatAdmin":true},"workspace":true})

[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]

see also: authority viz
https://gist.github.com/dckc/b910588219de97b72e507050564b33c5#file-x-svg
https://github.com/Agoric/agoric-sdk/tree/dc-authority-viz 0ce4971

more recently:
https://gist.github.com/dckc/63b0635baf6f5a4a60af1e6ac75c5b40

[dckc]

3 chunks recently:

1. Thu, 27 Jan PM 57a5908 refactor(vats): start vault factory without install-on-chain
2. Fri, 28 Jan AM: 2e9baf2 feat(vats): support behavior config via boostrap vatParameters
3. Fri, 28 Jan PM:
   • c6c7946 chore(run-protocol): fix, test AMM bootstrap
   • cd8afa3 test(run-protcol): unit test startVaultFactory

[dckc]

It looks like we're moving back to using boot.js in order to do #5819, so let's be sure to remove SIM_CHAIN_BOOTSTRAP_MANIFEST while we're at it. For decentral-demo-config.js, we can use a separate bootstrap module, analogous to boot.js.

agoric-sdk/packages/vats/src/core/boot.js

Line 13 in 416b3e7

SIM_CHAIN_BOOTSTRAP_MANIFEST,

[dckc]

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