try rewriting issuer.js with Representatives/Containers (virtual objects)

[warner]

#455 describes a plan for moving large state (made of millions of small JS objects) from RAM to disk. This trades off the clarity of a simple Map-based ocap style against performance gains that will probably be necessary to support our target volume.

One component of that plan is to rewrite the vats that create+manage this state to use the newly proposed API:

const purse = (me, c) => ({
    deposit(other) {
      const myBalance = c.get(me);
      const otherBalance = c.get(other);
      c.update(me, myBalance + otherBalance);
      c.update(other, 0);
    }
});

const c = vatPowers.createContainer(purse);

function mint(initialBalance) {
  return c.create(initialBalance);
}

(note: the c argument to purse may or may not be the same c as returned by createContainer, we need to decide)

The object returned by purse() or c.create() is called a "representative", and it is a short-lived stand-in for the long-lived virtual Purse object. The representative knows that it is short-lived, and all its state must live in secondary storage (accessed with c.get and c.update).

@dtribble has agreed to make an initial pass at rewriting issuer.js to use this new scheme. To be clear, this won't run yet: we haven't implemented createContainer. The goal of this first step is to decide whether the proposed API is even suitable for the Issuer's purseLedger and paymentLedger tables (replacing the Store which currently holds that data).

A separate step will be to offer createContainer so his code can actually run. We could fake this within liveslots (without actually adding the new syscalls) as an intermediate step, or move directly to disk-backed tables.

The questions we want to answer are:

• how readable/auditable is the resulting code?
• how much will be mourn the loss of a pure ocap-style Issuer?
• are there rights-amplification patterns involving multiple representatives (possibly from multiple containers) that require additional API to express?
• can the secondary-storage data (the return value from c.get, the second argument to c.update) be limited to flat JSON-able objects, or do we need a full marshalling step that can serialize pass-by-presence objects as well as other representatives? We expect to need the full marshalling step eventually (e.g. for Zoe offers/seats), but it would be nice to know what specific patterns provoke this requirement, and which can be accomodated by something simpler
• how likely is it for a developer to accidentally retain representatives, nullifying the memory benefit of keeping their data in secondary storage?
• how tempting is it to perform identity comparison between representatives? We need to come up with a policy for liveslots to manage the identifier-to-representative tables (remember-forever, 100-entry LRU cache, remember-never), which will be visible to user-space vat code by performing identity comparison between newly-delivered representatives and older ones which were retained (against advice) within the vat. There may be speed benefits (and RAM-consumption drawbacks) to having liveslots cache these for longer periods of time. Vat code must know whether it is safe to use identity comparison or not, which will depend upon what sorts of guarantees liveslots is able to make.
• what do we want the me/other object to be? We think it needs to be the representative itself, to facilitate the targetPurse.deposit(otherPurse) pattern (which uses rights-amplification to access the internals of otherPurse), but we could use experience with it. @FUDCo described it as a "new flavor of Presence", which I quite like.

[katelynsills]

Ah, I would have really liked to be in this meeting to learn more about what might be happening to ERTP in the future!

[katelynsills]

Design plans as of 2/23:

issuer.js has the following main objects:

• issuer (one per brand, identity comparison used often by other users)
• brand (one per brand, obviously, identity comparison used often by other users)
• mint (one per brand, identity comparison not used by by other users).
• depositFacet (not in use, could be deleted).
• purse (many per brand, identity comparison not used by other users)
• payment (many per brand, identity comparison not used by other users)

It looks like purses and payments are good candidates for virtual objects, and that they should both use makeWeakStore from the vat secondary storage system which allows for virtual objects as keys.

Plan

1. Start with a PR that just makes payments virtual objects, and uses the virtual objects form of makeWeakStore. Check the implementation to ensure it's clean, that tests pass, and that we are not depending on the identity of payment representatives anywhere in the our code base.
2. Do the same thing for purses, potentially deleting depositFacet as it might complicate matters and we do not use it anywhere anymore.
3. Coordinate with the amountMath refactoring that should simplify issuer.js. There may be major simplifications that can be made that improve the readability and POLA enforcement of issuer.js.

[katelynsills]

Payments are now virtual objects as of #2526.

[dckc]

...

2. Do the same thing for purses, potentially deleting depositFacet as it might complicate matters and we do not use it anywhere anymore.

We don't use depositFacet? Isn't that what we use for contacts in the wallet? i.e. my board id goes to a deposit facet? Or is that a different kind of deposit facet?

I suppose I should be able to figure this out by reading some code... but last time I tried, I got as far as depositFacet and thought I had found the answer.

[katelynsills]

We don't use depositFacet?

The wallet has its own version of a depositFacet per brand rather than per purse. This depositFacet is not used in the wallet.

[katelynsills]

Is making purses virtual objects in Beta?

[katelynsills]

See #2841 for the next step, making purses virtual objects. This is needed by the stress test phase.