New blogpost by Jessica Tallon over on the Spritely Project blog:
Jessica and I talked about this at Friam recently, but basically this is
a demonstration of a simple ocap bank design which Jessica came up with
on *week two* on the job being fulltime on Spritely stuff.
Jessica was challenging me whether or not synchronous operations were
really ever needed in the vat design. I was explaining her the
traditional ocap mint example from the Ode paper and saying "this is why
we need synchronous operations", and Jessica said "I don't think that's
true", and proceeded to explain the above approach.
I walked dazed down to lunch. Morgan (my spouse) and I were supposed to
be having a conversation but I was so overwhelmed trying to find a hole
in Jessica's design that I was unable to talk and Morgan said "okay,
just go upstairs and write an implementation because you've clearly been
made useless by this idea until you have it written down." Both Jessica
and I wrote implementations; they're mostly the same, but mine shows up
in the blogpost because it was a bit more conventional to Spritely
Goblins' coding style.
The design is all Jessica's, I merely contributed the name. The
metaphor is a banker sitting on a wide beach with a ledger. The banker
has a meticulous eye and has written down the set of current valid
pebbles. When a payment is desired, Alice merely hands some pebbles to
Bob. Bob exchanges them with the banker who crosses off the old pebbles
(they're invalid) and hands Bob some new pebbles. Thus Alice has no
access to the old currency, so exclusivity is preserved. Something akin
to "purses" is still possible, but we call them "pouches", but they have
no essential role: they're just an object to store some pebbles and
cache their current accumulated value.
PS: Note that this takes an almost "peano arithmetic" approach; we use
the smallest denomination of the currency (akin to working entirely in
pennies) in the example with a set that shows all the current "valid
pebbles". However as Jessica notes in the post, we can provide
compression and have larger denominations: simply use a hashtable
mapping the valid pebble to its numerical value and when exchanging
permit giving the requested numerical change values.
PPS: I think I might have thoroughly broken MarkM for about two minutes
when explaining the above also based on him seeming to need to sit down
and his face seeming to scrunch into a temporary black hole as he
thought about it. But afterwards he said that the ocap mint approach
was one of the convincing examples for vats, and that Joule had an
example in its documentation, which I think is this (which I've tried to
understand previously, unsuccessfuly):
But the Joule example was more complicated and had bugs, so the swapping
idea being sufficient was the surprising thing.
PPPS: This doesn't mean that synchronous turns in vats are out of the
running now, though. I explained a problem I had run into in my
previous actor-MUD type sytems, where a player needed to move between
rooms and have an "official location" at any given time. Strange things
would happen if this was all done asynchronously: the departing room,
the player, and the entering room would often be out of sync with
conflicting beliefs as to where the player was. This was especially
risky with saving and restoring, and could lead to weird things if
attacking another player and a fireball hitting them in the back of the
head after they enter a separate room! Jessica agreed that this was
still a good example for vat synchrony... or at least, that she didn't
(yet) have a good counter-proposal...!