wire RPC publishing nodes into bootstrap/run-protocol code

[warner]

What is the Problem Being Solved?

@gibson042 's finished with the task of creating "RPC publishing nodes": an object which represents the authority to:

• 1: publish data to the chain's persistent+hashed storage, where it can be queried using a non-transactional RPC query at some particular hierarchical path string
  • (and updates to that data appear in the block Results log)
• 2: create a new publishing node whose path string is an extension of the original

These publishing nodes also have a method which reveals their path string, so if A chooses a child name and creates a new publishing node for B, A can hand just the publishing node to B, it doesn't also need to tell B what path was chosen.

The bootstrap code (packages/vats/) creates the "root publishing node", which has the shortest RPC query path possible (maybe /swingset/publish or something: it lives in the same namespace as all other cosmos-sdk modules).

The question is how to disseminate this publishing authority to the smart wallet and the core economy contracts.

We agreed this morning to avoid human-meaningful names if we possibly can. We also agreed that it would be good to be able to change the mapping in the future, e.g. if the smart wallet initially uses a path with /42/, we might need to replace that contract with a new one (which could receive a prefix of /43/), and clients need a way to discover the new path.

We agreed to defer having Zoe be involved in the process. Instead, whoever creates each contract should acquire a publishing node first, then pass it to the new contract instance via privateArgs. Maybe in the MN-2/3 timeframe we could make this more automatic, but we don't need it in MN-1.

Description of the Design

The plan we sketched out calls for the bootstrap code to use the root publishing node to publish a table of name-to-path mappings. In particular the data it publishes (and updates via the Notifier protocol) is a JSON-encoded object which has one particular key whose value is a mapping from names to paths.

The bootstrap code has a function that manages a counter, and will create new numbered child nodes upon request. Perhaps createChildNode(name) -> node. The name is used to update the mapping.

The code that launches the RUN protocol needs access to this function. It will create new nodes for the contracts it creates, and pass them to privateArgs.

The new contracts will take those publishing nodes and use them to publish whatever they need.

The smart wallet will use its node to creates a bunch of address-keyed child nodes, one per client, under which it can publish data about the particular wallet account.

Security Considerations

In the (far?) future, we hope to regain some measure of confidentiality from an otherwise entirely transparent chain, through the use of zkSNARKs or MPC or something. In that world, publishing data through one of these publishing nodes should not automatically make it visible to the entire world. We can model that now, without the fancy math, by treating the publishing path as a secret. For now the path is just a couple of small integers, trivially enumerable (and generated by a transparent/replicated chain). But in the future the path could contain a decryption key, such that the ciphertext is visible to the world, but the key necessary to decrypt it is only available by asking the original notifier. The upshot is that as long as we pretend the publishing path string is secret, and recognize that e.g. publishing a list of them in a parent node is equivalent to broadcasting the read authority, we should still have a sound foundation to reason about confidentiality in the future.

Off-chain clients should have a clear and reliable pathway to learn the publishing path of the information they care about. Third parties might make claims about path /x/y/z being the correct location of e.g. BLD/RUN AMM price information, but they might be lying, so to the extent that certain contracts are the "right" source for a given value, clients should be able to make queries or (if really necessary) object messages to get to the corresponding publishing nodes.

Test Plan

unit tests in packages/vats/, probably a bunch of manual integration tests too

[dckc]

Thinking about this from the perspective of users / features, getting a quote from the AMM seemed like a place to start. The AMM, like all Inter protocol contracts, uses brands. Going back to Jan 21 discussion #3756 (comment) :

The contract's responsibility should end with a publically-visible Notifier, that it updates after each trade.

That discussion includes:

We'll add an instance of marshal to the on-chain wallet, parameterized with a convertValToSlot() that translates Presences into a new woNNN slot type.

and some discussion of using the board for public objects.

But I'm struggling to see how that could work: publishing to the board, like all cross-vat stuff, is async, but convertValToSlot has to be synchronous, no? @michaelfig do you see a way to reconcile them?

I'm afraid this still needs-design.

[michaelfig]

But I'm struggling to see how that could work: publishing to the board, like all cross-vat stuff, is async, but convertValToSlot has to be synchronous, no? @michaelfig do you see a way to reconcile them?

Yes, run marshal once to extract the unmapped presences, asynchronously resolve them to identities resulting in updates to the map, then run marshal again to substitute the mapped ids into the results.

I'm afraid this still needs-design.

I play fast and loose with designs, since I often need to prototype a sketchy design to see for myself if it is workable. I see a way forward, and it's just details now AFAICT, so I'm estimating this as a 3, and removing needs-design.

[michaelfig]

Details wrt the design of the userland publisher/subscriber API are being hashed out in #4331.

[dckc]

I play fast and loose with designs, since I often need to prototype a sketchy design to see for myself if it is workable.

Sure, that's fine. I'm still not to the point where I can see how to prototype something. I'll stand by to see what you come up with, OK?

Yes, run marshal [twice]... asynchronously...

I struggle to see how that achieves "The contract's responsibility should end with a publically-visible Notifier, that it updates after each trade." I look forward to a prototype.

[michaelfig]

I struggle to see how that achieves "The contract's responsibility should end with a publically-visible Notifier, that it updates after each trade."

I don't see how that's even possible without deep kernel wiring. I don't think the plumbing is onerous, though.

[dckc]

history for clients that are offline for a bit is high on @michaelfig 's list

[dckc]

@gibson042 's finished with the task of creating "RPC publishing nodes"

Does that mean #4558 should be closed? Or is there some other issue for that work?

[michaelfig]

@gibson042 's finished with the task of creating "RPC publishing nodes"

Does that mean #4558 should be closed? Or is there some other issue for that work?

The PR is mostly complete, but not landed yet. @gibson042 can you add a "closes" line to the relevant PR to close #4558?

[dckc]

@turadg , we (@michaelfig and I) broke ground on how to do this in #5400 (now merged): we wired up the AMM top-level .getMetrics() call: e678969efe8e60c9a

[dckc]

To support Risk Management ETL, the vault factory should organize all the vault notifiers under one storageNode. (@dtribble and I just discussed this.)

this ticket should perhaps split into several... or we should perhaps re-open tickets such as #4649 and restore their scope to include RPC.

[dckc]

@warner @michaelfig regarding...

The plan we sketched out calls for the bootstrap code to use the root publishing node to publish a table of name-to-path mappings.

What was the purpose of that level of indirection? We didn't include anything like that in #5400 nor #5613 ; is that OK?

[turadg]

Closing as done enough for MN-1.
Rest is deferred to #5687