You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DEX had asked us to provide a CLI that given a chain-id, port-id, and channel-id we return the ChannelEnd, ConnectionEnd and AnyClientState on both ends. We should probably define a new struct to include the information such that it can be read easily.
Problem Definition
Currently the user needs to do ~6 queries to get this information.
Proposal
We can introduce a new query CLI, tentatively called query trace taking 3 parameters: a chain-id, port-id, and channel-id.
The most challenging part is how to assemble the output in a simple, meaningful way, given that there are multiple queries that this will involve, as follows:
hermes query channel end chain-id port-id channel-id
extract from the result the connection hop identifier, for example connection-id
also extract the counterparty channel/port, counterparty-port-id and counterparty-channel-id
hermes query connection end chain-id connection-id
extract the client identifier of the underlying client, for example client-id
extract also the counterparty client identifier, counterparty-client-id
extract also the counterparty conn identifier, counterparty-connection-id
hermes query client state chain-id client-id
extract the chain identifier from the client state, counterparty-chain-id
now we have the full trace information on the side of chain-id
proceed to fetch the trace information from the counterparty side
hermes query client state counterparty-chain-id counterparty-client-id
hermes query connection end counterparty-chain-id counterparty-connection-id
hermes query channel end counterparty-chain-id counterparty-port-id counterparty-channel-id
It probably makes sense to have two modes for the output:
default: Hermes outputs the whole structure of every field (not only the identifiers) for instance:
@adizere pointed out that Dex wanted to filter also on destination chain, in other words show channels between two chains.
Could we extend then the existing query channels CLI to look something like: query channels <chain-id> [--other-chain <other-chain-id>] [--verbose]
For this one, can we maybe incorporate in query channel? Maybe query channel ends <chain-id> <port-id> <channel-id> [--trace]. Note ends (will show both ends of the channel) vs end.
Crate
relayer, relayer-cli
Summary
DEX had asked us to provide a CLI that given a
chain-id
,port-id
, andchannel-id
we return theChannelEnd
,ConnectionEnd
andAnyClientState
on both ends. We should probably define a new struct to include the information such that it can be read easily.Problem Definition
Currently the user needs to do ~6 queries to get this information.
Proposal
We can introduce a new query CLI, tentatively called
query trace
taking 3 parameters: achain-id
,port-id
, andchannel-id
.The most challenging part is how to assemble the output in a simple, meaningful way, given that there are multiple queries that this will involve, as follows:
hermes query channel end chain-id port-id channel-id
connection-id
counterparty-port-id
andcounterparty-channel-id
hermes query connection end chain-id connection-id
client-id
counterparty-client-id
counterparty-connection-id
hermes query client state chain-id client-id
counterparty-chain-id
chain-id
hermes query client state counterparty-chain-id counterparty-client-id
hermes query connection end counterparty-chain-id counterparty-connection-id
hermes query channel end counterparty-chain-id counterparty-port-id counterparty-channel-id
It probably makes sense to have two modes for the output:
Acceptance Criteria
Get full channel information from both chains with a single CLI.
hermes query trace CHAIN-ID PORT-ID CHANNEL-ID [-s/--summary]
For Admin Use
The text was updated successfully, but these errors were encountered: