Cosmos Hub as an IBC Hub for the AEZ
I want to kick off a discussion about the Cosmos Hubs current identity crisis. That is, the Cosmos Hub is a Hub in name only. Even with ICS/AEZ. With the introduction of the AEZ I would’ve thought there would be considerable review and discussion of the Cosmos Hubs role as an “IBC Hub” within the AEZ. Currently, ICS chains can be onboarded using the Cosmos Hub as security, yet the consumer chains can connect to any chain via IBC (as normal). The Cosmos Hub gains very little from this, as consumer chains and other sovereign chains share the majority transaction fees. Cosmos Hub has long had the ability to be an “IBC Hub” with the introduction of the IBC Router in Proposal 56. I believe it is time for the Cosmos Hub to position itself as the IBC Hub for the AEZ. When onboarding, ICS chains should be required to connect ONLY to the Cosmos Hub (Permissioned IBC?) and route all traffic THROUGH the Cosmos Hub using the IBC Router. Sovereign chains will connect to the Cosmos Hub if they want to interact with a Consumer chain. This will ensure that the Cosmos hub receives its share of the fee revenue (another conversation is needed about current fee values - they’re far too low) from…
Excerpt (1198 of 1544 characters). Read the whole post on the forum ↗
Thanks for bringing this up @Rarma ! In principle, I think this is a good idea. I did try to push for this strategy when I was working at AiB in 2020, and I think it’s unfortunate that this wasn’t executed earlier (and still hasn’t). Because this is a topic I have had a lot of interest in, I do have a few concerns: • There needs to be an explicit devrels/owner of the Hub’s IBC services. • Maintaining an IBC hub is no easy task and the product ownership structure should be explicitly stated prior to this ‘requirement’ going live. For example, Osmosis spends significant amount of resources coordinating with relayers, talking to chains, monitoring liveness, developing tooling, creating registries, etc. This doesn’t exist for the hub. • Proper vetting of the product owner should happen, and funding should be allocated to ensure this is their full-time job (maybe via AADAO). I attribute most of why this didn’t happen in 2020 to this. • Tradeoff assessment of added latency vs overhead of each chains managing IBC connections need to happen. • What about for non-ICS20 IBC channels? (i.e. ICS-27, ICS-721, etc) What if the hub fails to adopt these new features at an…
Excerpt (1196 of 1465 characters). Read the whole post on the forum ↗
Generally speaking Cosmos technology needs to develop along 2 strategies: • Maximum decentralization of chains • Generating value for ATOM The two are closely related because it takes money to build common good services. In every society that is why you have taxes, bond sales and inflation seignorage - all of them are method to raise money to fund the creation of public goods. In the case of Cosmos, the public goods token is ATOM. ATOM is the tax that the interchain has to pay and in return get public goods in return. At present, a lot of public goods are delivered but no one is getting paid via ATOM appreciation. That circle of decline needs to be ended. Everybody needs to eat - including developers and investors. I don’t understand why people associate altruism with no monetary incentives. Money is allocation of resources. If you deprive things of money you want to kill them. Nothing can survive without proper economic incentive. Effort needs life energy and life energy doesn’t come out of nothing. People need to live and have to be able to pay their bills to work on Cosmos. Economic incentives are important and Cosmos teams need to do a signfiicantly better job on…
Excerpt (1193 of 2586 characters). Read the whole post on the forum ↗
I think this will be potentially harmful to the Hub as it is just one additional barrier to entry to joining the AEZ (in addition to increasingly draconian economic requirements to join as well as the general hub drama). I’m concerned it will push potential consumer chains away. When mesh becomes an option and is much more value - reciprocal, why go with replicated?
Though, i’m not strongly against it if there are consumer chains that want to opt in.
One, more important question. This will not work for existing consumer chains correct? Due to IBC path dependency requirements, consumer chains with existing liquidity on other chains (like stride and, to a lesser extent, neutron) wouldnt have that liquidity fungible with new liquidity transfers routed through the hub. An attempt to migrate liquidity would be nearly impossible and likely cause significant damage to those consumer chains’ TVL.
If that’s the case, i’d just ask that any proposal take this into account and not make this a retroactive requirement.
vixcontango: Cosmos Hub needs to be the default hub of all IBC traffic, the IBC fee has to be paid in ATOM I’m not totally sure that IBC fees were intended to be paid in atom. If you’d like to link to the white paper that your referencing I’m more than happy to check it out. RoboMcGobo: as it is just one additional barrier to entry to joining the AEZ I tend to agree with you. Also we would have to consider things like the existing IBC channels on neutron and stride… And even how to create channels on duality. Point blank, IBC channels are the stickiest asset in cosmos. I think there’s exactly zero chance of stride wanting to recreate all of its channels and in fact the onboarding procedure was mainly focused around ensuring that stride did not need to recreate all of its channels. dogemos: What about for non-ICS20 IBC channels? (i.e. ICS-27, ICS-721, etc) What if the hub fails to adopt these new features at an adequate speed where ICS chains feel they’re blocked by the hub? Yes, exactly this. I think that there’s also a serious question about latency, which you also mentioned in your post. The diagram is super logical and super…
Excerpt (1197 of 1526 characters). Read the whole post on the forum ↗
IBC traffic was supposed to go through the Cosmos Hub which uses ATOM for transactions. Payment in ATOM was not explicitly outlined but logically usage of the Cosmos Hub as IBC Hub should lead to usage of ATOM.
I also just realized that due to the path dependency issues i mentioned above, existing cosmos chains like umee that already have liquidity would not be able to onboard to ICS either (unless exempted from this requirement).
ICS would effectively only be open to new, untested chains which places additional risk on the hub in terms of ROI.
Man would i die to take that devrel role for IBC on the hub!
If we want Cosmos hub to be IBC router shouldn’t Cosmos then have latest version of ibc? Right now Cosmos has some version of 4.2.*. My question here how would this affect other chains? For example Stride can work with any chain that has ibc v3 and up but could this be done through cosmos if this is the case? It this example instead of the direct route from Stride to other chains would need to go to Stride>Cosmos>Chain A. Could this be done? As far as i remember Stride has ibc v7.2. So could this even work with cosmos being ibc router? This is a genuine question since I think stride is unique on how it utilises ibc. So I think Cosmos hub should have latest ibc version so other consumer chains could work properly. Not all chains will do the same as stride but their operation should not be limited by cosmos hub. I am up for making cosmos hub a ibc router but it should not be forced, instead offer it as a choice. Let’s say in theory ICS has around 50 chains 10 years from now having connect to osmosis and cosmos hub would be 100 different connections needed to be set up and this is only for 2 chains. Imagine that at avarage every consumer chain needs 4-5 ibc connections. This is…
Excerpt (1199 of 1423 characters). Read the whole post on the forum ↗
Before one decides on their private finances and gets a job, usually a good person first decides on their moral compass and values. Just saying
we can try a signaling proposal trought the gov to know how the community thinking about it ?
Sure can. Will write it up as a draft now
Kamikaza731:Cosmos then have latest version of ibc? Right now Cosmos has some version of 4.2.*. My question here how would this affect other chains?
Kitteh purrs at you.
Yeah, this is important. Can work on this in coming weeks.
dogemos:What about for non-ICS20 IBC channels? (i.e. ICS-27, ICS-721, etc) What if the hub fails to adopt these new features at an adequate speed where ICS chains feel they’re blocked by the hub?
Second this question. Currently Astroport uses a contract-to-contract channel / custom protocol to govern the Neutron outpost from Terra. Seems like this proposal would remove that flexibility for contracts? Or how would that work?