feat(vats): publish vbank asset list with agoricNames

[dckc]

closes: #5762
refs: Agoric/dapp-inter#9

Description

• add a vbankAsset entry in agoricNames
• add an entry under it for each addAsset() call that maps denom to { brand, issuer, issuerName, denom, proposedName, displayInfo }
  • provided the optional nameAdmin arg to makeBankManager() is present

Security Considerations

claim for review: the only objects we're publishing here are brands and issuers.

Documentation Considerations

our docs on chainStorage keys / paths are kinda scattered. I suppose we can consider that in scope of #6111 rather than here.

Testing Considerations

tested manually with make scenario2-run-chain, and that before adding displayInfo support.

$ agoric follow :published.agoricNames.vbankAsset
...
[
  [
    "ubld",
    {
      brand: slot(0,"Alleged: BLD brand"),
      issuer: slot(1,"Alleged: BLD issuer"),
      issuerName: "BLD",
      proposedName: "Agoric staking token",
    },
  ],
  [
    "uist",
    {
      brand: slot(2,"Alleged: IST brand"),
      issuer: slot(3,"Alleged: IST issuer"),
      issuerName: "IST",
      proposedName: "Agoric stable local currency",
    },
  ],
]

[turadg]

putting it under agoricNames mostly feels right, but... should it go somewhere else?

I'm sure it should go under published. The other children there are,

• committees
• provisionPool
• psm
• wallet

It clearly doesn't belong under any of those. But maybe it merits its own key, vbank?

I expect we'll take a pass through to #6111 before release.

[turadg]

this is awaiting displayInfo even if it's not used. is that cheap?

[dckc]

no; it's an inter-vat round-trip. good catch. I can postpone this until I'm waiting for the settled issuer.

[dckc]

hm... actually, if we needed a round-trip to settle kit.brand, the call to getDisplayInfo() should get pipelined rather than taking an extra round trip. But kit.brand might have been settled in the 1st place, in which case this is an extra round trip.

[samsiegart]

Tried locally and was able to load the display infos in the UI 👍

[dckc]

... But maybe it merits its own key, vbank?

Right... that's what I was wrestling with.

Aha... it's like all the other things under agoricNames in that it's (the entries of) a NameHub, so it can be used a la lookup('agoricNames', 'vbankAsset', 'uist') from the REPL. And the contents are governed by the swingset.CoreEval big hammer (that is: not yet delegated to anything less than a BLD staker vote). So yes, I think it belongs under agoricNames.

[dckc]

@michaelfig it's currently keyed by denom. I expected to key it by name, a la agoricNames.brand and agoricNames.issuer, but I didn't see any uniqueness guarantee there in vat-bank.js. ISTR from REPL usage that there is such a constraint. Help me find it?

[turadg]

No change requests but I want to understand the two issuer resolutions before approving.

[turadg]

good doc. for my understanding, is that the same as saying "has a presence of the issuer"?

[dckc]

yes, unless the issuer was actually created in the publishing vat, in which case it would be the object itself and not a presence for it.

[michaelfig]

[no apparent denom uniqueness requirement]

The requirement is enforced via:

denomToAddressUpdater.init(denom, makeStore('address'));

The .init will throw if called multiple times with the same denom.

[dckc]

@michaelfig yes, I know denom uniqueness is enforced. My question is: where is issuerName uniqueness enforced?

[michaelfig]

yes, I know denom uniqueness is enforced.

Ah, sorry for misreading.

My question is: where is issuerName uniqueness enforced?

I don't see any direct enforcement of issuerName uniqueness, but besides denom, reusing the issuer is also forbidden because of brandToAssetRecord.init(brand, assetRecord); Could that be what you're remembering?

[dckc]

... reusing the issuer is also forbidden because of brandToAssetRecord.init(brand, assetRecord); Could that be what you're remembering?

ah. yes.

So denom is the only suitable string key so far. But it seems a little awkward. I wonder if we should add a uniqueness constraint on issuerName so that we can key this NameHub on issuerName instead.