make vat-bank reachably durable

[warner]

What is the Problem Being Solved?

vat-bank holds "virtual Purses" which represent the balances of accounts that are managed by cosmos-sdk on the golang side of the bridge. There will be a whole lot of these, and currently vat-bank holds an in-RAM object for each one, so the memory footprint is a concern.

The final goal is to get flat memory usage despite an arbitrary number of accounts (each of which holds a virtual purse for each of some moderate number of denominations).

This will be complicated by the code it needs for making balance updates. ERTP-style clients want to use getCurrentAmount() to get the most recent amount, and also getCurrentAmountNotifier() to get a (lossy) stream of updates. The balances themselves live in the cosmos side, where they could be queried on demand, but currently the cosmos Bank module sends (large) update messages to JS for every change. This enables getCurrentAmountNotifier() and reduces the work needed by getCurrentAmount(), but leads to significant load for data that nobody is paying attention to (yet).

Issues around vat-bank performance:

• refine bankManager / VBANK to provide purses on demand #5412 : only make purses on demand
• Bank vat has a memory leak #5671 : apparent memory leak
• bank vat updates for hundreds of accounts in a block is slow #3629 : updates are too slow
• notifying smart wallet of every vbank balance update is too expensive #5896

The Notifier involves Promises. Our plan for a durable Notifier (#4567) still needs RAM for the Promises held by "active" notifiers (where some client is waiting on a new value). And we expect that clients like the on-chain smart wallet will be constantly fetching new balances, so it's likely that every Notifier will be active all the time. We may need fully-virtual Promises (#3787) achieve flat RAM usage under that constraint.

Description of the Design

Not entirely sure, but at the very least we need the bank object (one per account) and the VirtualPurse object (one per account times denomination) to become instances of virtual Kinds. These are the user-facing objects.

It looks like each bank object also has a balanceUpdater object to be the receiver of the cosmos-initiated new-balance messages. These should be virtual too. In our current "push" architecture, where cosmos sends an unsolicited message about balance updates, the virtual-object manager will reconstitute Representatives for them on-demand, so we'll only spend RAM on them if/when a balance changes, which is ideal. Their associated Notifiers may not have that property, of course.

I suspect we need to overhaul the way we manage balance updates at the same time. I don't yet know what approach might work and get us flat memory usage.

Security Considerations

vat-bank has a mint-like authority over "native" (cosmos-managed) tokens; at the very least it can transfer tokens between arbitrary accounts. So that authority must be carefully managed.

Test Plan

I don't know.. it's not clear how vat-bank is currently tested.