search

cosmos / ibc-go

Inter-Blockchain Communication Protocol (IBC) implementation in Golang.
https://ibc.cosmos.network/
MIT License
547 stars 579 forks source link

Write tests for different sdk.Messages (TrySendTx) #510

Closed seantking closed 2 years ago

seantking commented 2 years ago

Summary

At present, we are only testing if bank msg send can be executed as part of the TrySendTx flow. See here.

At a minimum, we should write unit tests that cover the execution of all the SDK messages required as part of our initial user stories/use cases.

Required messages (likely to be updated):

For Admin Use

seantking commented 2 years ago

@charleenfei can you share the user stories once you have written them (happy to help with this). We need to ensure that the teams planning to use this at launch are covered (what SDK messages are they planning to execute?).

seantking commented 2 years ago

@colin-axner Am I correct in assuming that some of these tests will eventually need to live outside of the ibc-go repo. If say we want to test the groups module, or liquidity pools (likely something that we should test for) we'll need to do this in the interchain-accounts repo I suppose.

charleenfei commented 2 years ago

@charleenfei can you share the user stories once you have written them (happy to help with this). We need to ensure that the teams planning to use this at launch are covered (what SDK messages are they planning to execute?).

I still need to follow up directly with these teams to get a latest update on these stories, but as it is so far, a sample first three:

Injective X Band Chain Currently, Injective sends an IBC tx to Band Chain via their custom IBC oracle module, which is a data request. When this IBC packet is executed on Band Chain, validators on Band Chain fetch prices for 10 different markets. A random selection of validators will post this selection on-chain. Once a minimum quorum has been reached, an IBC packet is sent to Injective. The roundtrip latency of this flow is around 30 sec when things go well (no packet timeouts or delays in validation). However, Injective wants to minimise as much as possible the latency between real world price updates and price updates on Injective. They can simplify this two transaction flow to a single transaction using interchain accounts, in a use case where Injective opens an interchain account on Band Chain which would be able to pay for a continuous set of update transactions and maintain a standing request for the prices of markets, which would simplify the transaction flow to a single transaction, and introduce a simple flow to update the standing request if necessary.

Umee X Hub Users on Hub would send their ATOM to Umee. In return, the user gets equivalent amount of Mi (sp?) tokens (token would be a form of liquid staking token), which could then be staked on the Hub, in some other liquidity pool, etc, in addition to other business logic which Umee could perform on behalf of the users in return for the ATOM.

Umee then stakes these ATOM tokens on the Hub on behalf of Umee (ATOMs get inflation rewards, etc). Without ICA, Umee would have to use validator controlled multisig, because for this flow Umee needs an account on the Hub which can be controlled externally in a decentralised way. This ICA registered on the Hub would then receive the staking rewards for the ATOM, figure out distribution back to Umee chain, and send back to the corresponding existing account on Umee.

Hub Custodial Services The problem the cosmos ecosystem faces is fragmentation of services. A new chain goes live, they need to talk to custodial solutions and exchanges to integrate. Many exchanges and custodial solutions don't want to integrate 10s of chains unless paid in advance.

An alternative is offering the custodial service through the Hub. When a new chain goes live, through IBC the tokens are transferred to the Hub and custodial services can use the tokens from X chain that have been passed through the Hub. This means that the custodial service would just have to integrate with one chain, rather with X.

Using ICA, a service could be built in which a user sends tokens to an interchain account address on chain X, which corresponds to the registered ICA account of chain X on the Hub. This account would handle the token transfer to the Hub and then further on to the custodial wallet.

colin-axner commented 2 years ago

@colin-axner Am I correct in assuming that some of these tests will eventually need to live outside of the ibc-go repo. If say we want to test the groups module, or liquidity pools (likely something that we should test for) we'll need to do this in the interchain-accounts repo I suppose.

I'm ok with using messages from the SDK, but we don't want to be dependent on other SDK modules (otherwise updating SDK versions will become difficult). Based on how the code is structured, I'm not too worried on testing all messages. Testing that the messages are executed and perform expected functionality is something that can live at the integration test level above the relayers