rationalize Inter Protocol storage node paths

[turadg]

What is the Problem Being Solved?

They've developed somewhat ad-hoc. For PSM we realized there's more than one PSM (at least one per anchor) and then we realized that even IST may not be fixed: there will someday be another PSM whose mint isn't IST.

This same insight applies to most of Inter Protocol contracts. E.g. published.vaultFactory shouldn't assume it's the only vault factory on chain.

Description of the Design

Namespace under IST or something similar.
Design naming scheme going out to MN-3 permissionless.

Doc for naming of keys too. Cover this case #5393 (comment)

If keys are an index of high cardinality, they should be under their own parent key so that they don't make siblings of other types hard to find. E.g. if manager102 sibling to metrics is bad because the latter will be easy to miss. managers sibling to metrics is good.

• fix published.vaultFactory.manager0
• fix published.auction.book0

Security Considerations

First to claim gets the path.

Test Plan

• Manually validate that the scheme supports Allow multiple vault types for a given collateral type #6518

[dckc]

See also:

• agoricNames: managing naming consistency between dApps and chain #4084

And there's perhaps a more general issue of documenting not just the keys but also the data at those keys.

Speaking of which...

• Provide /custom/vstorage/flatdata endpoint for contract notification data #5968

[dckc]

In the Jan 23 approach (#6835) to putting vbank assets in chainStorage (#5762), agoricNames.vbankAsset is keyed by denom (ubld, uist, ibc/32432t34362354). Nearby NameHub collections such as agoricNames.brand are keyed by issuerName (BLD, IST, USDC_axl), but I couldn't find a uniqueness constraint on issuerName in the vbank code.

I wonder if we should add a uniqueness constraint on issuerName so that we can key this NameHub on issuerName instead.

[dckc]

idea: snapshot tests for documentation

For each contract etc. that "owns" part of chainStorage, make a snapshot test with example data. Then index the resulting .md files, perhaps in a few places. https://github.com/Agoric/agoric-sdk/tree/master/packages/inter-protocol#reading-data-off-chain is one useful place, but it doesn't cover, for example, agoricNames.

(inspired by a quick review of makeChildNode() calls)

p.s. by way of example: https://github.com/Agoric/agoric-sdk/blob/6111-dc-chainStorage-snapshot-idea/packages/vats/test/snapshots/test-agoricNames-rpc-api.js.md

[turadg]

Taking this general ticket out of Vaults Release. The one important change not to defer is in #7150