node icon indicating copy to clipboard operation
node copied to clipboard

Support CCTX with Cosmos chains with IBC

Open lumtis opened this issue 1 year ago • 2 comments

### Tasks
- [ ] https://github.com/zeta-chain/node/issues/1510
- [ ] https://github.com/zeta-chain/node/issues/2128
- [ ] https://github.com/zeta-chain/node/issues/2129
- [ ] https://github.com/zeta-chain/node/issues/2573
- [ ] https://github.com/zeta-chain/node/issues/2436
- [ ] https://github.com/zeta-chain/node/issues/2130
- [ ] https://github.com/zeta-chain/node/issues/2131
- [ ] https://github.com/zeta-chain/node/issues/2132
- [ ] https://github.com/zeta-chain/node/issues/2163
- [ ] https://github.com/zeta-chain/node/issues/2166
- [ ] https://github.com/zeta-chain/node/issues/2253

This feature would heavily depend on completing better modularity for the chain: https://github.com/zeta-chain/node/issues/1711 Right now, cross-chain functionality relies on a strong coupling between observer and crosschain modules, this would require to be able to use the crosschain module without depending on observer

Depends also on https://github.com/zeta-chain/node/issues/1510

Is your feature request related to a problem? Please describe.

A simple way to support crosschain txs with an external chain without deploying a smart contract architecture is to use the memo field generally available in txs in blockchains to add data for a smart contract call on ZetaChain, it is the way we currently support interoperability with Bitcoin.

IBC transfers in Cosmos with the transfer module include this memo field. This can be leveraged to easily support crosschain interactions for omni-chain smart contracts with ZetaChain.

There is already a task for integrating IBC transfer in the blockchain: https://github.com/zeta-chain/node/issues/1510 This would allow directly transferring tokens between ZetaChain and Cosmos chains.

This feature is about an extension, a module built on top of it, to allow the IBC transfer module to interact with omni-chain smart contracts and create CCTXs.

The biggest advantage of the solution is that with IBC we already have a native way to validate transactions on external chains, and send transfers on external chains, the integration can be done without integrating with the TSS, the observer set, which heavily reduces the complexity for the integration and heavily reduces vectors for bugs (most of the issues we encounter are related to missed observation and long pending transactions, which would be directly managed by the IBC protocol here)

Describe the solution you'd like

The solution would implies creating a new module that interact with the transfer module to process inbounds, and send outbounds.

Let's call this module cosmosbridge

The solution can be straightforward:

  • cosmosbridge has a module account
  • it watches for IBC transfer to be sent to its address (with hook)
  • upon reception of a transfer, if the chain is supported (represented with channel ID), it create a new CCTX with an inbound automatically observed. It processes the inbound with the same logic as for BTC deposit, using the memo for a normal deposit or a smart contract call, this part would be handled in the crosschain module with a common logic
  • the crosschain module already watches for withdraw events to create new outbound. If there is a withdraw events related to a Cosmos chain, instead of having a new pending outbound that would be processed by the observer set, the crosschain module call a function in the cosmosbridge module to transfer back the ZRC20 Cosmos token to the withdraw address with the IBC transfer module
  • the acknowledgment hook of IBC is used to confirm the outbound once the transfer is processed. Revert and timeout hooks are used to process what we currently have as reverted outbounds.

-> some dispatching logic would be necessary in the crosschain would be necessary to perform different logic during outbound creation depending on the type of chain (there would be no pending outbound object, nonce, etc required in this case here)

deposit withdraw

Motivation and Context

  • Not relying on the observer set and TSS makes integration and operations much easier than any other chain type
  • The functionality can be used with any Cosmos chain with IBC enabled which open for a big and growing ecosystem:
    • Cosmos Hub
    • Celestia
    • Injective
    • Stride
    • Osmosis
    • DyDx

References ibc transfer: https://tutorials.cosmos.network/academy/3-ibc/7-token-transfer.html chains supporting IBC: https://mapofzones.com/home?columnKey=ibcVolume&period=24h

lumtis avatar Feb 16 '24 09:02 lumtis

so essentially the cosmosbridge module address acts similar to the TSS address in terms of interacting with other chains (inbound and outbound)?

brewmaster012 avatar Feb 18 '24 19:02 brewmaster012

so essentially the cosmosbridge module address acts similar to the TSS address in terms of interacting with other chains (inbound and outbound)?

From the external chain, in some way yes. This is the address the funds would be sent to, and received from when doing cross-chain transaction. This address could also actually be the Cosmos format address of the TSS instead of the module account if we want to keep some consistency (although I don't think it would be a good idea since then TSS has ownership of the funds and we add an unnecessary attack vector)

It is different on the technical side since the txs would be automatically observed and IBC relayers would sign transactions between chains instead of the observer set.

lumtis avatar Feb 19 '24 15:02 lumtis