[PROPOSAL #56][ACCEPTED] ⚛️ Add IBC Router to Hub ⚛️ Discussion

Hub Proposals Signaling/Text
1
  • Moderator edit to add link to on-chain proposal: Mintscan

Submitted to the Cosmos Hub Governance on 2021-09-07 16:45 UTC

Voting Started on 2021-09-07 16:45 UTC

Voting ends on 2021-09-21 16:45 UTC

The Hub has long been envisioned as a central point in the IBC architecture. In the battle to build and ship IBC this central vision has remained unchanged, but with so much focus on the need to build out other zones with real economies to support this network (the CosmosSDK is the result of this effort), the idea of the hub as an Interchain Router hasn’t been discussed in a serious context for quite a while.

This is understandable: Cosmos needed so many other pieces to come together before the Hub had a chance to even start performing this function. Those other zones have been created, they each have products and economies. The bootstrapping era of IBC is well underway.

These new zones joining are noticing a problem: they need to maintain a large amount of infrastructure (archive nodes and relayers for each counterparty chain) to connect with all the chains in the ecosystem, a number that is continuing to increase quickly.

Luckly this problem has been anticipated and IBC architected to accomodate multi-hop transactions. However, a packet forwarding/routing feature was not in the initial IBC release. This proposal aims to fix this for the Hub.

This is a proposal to include a new feature to IBC on the Hub that allows for multi-hop packet routing for ICS20 transfers. By appending an intermediate address, and the port/channel identifiers for the final destination, clients will be able to outline more than one transfer at a time.

Strangelove Ventures has delivered an [IBC Middleware module](https: //github.com/cosmos/ibc-go/pull/373) that will allow the hub to play the role of IBC Router that was always envisioned for it. Passing of this propsal will begin the era of the Hub offering interchain services to other chains and profiting from those relationships.

To pay the hub validators and stakers, this proposal implements a governance configurable fee (which we propose should be initially set to 0.0 to encourage adoption) that will be taken out of each packet and given to the community pool. The community pool will then periodically trade these fees for ATOM and distribute them to staked holders. The exact distribution method of these fees is left TBD in this proposal as it is not initially required and can be implemented in a future governance proposal. One way to do this would be using the [Groups module](https: //docs.cosmos.network/master/architecture/adr-042-group-module.html), Community spend proposals and the Gravity DEX.

A vote YES on this proposal indicates that this feature should be included in the next hub upgrade. We (as the Hub) believe that time is critical right now and we cannot wait to begin providing this service to other chains. A NO vote indicates that this shouldn’t be included in the next upgrade.

[Full Proposal text and additional links available here](https://github.com/strangelove-ventures/governance/blob/master/proposals/2021-09-hub-ibc-router/README.md

This proposal went onto the hub before being posted on the forum which is not typical for the lifecycle of a proposal. The forum has been the go to place for public discussion of proposals so that ATOM holders can make informed decisions in governance. In private telegrams and discords the topic has been debated thoroughly by various Cosmos core contributors. It has a number of varied opinions that should be more visible to the public discourse.

I encourage active and civil discourse here, we all want the same thing: a successful Cosmos Hub. Pasting external conversations that have been confirmed OK to reproduce by those involved is also encouraged.

1 Like
2

The following comment is mine but re-posted from the UX Working Group Telegram chat, one of the places discussion has taken place so far. I’d like to encourage responses to the comment here as well as further copy-pasting of prior discussions.

It’s unconventional for an external contribution (although of course jack is hardly external) to go to the hub without thorough review from members of the SDK team and/or IBC. I would also like to see the hub pick up pace and I appreciate Jack’s attitude of just getting shit done. I think that the biggest thing I currently have a problem with about the proposal is that it isn’t / hasn’t been present on a public forum for this kind of discussion to take place. Validators don’t have time to follow every chat even if they’re present. Delegator voters are certainly not present in most of the places discussion has taken place. For them to be expected to evaluate whether it’s a good idea to vote or not there should be a public place where team members who have the most context on this kind of work can discuss the benefits, drawbacks and risks of an implementation of a feature like this. The other large issue is that shipping code isn’t a one time thing. Nothing in the proposal discusses who will maintain this code or where it will live. It’s an unanswered question in my mind, I know that the IBC team is over capacity with an ambitious roadmap, the gaia team is almost completely new hires and the SDK team has little to no IBC experience as well as being over capacity in almost every way.

If the hub votes to put this on the hub it’s my job to do so, but it doesn’t feel like the public is informed about the fact that it hasn’t gone through the same process code usually does (albeit our process is slow and as ethan and jack have pointed out makes it feel impossible sometimes to get anything through) or about who will be maintaining the code and how they’ll be supported to do so.

In terms of actual product value, I think the solution strikes a nice balance for a minimum viable version of multi-hop that might allow us to test product market fit that could justify further development of hub as a router features like the full implementation of multi-hop. However this feature also doesn’t live in a vaccuum. It has to be adopted by all the wallets that people use for it to work at all. Emeris already has something like the client side only version of multi-hop and Keplr looks for user demand in prioritizing their feature list. Even if this gets onto the hub how will we ensure it is even used? Relayers don’t create outgoing packets for users, it starts with the interface. If anything this is a feature request from relayers to wallets. The client only version of the feature will likely cause more work for wallets than the IBC middleware solution, but that’s not even a confirmed fact and as far as I know no wallet has committed to supporting this feature in any way.

1 Like
3

Voting yes. Seems like a very needed and great feature to add the hub. As for the fee, I generally think it is better to have a few now than implement one later on when people are used to paying nothing for ibc routing. Not really sure how much this fee should be, but probably best to keep it very minimal.