orchestration - ICA Controller - Account - vstorage logging

ivanlei commented 6 months ago

What is the Problem Being Solved?

https://github.com/Agoric/agoric-sdk/issues/9065 details the ability to send ICA commands over an ICA account object.

This enhances that capability by logging well-structured information to a subtree of the contract's storage node that allows for following TX progress and debugging. This universal logging brings uniformity to error handling, debuggability, & TX recovery.

Description of the Design

current draft:

each asyncFlow/orchestration has an ID, which is used as a root for vstorage records of progress
orchestration publishes to an associated subscription underneath that key the current interesting operation in progress and it’s info (e.g., what channel and txn ID at the IBC level?)
there is a record associating the async flow with the walletSpendAction
- in the case of continuing offers, that should tie the user’s action to the base object (eg.., the Portfolio)

Security Considerations

Scaling Considerations

Test Plan

Upgrade Considerations

rowgraus commented 5 months ago

Questions coming out of planning:

What actions should be automatically stored?
How do we want developers to specify additional information
What information do users require in order to track their own transaction
First user story

LuqiPan commented 4 months ago

From security's perspective, should we be worried about this being another factor that contributes to vstorage(hence disk) growth?

turadg commented 4 months ago

contributes to vstorage(hence disk) growth?

A concern, yes. It should not be exploitable because it's managed by the Orchestration API. The API can also delete old data so it doesn't persist in IAVL.

dtribble commented 4 months ago

contributes to vstorage(hence disk) growth?

A concern, yes. It should not be exploitable because it's managed by the Orchestration API. The API can also delete old data so it doesn't persist in IAVL.

Indeed that's a motivator for having system-provided txn logging with sufficient info for most purposes

dckc commented 3 months ago

each asyncFlow/orchestration has an ID, which is used as a root for vstorage records of progress

Is the id scoped to the contract? (in particular: to the orchestration facade?)

It's not supposed to be global, right?

dckc commented 3 months ago

there is a record associating the async flow with the walletSpendAction

It's straightforward to point from a wallet's vstorage to a key of the contract's choosing (using offerToPublicSubscriberPaths).

Going the other way doesn't seem feasible. We don't need to go the other way, do we?

0xpatrickdev commented 2 months ago

When an ICA message lands on another chain, or any cross-chain ibc message for that matter, the following transaction shows up: MsgRecvPacket

On MsgRecvPacket, we have Packet.

Notably, the primary way to filter transactions on a remote chain is by using the following fields:

// identifies the port on the sending chain.
string source_port = 2;
// identifies the channel end on the sending chain.
string source_channel = 3;
// identifies the port on the receiving chain.
string destination_port = 4;
// identifies the channel end on the receiving chain.
string destination_channel = 5;

This seems to suggest we want to make these values available in vstroage, in addition to the account address we are currently publishing.

0xpatrickdev commented 2 months ago

Until #9066, every interchain action has been triggered by a wallet offer. This meant that the actions taken by the LCA were clearly documented in published.wallet. For scenarios where external triggers initiate interchain transactions, it seems it would be helpful to log something this vstorage to figure out something happened. This might suggest we want do vstorage writes when tx's are completed (and initiated).

dckc commented 1 month ago

Until #9066, every interchain action has been triggered by a wallet offer. This meant that the actions taken by the LCA were clearly documented in published.wallet. ...

There's a pattern where, for example, the vaultFactory publishes info about vaults and the wallet points to those parts of vstorage by path. It's used in watchUserVaults in dapp-inter.

Likewise, the account / tx info could be canonically published by the contract, and the wallet could get a pointer.

0xpatrickdev commented 1 month ago

Notes from talking with @michaelfig -

it might be a good idea to post this information from vat-orchestration or vat-ibc on behalf of all consumers
we should consider using srcPortID + srcConnectionID for the key instead of ChainAddress.value
- the namespace we might consider is published.orchestration.ica
- for the interim, while we figure out the schema, we might want to call this published.orchestration.debug.ica. And we can delete the node when we are done
- we need to this about how to do this for LCA's, although only the address is relevant there
this information can change over time - specifically, if a channel is closed and reopened there will be a new channelID (portID, connectionID and ChainAddress should remain the same)

Agoric / agoric-sdk