Make vatstore optionally available to vats as a vat power #3304
Conversation
There was a problem hiding this comment.
Implementation looks good, modulo the recommended comments and test addition.
I'm tempted to suggest you remove the enable/disable switch, since it's a fairly big delta compared to the small (in my perspective, qv #3292 comments) need. It's a bummer that the process of adding vat options takes so much effort (those keys are carried through so many files before they make it to liveslots). But I'll leave that decision up to you.
| send('get', 'foo'); | ||
| send('get', 'zot'); | ||
| await c.run(); | ||
|
|
There was a problem hiding this comment.
Let's add another check here, peek into the kvStore and confirm the surviving foo key is being stored with the userspace-specific prefix, not something which could possibly overlap with e.g. the virtual object manager's keyspace.
| @@ -916,6 +918,23 @@ function build( | |||
| if (enableDisavow) { | |||
| vpow.disavow = disavow; | |||
| } | |||
| if (enableVatstore) { | |||
| vpow.vatstore = harden({ | |||
There was a problem hiding this comment.
let's add a comment here to describe how the vat's keyspace is carved up, and what code is responsible:
- userspace
vatstore:vvs.${userKey} - VOM
makeWeakStore:ws${storeID}.${vobjID}(virtualObjectManager.js / makeWeakStore / virtualObjectKey) - VOM virtual objects:
o+${kindID}/${instanceID}(virtualObjectManager.js / makeKind / makeNewInstance)
Or, put this comment up at the top of liveslots.js, and add pointers to it from the three places that currently compete for keyspace.
My biggest concern is that we might accidentally add a new feature in the future, and the implementor doesn't realize the importance of keeping the keyspaces distinct, and we wind up with a breach enabled by userspace intentionally colliding with the keyspace of something more powerful.
There was a problem hiding this comment.
I'd feel slightly better if the virtual object manager used vom. in front of everything it manages (so vom.ws${storeID}.${vobjID} and vom.o+${kindID}/${instanceID}). On one hand, that feels overkill because those three keyspaces are already obviously non-overlapping. On the other hand, then a third feature can just choose a different prefix (foo.) instead of also needing to worry about how the VOM might change in the future and consume more of the keyspace.
FUDCo
force-pushed
the
3292-reify-vatstore-as-a-vat-power
branch
from
29d11b9 to
229da78
Compare
|
Closes #3292 |
Implements #3292