6765 publish vaultManager's price feed

[turadg]

closes: #6765

Description

This makes the VaultManager publish changes to its price feed. The PriceAuthority returns a Notifier so this adds a makeStoredNotifier to pipe the prices to vstorage. I considered just having an observeNotifier but we have a commitment that a contract consumer can do its work without reading vstorage. So we need to continue the StoredFacet pattern that exposes a getPath(). I dropped getStoreKey though since that's deprecated.

In the course of making these changes, I need a collateralUnit during initState and getting it requires an await, which initState can't do. Since vaultManager is a singleton kind, it can be passed into prepareVaultManager and exist in closure. So this also has a refactor to move many initState params up to that prepare. cc @dtribble as it introduces arguments to addChildBaggage.

Best reviewed by commit.

Security Considerations

Similar to the scaling considerations, wrt undue load.

Scaling Considerations

This exposes a Notifier on VaultManager which means that anyone can ask for a price since any updateCount. Not so, explains @michaelfig below,

A Notifier only keeps the latest state, and all historical states are dropped. The updateCount cannot be used to index into past states, it is only used for the Notifier implementation to determine if the consumer needs to wait for the next value from the producer, or if the latest state is good enough.

Documentation Considerations

The list of storage nodes published by VaultFactory should be updated. Deferring to #6111

Testing Considerations

New test. No need to test the vstorage writes per se.

[michaelfig]

This exposes a Notifier on VaultManager which means that anyone can ask for a price since any updateCount. I think that means all updates have to be held eternally.

That's a common misconception. A Notifier only keeps the latest state, and all historical states are dropped. The updateCount cannot be used to index into past states, it is only used for the Notifier implementation to determine if the consumer needs to wait for the next value from the producer, or if the latest state is good enough.

[dckc]

Test coverage for the quotes storage feature looks good.

I'm not confident I grok the 1st 2 commits (change to provideChildBaggage, init args) but it seems like the sort of thing that wouldn't survive our test suite if it were wrong.

I presume the scaling considerations in the PR are, as @michaelfig suggests, based on a misunderstanding.

[dckc]

I don't suppose there's a straightforward way to get the displayInfo earlier, is there?

[dckc]

nice test. thanks.

[gibson042]

Ugh, these names...

Suggested change

	export const makeMarshallToStorage = (storageNode, marshaller) => {
	return value =>
	E(marshaller)
	.serialize(value)
	.then(serialized => {
	const encoded = JSON.stringify(serialized);
	return E(storageNode).setValue(encoded);
	});
	};
	export const makeSerializeToStorage = (storageNode, marshaller) => {
	return async value => {
	const marshalled = await E(marshaller).serialize(value);
	const serialized = JSON.stringify(marshalled);
	return E(storageNode).setValue(serialized);
	};
	};

But also, what is the benefit of defining such a function in lib-chainStorage? I'd be happiest if this package were imported only from the vat that calls makeChainStorageRoot (i.e., the one with access to the bridge device) to which other vats just sent simple messages.

Also, if sending an object to a remote Marshaller to get input for JSON.stringify serialization on the way to chain storage is a common pattern, then I'd also like to save round trips by incorporating the JSON.stringify serialization into a logical wrapper of either Marshaller serialize or [less preferably] StorageNode setValue and getting the initiator out of the path between them, e.g. storageNode.setValue(E(marshaller).marshalAndSerialize(value))¹² or storageNode.serializeAndSetValue(E(marshaller).serialize(value))).

Footnotes

1. Extending StorageNode setValue's input signature from (value: string) to (value: ERef<string>). ↩

2. Where marshalAndSerialize takes a passable, encodes it (to CapData/smallcaps/etc.), serializes the result (to JSON text), and returns the result—and could/would be more tersely named serialize if that were not currently claimed by just the first [encoding] step. ↩

[turadg]

+1 on the names. I can't invest in until after Vault release.

The code change LGTM and I'll probably incorporate it into another PR. Not worth retriggering deployment-test rn.

The round trips is a problem. I think @dckc 's meant to help #6646

[dckc]

re "The Endo one-interface-to-rule-them-all" for notifiers / subscriptions, I hope there's an issue to represent it. endojs/endo#1035 looks close. I'm inclined to use that until I hear otherwise.