Provide PSM chainStorage data to Bulldozer bootstrap #7156
Comments
dckc
added
enhancement
|
The data we're talking about is pretty limited:
In today's kernel meeting, we agreed:
@mhofman will mostly be doing the launch-chain.js side (this ticket), and @dckc will mostly be doing the vat-bootstrap side (#6645). This will result in some specialized knowledge living in an unusual place. The particular set of IAVL keys that hold the PSM/wallet data is a function of the behavior of the pismo-era vats, and the IAVL root key that chain-storage starts from (I think it starts with The alternative, which we rejected, would be for the PSM/smart-wallet vats to get chain-storage read access, whereupon at first launch they could query for data written by their predecessor, and then populate their initial (durable) tables from the results. That would separate the concerns better (new PSM vat is solely responsible for recovering state from the old PSM vat), but would require chain-storage reads, which we believe would interfere with our plans to parallelize vat execution. Basically if a vat can ever read (synchronously) from a device, the worker hosting that vat would have to stop its execution, send a read request to the kernel, and wait for its response before it could continue execution. The kernel would receive that read request at a time that is uncoordinated with other activity, which looks like a timing race, and a threat to deterministic execution. The parallel execution design will be a lot simpler if we don't have to accomodate this case, and stick to only doing device writes (which can be safely deferred until the end of the vat delivery). |
|
To avoid too much (any) economy logic in cosmic-swingset, it would be preferable for the config to list the keys/path that need to be read/exported and included in the bootstrap args. @dckc do we have an idea of the kind of vstorage read operations we need? read specific paths? export a whole subtree? dump a list of children and/or entries? |
|
If the swingset config can specify a list of roots ( |
|
I would imagine that an export of those subtrees will be more data than we need. Also from what I recall the "history" is an application concern since it's an append to the same vstorage paths, so you would indeed get the history. Maybe we should look at an export of these subtrees and see what we can do from it. |
mhofman
changed the title
|
assigning to @gibson042 who volunteered for this in a chat thread |
|
cc @FUDCo |
|
FYI: I started prototyping by grabbing data straight off mainnet: agoric-sdk/packages/inter-protocol/test/psm/test-psm.js Lines 712 to 723 in 1ff8891 |
|
@dckc I'm also planning to use that shape (an array of [key: string, value: string] entries). But you do need a full subtree, right? |
Yes; in particular, for I'm not sure whether I need |
What is the Problem Being Solved?
In order to, for example, restore PSM state from chainStorage (#6645), the post-bulldozer VM has to somehow access the pre-bulldozer chainStorage state such as the list of PSM assets.
Description of the Design
???
Options include:
getValue()method to the JS chainStorage APISecurity Considerations
Scaling Considerations
Test Plan
The text was updated successfully, but these errors were encountered: