Expose some Swingset state through cosmos RPC

[mhofman]

What is the Problem Being Solved?

We may want to expose some swingset state to cosmos RPC queries, such as:

• Check if a bundle is installed
• get a list of vat, their name and incarnation number (or some way to look up a specific vat details)

Regardless of the way swingset stores this information, we would commit to supporting these queries with specific cosmos proto messages.

Description of the Design

These queries would have to be processed without affecting consensus, and probably without being affected by in progress execution. A possible safe approach there may be to open a separate swing-store connection which starts a read only transaction, but swing-store is not currently architectured to handle a "read-only" mode.

Then there is the question of integration with golang cosmos. Currently there are 3 categories of messages sent over the golang-js bridge:

• Init message, which is a hybrid message that is not in consensus (on restart), but contains consensus affecting data (during restarts due to upgrade)
• snapshot related messages which are not in consensus, and routed to a sub process opening its own swing-store read-only connection for exports
• everything else, which is a consensus affecting message (block related messages, and bridge responses)

While it might be easier to funnel everything over the same connection for now, once we have split brains (#5287), we might be able to manage separate connections for this. A secondary process could be used to service all RPC queries.

Security Considerations

Make sure queries cannot affect consensus operations

Scaling Considerations

If a separate process opens its own connection and to service read queries, how should it handle transactions. Multiple DB reads without a transaction risk reading inconsistent data if a commit happens in the middle of 2 reads. Swing-store should manage the transaction, but creating a separate swing-store instance per query might be too much overhead (a swing-store instance requires its own DB connection).

Test Plan

Likely multi-layered:

• unit test of whatever swing-store changes are necessary
• functional test of the JS query interface
• unit/functional test of the cosmos swingset queries (mocking the JS side, especially once we have split brains)
• end to end integration test, possibly use in a3p-intergration since querying vat status is a common operation

Upgrade Considerations

None particular besides requiring new chain software.

[mhofman]

@Chris-Hibbert mentions that knowing which bundle is used by a vat would be valuable. The problem with that question is that Swingset only directly knows about the "root" bundle, which is the ZCF bundle for Zoe contract vats, not the contract bundle loaded by zcf itself. Maybe we could list which bundles are included in the args of the vat? But I'm not sure that covers all use cases (e.g. the contract kept a bundle from a previous incarnation and stored it in baggage?)

[Chris-Hibbert]

Zoe tracks the contractBundleCap used for each contract, and updates it on upgrade. The initial bundeId for the contract gets baked into the vat name for each contract, but there's no visible tracking when the contract gets upgraded. I suppose Zoe could write these to vstorage, but Zoe doesn't currently talk to vstorage.

The committee contract remembers the bundleId for the voteCounter it will use.