Cosmos — an early in-depth analysis at the ecosystem of connected blockchains — Part Two
This is part two of three articles where i will discuss what i have learnt whilst looking into Cosmos. Part One can be found here. I will provide links throughout the article to provide reference to sections as well as a list of sources at the bottom of the article for you to look into specific areas in more detail if required. Hopefully it will be useful for those interested in learning more about the project.
Tier 1, Tier 2 and Tier 3 ISP’s
Today the Internet can be thought of as a giant network of interconnected networks using the same communication protocol — Transmission Control Protocol/Internet Protocol (TCP/IP). At the core of the Internet is an ultra-fast global optical Internet backbone.
An Internet Service Provider (ISP) is a company the provides Internet access. The most common ISP is the provider who delivers Internet to your home or business for a fee. However, there are 3 levels of ISPs.
Tier 1 Internet providers are the networks that provide the backbone of the Internet. We call them backbone Internet providers. These providers build infrastructure such as the Atlantic Internet sea cables. They provide traffic to all other Internet providers, not end users. Examples include Level3, Cogent communications, Telia Carrier etc
A tier 2 ISP is a service provider who connects between tier 1 and tier 3 Internet service providers. Tier 2 providers will exchange Internet traffic through peering agreements, as well as purchase Internet transit. They include Vodafone (buys IP transit from Level 3), British Telecom (buys IP transit from Telia Carrier).
A tier 3 ISP is a provider who strictly purchases Internet transit. A tier 3 provider is the last mile provider who delivers Internet access to residential homes and businesses. Examples include Comcast, Verizon Communications etc.
Why is this relevant?
Cosmos also follows a hub and spoke topology and so once Cosmos starts to scale to thousands of blockchains etc, it’s likely there will also be similar topology with Tier 1 Hubs mainly connecting to other Tier 1 Hubs as well as Tier 2 hubs. These need to be the most secure Hubs and provide the backbone as well as connecting to high traffic zones such as say a DEX for example which all other zones will want to use. These Tier 1 Hubs are the 3 hubs represented in the dark blue shade in the middle in the diagram below.
Tier 2 Hubs connect to Tier 1 Hubs as well as Tier 3 Hubs. They also connect to zones which have less traffic than the core ones but more than the average zone. These are represented in the Blue shade in the diagram.
Then the majority of zones created will be connected to Tier 3 Hubs. These connect to Tier 2 Hubs and other zones. This is mentioned in this Video “Interoperability (Cosmos) — Blockchain for Developers [Lecture 11]” (time stamped) from 32:43 to 35:20
When you connect to a web page you don’t directly connect to it, you will go across many paths through numerous of the Tier ISP’s mentioned previously. you can see this for yourself if by opening “Command Prompt” and typing “tracert speedguide.net” to see the route it takes to get to the speedguide.net website and latency involved. (in the example below, it took 20 Hops with a total latency of around 42 milliseconds)
If we refer to the Diagram above with the different Tier Hubs and zones if you wanted to transfer an asset between the 2 zones circled in red, you can see the paths it would take.
Zone 1 > Hub 1 (Tier 3) > Hub 2 (Tier 2) > Hub 3 (Tier 1) > Hub 4 (Tier 1)> Hub 6 (Tier 2) > Zone 2 so if its taking a minimum of 6 blocks to transfer between 2 zones (41 seconds) you can see how this can get very slow when going through many hops. (minimum of 247.68 seconds)
The longer the number of hops the more you have to pay fees, (which is also made more difficult by hubs being deciding what currency they want to accept. (For example, the Cosmos Hub will be able to accept multiple as payment for transactions (not specifically just ATOM) whereas other Hubs in the Cosmos Ecosystem like IRIS hub require that transactions are paid in IRIS. So if you have a say 6 hops each requiring a different currency to pay the fee in, then this makes it very difficult for relayers as they need to have wallets for each different payment method on each of the hops along the chain as well as holding an amount of tokens to be able to pay.
Compared to Polkadot / Ethereum etc where there is a root chain which keeps track of tokens across all chains to prevent double spending etc, that’s not the case in Cosmos. The Hub does not verify or execute transactions committed on other zones, so it is the responsibility of users to send tokens to zones that they trust.
Hubs protect against double spending between zones but ultimately the security of the zones are allowed to fail without it effecting every other blockchain in the ecosystem.
Token Transfers Across Multiple Routes
In the example below say Zone 2 is a DEX and want to send Token “A” from Zone 1 to the DEX (Zone 2)
As described previously a Hub doesn’t keep track of the state of all the other zones / hubs in the chain one route could go through a very insecure zone with just 1 validator who double spends for example and so to combat this the token is represented differently depending on which route it takes by adding the source blockchains as a prefix.
So, if the token is transferred across the route highlighted in green below, Token A would be represented differently at each hop from Zone 1 to Zone 2 (DEX)
Zone 1 = “A”
Hub1 = “Zone 1:A”
Hub 2 = “Hub 1: Zone 1:A”
Hub 4= “Hub 2: Hub 1: Zone 1: A”
Zone 2: “Hub 4: Hub 2: Hub 1: Zone 1: A”
If the token is transferred across the route highlighted in orange below, Token A would be represented differently at each hop from Zone 1 to Zone 2 (DEX)
Zone 1 = “A”
Hub 1 = “Zone 1:A”
Hub 3 = “Hub 1: Zone 1: A”
Hub 4 = “Hub 3: Hub 1: Zone 1: A”
Zone 2 = “Hub 4: Hub 3: Hub 1: Zone 1: A”
So Token A is represented twice on Hub 4 depending on which route it has taken:
It will mint different tokens for:
“Hub 2: Hub 1: Zone 1: A” and “Hub 3: Hub 1: Zone 1: A”
and the DEX at Zone 2 would have Token A represented multiple times with depending on which route it had taken
“Hub 4: Hub 2: Hub 1: Zone 1: A” and “Hub 4: Hub 3: Hub 1: Zone 1: A”
Considering the number of different routes that a token may take, there would be a lot of tokens represented multiple times splitting the liquidity depending on which path it has taken. The further hops it takes the more you have to trust you have to place without any easy way to determine validator setups to ensure they are secure, fully decentralised etc for each hub / zone
This Video below explains multiple of the potential issues i have raised in this article and if your only going to watch one then this would be it from 45:16 to 58:20
To be able to connect to Blockchains that have probabilistic finality such as POW with Bitcoin and Ethereum etc as well as any other blockchain (including those that have immediate finality that doesn’t implement the IBC protocol) a Peg Zone is required to connect them to the Cosmos ecosystem
This is a complicated infrastructure to set up, you need to trust the team running the Peg Zone and each peg zone is custom designed to work with a specific blockchain they are connecting to. So there would need to be a completely different peg zone design to connect Ethereum than it would to connect Bitcoin (which would be very difficult to implement anyway) due to it needing to be able to sign a transaction and for that to be recognised by the connected chain. As a result, the team have said it would only be worthwhile connecting the top few blockchains that have the most demand. This means there’s going to be a lot of blockchains which Cosmos isn’t going to be able to connect to natively.
This is explained in this video (time stamped) from 30:07 to 33:01 and more information can be found here
Other interoperability projects that would compliment Cosmos
The team have been looking at the possibility of integrating Interledger into the Cosmos to address the issue of paying fees across hops as can be seen in this video, Interledger is great at being a transfer of value, however isn’t able to transfer non-fungible assets / logic / data to other blockchains. An example of this is with Hyperledger Quilt which currently use Interledger but now looking at implementing Overledger SDK as well.
I personally think IBC is a great solution for directly communicating with 2 chains but may hit potential issues as the ecosystem is scaled out. I think by creating a zone which integrates the Overledger SDK would complement Cosmos and provide a solution to numerous issues identified in this article.
On the left is a Hub in the Cosmos Ecosystem and multiple zones connected to it. All the blue lines represent a connection via Cosmos IBC Protocol. All the dotted green lines show possible direct connections to other blockchains as well as being able to connect to other zones running Overledger SDK within the Cosmos ecosystem. This will provide Oracle / Off Chain / Connecting to legacy network functionality and doesn’t require the connected chains to fork their code to make it possible.
- Rather than have a peg zone for every blockchain, there could be a single peg zone with the Overledger SDK integrated that enables direct connection to all different blockchains as well as to other peg zones running Overledger within the Cosmos ecosystem — resolving the issue of having to pass through multiple hops to reach the destination chain, which will significantly reduce latency, complexity of having to pay fees across many different hubs each with their own token(s) that they accept for payment as well as providing more trust (as the source and destination chains don’t have to trust every single hub / zone that’s in the path)
- It would resolve the issue about having to represent the same token multiple times depending on the route they took across multiple hops. Otherwise this would get very complicated for DEX’s to manage etc when there are token is represented many times. As it provides direct connectivity each token can be represented once. Overledger’s Universal Utility token can provide tokens to be represented across any blockchain
- It would provide a more efficient, scalable solution than the complex peg zones and allow Cosmos blockchains to connect immediately to all the leading enterprise permissioned blockchains (R3’s Corda, Hyperledger, JP Morgan’s Quorum, Ripple and Permissioned variants of Ethereum) as well as the leading Permissionless blockchains such as Bitcoin, Ethereum, IOTA, EOS and Stellar (Also looking at adding Binance Chain). Permissioned blockchains are going to see the most utilisation over the next couple of years with Enterprises really pushing blockchain adoption, this would allow Cosmos ecosystem to benefit from this with very little time to implement.
- Overledger would provide Oracle functionality to blockchains within Cosmos ecosystem so that they can easily integrate their existing legacy networks.
- Overledger would also provide the ability to run smart contracts across all blockchains even those that don’t support smart contract functionality such as standard zones / hubs as well as blockchains such as Bitcoin via Treaty Contracts.
So rather than having them all direct connected to each other / multiple hops, you could have a zone within each separate section that enables direct connection to another. So in the example below if the two zones wanted to communicate to each other, they would just need to connect to their directly connected hub and then to the zone running Overledger SDK and it would provide direct connectivity to the other zone running Overledger SDK via Overledger.
Validators for each of the hubs would be incentivised to run the node running the Overledger SDK with the number of connections going through it to connect to the various different blockchains. As additional revenue, they could even host their own Overledger Gateway to benefit from the volume that is relayed through that as well.
Even if it’s not used for connecting hubs within the cosmos ecosystem it would provide a more scalable solution that having to create a custom peg zone for every zone you want to connect so that each connecting chain is able to recognise the signed transaction.
Another option would be for the Zones to implement the Overledger SDK as a module to access interoperability with other blockchains without the use of IBC.
In Part Three we will look at the ATOM token as well as looking at the commonly misunderstood staking tokens in general. This can be viewed by clicking here
Sources for research / Useful Links
As always do your own research, but hopefully this will give a better understanding of the project, and you can see some of the sources i used whilst researching below so you can find out more for each. I have provided my opinions on the advantages of Cosmos, and any potential issues that i have raised I have provided links to where they have been discussed at Presentations. I am familiar with Overledger which is why i have suggested that as a solution to some of the potential issues raised and that both projects would complement each other nicely.
Intro to Cosmos, Whitepaper, Token Distribution Details, Diagram showing how Tendermint works, Tendermint details, List of Projects using Tendermint, Cosmos Validators FAQ, Peg Zones, Ethermint, IBC, IBC BI-Weekly Calls, Cosmos SDK, Relayers, ATOM Tokenomics
Cosmos Explorers , Validator info — Mintscan, B-Harvest, Link to lots of other sites for wallets, delegating etc, Number of ATOMs
Other recent articles:
Blockchain Brad Interview with Quant Network CEO — 570 Banks, Rearchitecting the Financial System (DeFi), QNT being listed on Traditional Stock Exchanges this year, Expanding to Asia, Partnered with Oracle, Connecting Binance Chain to Enterprises, Telecoms, Patents and much more