While the scaling problem for blockchains is well understood and being addressed by many teams, what is often overlooked is the interoperability problem and why it matters for the future of crypto. Without protocols in place to enable automated communication between chains, our decentralized projects will continue to remain in silos and our overall ecosystem will remain fractured.
The reality today is that we live in a multi-chain world. It’s foolish (as Vitalik Buterin famously said in his 2016 white paper on chain interoperability) to believe that there will be “one blockchain to rule them all”, so unless we get serious about creating standards and engineering-friendly tools to enable inter-chain communication — and unless we properly incentivize entrepreneurs to make this happen —our fractured system will continue to hinder the development and mass adoption of decentralized applications. An overabundance of utility tokens will be maddening for users and developers alike.
Imagine if cities, for example, had their own unique currencies, transportation systems, and train track dimensions. Because standards are built through commonality, if every project builds and promotes their own protocols in isolation, it will become hard — or even impossible — to come together and create standards.
To follow the analogy, it’s important for pioneers to create new cities, of course, but without common currencies and a connected infrastructure to support an economy (people, goods, trade, etc…), these cities have much smaller odds of flourishing.
Thankfully, the Cosmos Network offers us an elegant solution not only for building new “cities” that can integrate a common set of utility/currency tokens, but — just as importantly — it provides tools for building tracks, trains, protocols and train stations between cities (even to/from cities in different “countries” with radically different infrastructure!).
To help explain how Cosmos works we must first begin with Tendermint, which is “Byzantine-fault tolerant (BFT) state machine replication” software (i.e. blockchain software) that — like any blockchain software — is responsible for handling three important components: consensus (nodes agreeing on state), networking (propagating state between nodes), and an application layer (updating state based on transactions).
Thus, we can simplify the representation of a blockchain in the Cosmos Network that uses Tendermint by simply this:
And, to tie them together for interoperability purposes, information flow and transferring tokens between chains (i.e more than just atomic swaps) can occur via Cosmos’ Inter-blockchain Communication (IBC) protocol:
The first blockchain to be built in the Cosmos Network is called the Cosmos Hub. It leverages Tendermint and is being written with the Cosmos-SDK(using the Go language), which anyone will be able to use to use for their own blockchains to quickly “include” modules (similar to any package manager) such as staking, governance, accounts, token generation, etc…
The Cosmos Hub is designed specifically to allow other blockchains, termed “Zones”, to interoperate (e.g. pass tokens around) through this initial Hub:
Because Tendermint is free and open source, private chains can be easily created and used to strategically interface with public chains as needed. (e.g. imagine if an industry consortium wants to start private but eventually go public and interoperate with other chains. Cosmos would be a solid design choice for this.)
To go further down the rabbit hole, existing blockchain application software (such as the Ethereum Virtual Machine) can be used to run a unique blockchain on the Cosmos network. Indeed, the Ethermint project has done exactly that. Ethermint enables teams that have built smart contracts on Ethereum to easily port their code over to leverage Tendermint’s speed and scalability within the Cosmos Network.
Another important concept to consider within the Cosmos ecosystem is a Peg Zone. These unique blockchains enable interoperating (e.g. exchanging tokens) with an outside chain that has a different consensus protocol, like Ethereum’s Proof-of-Work (PoW) (versus Tendermint’s BFT).
For example, the specific peg zone between Ethereum and Cosmos is called Peggy:
As a final bonus, blockchains within the Cosmos Network don’t even need to run Tendermint. We can imagine a world where IBC is baked directly into a future Proof-of-Stake Ethereum, for example, and interoperate between any other blockchain in the ecosystem.
Here is an example all the blockchains mentioned above connected together via the Cosmos Hub:
As you can see, Cosmos is much more than just blockchain software, it’s a set of protocols and software tools designed to integrate a universe of blockchains and make it easy for developers to spin up their own blockchains with custom design parameters.
Because Tendermint separates consensus and networking code from the application code, which can be written in any language and interface via ABCI, life is made significantly easier for developers. The Cosmos-SDK (and future SDKs in the ecosystem that leverage IBC/ABCI) are designed to be modular and composable. This means, for example, if you want to spin up a blockchain that handles conditions unique to your industry or business case, you don’t need to reinvent the wheel. You can simply pull in plugins for staking, governance, accounts, token generation, etc… as needed, similar to any common package manager for a software language or framework.
In fact, a core belief of the Cosmos ecosystem is to allow interoperability between a heterogeneous set of self-sovereign blockchains that may have radically different protocols for networking, state management, and consensus. As long as the finality of block consensus is fast enough to play nice with IBC, then two blockchains that look and feel very different can get along and benefit from being in the same ecosystem.
Plus, Tendermint and ABCI allow for automated state transitions (compared to most blockchains that require state to always been updated by manual user transactions):
“Another example of the flexibility application-specific blockchains provide to developers is the ability to trigger automatic state-transitions. The ABCI has two messages called BeginBlock and EndBlock. BeginBlock() and EndBlock() functions are automatically executed at the beginning and end of each block. Developers must be careful not to include logic that is too computationally expensive or would expose the application to never-ending loop but, if done properly, this can be a very useful ability.”
Scaling is arguably one of the largest problems in the blockchain community today. The two main concepts universally proposed to speed up transaction processing and throughput are to (1) drop the number of block-producing nodes (e.g. into a BFT-based consensus protocol like Tendermint), and/or (2) “shard” a blockchain to handle requests in parallel.
Cosmos leverages both options:
From the Cosmos website:
“Tendermint and IBC allow blockchains in Cosmos to scale out indefinitely. Zones built on top of Tendermint can handle up to thousands of transactions per second by themselves. And even if transaction speed slows down on a Zone because too many people are using it, another identical Zone can be added to the Hub and half of the users directed to it, thereby doubling transaction capacity. Meanwhile, the Cosmos Hub ensure that Zones connected to it remain in sync.”
While it’s possible to spin up your own hub and connected zones (or spin up a zone connected to an existing hub) this can be costly in terms of time and money. Another option in the Cosmos ecosystem, however, is to build your own blockchain software while leveraging another zone or hub’s validator set. This means that, for an agreeable price, a single group of trusted validators could be producing blocks for multiple blockchains simultaneously.
Thus, while Cosmos may indeed be the place to go for the rapid development of application-specific blockchains, it will also be welcoming to dApp developers seeking a zone/hub that matches their application needs. Similar to how many developers are using the Ethereum Virtual Machine today to write applications, taking advantage of the same set of miners, so in the future there may be hundreds or thousands of zones to choose from on which to build dApps.
Finally, one of the most compelling features of Cosmos is the ability to share coins across hubs and zones, including coins that were brought in from external chains. This allows dApp developers to create a better experience for users, especially if those users are already used to storing and handling a particular token of their own.
The clunkiness of moving ERC20 tokens around, for example (which also requires ETH to pay for gas to actually make a transaction happen on-chain), is likely one of the main reasons why dApps have been slow to gain traction. What is needed is the ability to make “the blockchain” essentially disappear for end users and to create simple experiences of browsing, commenting, transacting, signing in, accessing personal data, etc… accessible for a wide audience.
The interoperability architecture that Cosmos brings to the table will finally allow this connected ecosystem of dApps to be built.
- — -
Author’s note: Thanks in advance for any corrections/updates to what I’ve written here. I very much welcome feedback. Also, if you are an ATOM holder: check out Hubble if you haven’t yet. I’m working with the Figmentteam and we’re excited to offer tools like Hubble as well as validator nodes for hubs/zones within the Cosmos Network. Feel free to subscribe to our newsletterand/or email me directly (email@example.com) to learn more about the value of staking your ATOMs with us.
Finally, I’d like to welcome you to subscribe to my personal newsletter where, in addition to crypto, I also write occasionally about health science and startup life. Special thanks to Tony, Andy, Matt, and Lorien for review, feedback, and insightful conversations about the above article. And before you leave, feel free to comment below (or inline above), hit the clap button, and/or share this article with a friend if you’ve found it helpful. Thanks!