Open michaelfig opened 1 year ago
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).
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.
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.
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
The tools can be command line, but likely we want explorers to be updated with support for lookup of tx outcome as well.
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
andmsgIdx
, 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