Report swingset actions result for client tools to get cosmos tx outcome

[michaelfig]

What is the Problem Being Solved?

Promise rejections or fulfilments for bridge actions are not exposed to the user of the chain.

Description of the Design

When the bridge handler’s return promise fulfills/rejects we should publish a Cosmos event indexed by txHash and msgIdx, so that off-chain clients (like the wallet UI) have a way to query an RPC node for historical settlements or watch for future ones.

Security Considerations

Scaling Considerations

Test Plan

[mhofman]

See #7102 which will plumb the txHash and msgIdx from cosmos to cosmic-swingset.

Right now a bridge delivery that cosmic-swingset performs has no return path (as it's implemented using swingset devices) but a specific mechanism could be introduced, or the context could be sent into vat-bridge alongside the action, and vat-bridge would publish the result itself. Either case this would be bridge specific logic, the question is mostly which side of the bridge triggers publishing (vat or cosmic-swingset).

[mhofman]

Bridge actions may not be the only actions that submitters are interested in. For example publish bundles are in need of a similar tracking mechanism.

[mhofman]

After chatting with @michaelfig, my understanding is that we want to leverage cosmos Events for this mechanism which avoid the storage cost of keeping historical results in storage. However cosmos Events are not in consensus, and that's what "append" vstorage nodes with notifications are meant to solve.

The strawman would be to have 2 vstorage nodes, e.g. swingsetActionStart and swingetActionResult, which are written to with "append" mode from cosmic-swingset. This generates change events for which the client can subscribe to.

@michaelfig also notes:

If we exposed a mechanism via chainStorage that also allowed attaching arbitrary event key/values to the state change event, we could use them for efficient subscription.

I assume we'd want things like the txHash to be an event attribute so that clients can filter the event stream accordingly (I don't know how this works). It strikes me we may want to work with block explorers to support and index these events and show this information attached to Transaction details.

The result value would be message specific, but in some cases like wallet actions, it may make sense to reference a vstorage node containing more details about the wallet action result.

[mhofman]

Note that the bridge mechanism that reports errors to cosmic-swingset should be durable to that a transaction spanning an upgrade of the vat where the bridge handler lives will still get its status reported correctly

[mhofman]

8441 discusses the bridge reporting side.

The tools can be command line, but likely we want explorers to be updated with support for lookup of tx outcome as well.