5 Differences between Cosmos & Polkadot
There has been a lot of discussion about the differences between Cosmos and Polkadot, two projects focused on blockchain interoperability. If you are unfamiliar with the two projects, this tweetstorm is a good high-level explanation of the two projects and resources to learn about them.
Although there are many posts explaining and highlighting the differences between the two, I believe most “Cosmos vs Polkadot” posts today are either biased or lack nuance. This blog post is an attempt to create a deeper discussion about the two projects, from architectural trade-offs to philosophical differences.
Why Build A New Blockchain?
There are two primary reasons why one would prefer building an application-specific blockchain from scratch instead of writing the application as a smart contract on one of the existing platforms.
Firstly, the existing smart contract platform you want to build on may not offer the flexibility and customizability that your application requires. For example, if your application requires a custom hash function, writing it on Ethereum would cost a lot of gas because the function needs to be executed on the EVM each time it is called. An option is to propose that the Ethereum protocol include the hash function as a precompiled contract, but unless this function is used widely in many other application as well, your proposal would probably not be approved. Writing your own blockchain from scratch gives you the freedom and flexibility to design the core logic of the blockchain to fit your application’s needs specifically.
The second reason is sovereignty. Building an application on a smart contract platform forces your application to be subject to the rules and governance of the protocol. This could range from things that affect user experience such as block times and gas pricing to state-changing decisions such as chain rollbacks.
Naturally, an independent, sovereign chain gives up the ability to seamlessly communicate with other applications because they live on separate blockchains with separate state machines. Cosmos and Polkadot are attempts to solve this — Cosmos with the Hub-and-Zone model, Polkadot with the Relay Chain/Parachain model.
This post will assume approximate knowledge of the two projects, and will focus on teasing out the differences between them.
Difference #1: Local vs Global Security
Cosmos and Polkadot function under two vastly different security models. Simplistically, Polkadot works as follows:
Parachains are blockchains within the Polkadot network. These chains have their own state machine, their own rules, and their own local block producers (collators). Each parachain is essentially an independent state machine, and can utilize any type of unique functionality, consensus algorithm, transaction cost structure, and so on. In the Polkadot Network, all the parachains are children of a parent chain called the Relay Chain, which contains some representation of a “global state” of all the parachains combined. The Relay Chain has its own consensus algorithm called GRANDPA consensus, which finalizes blocks on the parachains quickly. Through this model, parachains in Polkadot operate under a “shared security” model — if the Relay Chain is highly secure with 1000s of validators, any parachain will benefit from this strong security by simply connecting to the Relay Chain. This allows parachains to have sovereignty over their state machine and other local rules, as well as strong security shared with hundreds of other chains.
The drawback to this model is that the validators in the Relay Chain have the final say over state changes made in any parachain. For example, the validators could, for some reason, continually reject blocks that come from collators of a specific parachain and permanently block the parachain’s progress from being included in the global state. Polkadot tries to reduce this from happening by shuffling validators so that they validate random parachains, lowering the possibility of a specific validator censoring a specific parachain. Polkadot also has another class of validators called Fishermen, who continually check the validators for malicious activity.
The architecture of the Cosmos Network is fundamentally different.
In the Cosmos Network, instead of using a local/global model for security, every blockchain is independent and secures itself. Each blockchain runs its own consensus and the validators of each blockchain are responsible for securing that blockchain alone. The network uses a hub-and-zone model for interoperability, where zones (independent blockchains) can “send tokens” to other zones by routing through a hub (also an independent blockchain). This protocol is called the IBC (Inter-Blockchain Communication), which is a protocol for sending messages between chains to represent token transfers. The IBC protocol is a work in progress, starting with token transfers and eventually any type of message passing between blockchains.
Comparing this model with Polkadot, the biggest difference here is that the state of each zone is secured by its validators and its validators alone. If a zone wants to have strong security, it needs to bootstrap and recruit its own validators, which may be difficult for smaller applications. However, this is a strong selling point for certain applications that desires more control. For example, Binance is bootstrapping their DEX by having their own nodes be validators for the Binance Chain as a starting point. This way, they have full control over the chain while they test the DEX and roll out new features. In my opinion, it is difficult to imagine the Binance Chain giving up sovereignty over which transactions get to go in which block, which they would have to do if building on Ethereum or Polkadot. For the same reason, I believe that there will be a category of companies (e.g Telegram, Facebook, Kakao) that will choose to build their own chain and retain full control, in which it will be trivial to connect to other chains in the future.
Difference #2: Governance & Membership
The second main difference between Polkadot and Cosmos is with regard to governance and membership. In the Polkadot network, there is one single Relay Chain and some number of parachains that the validators of the Relay Chain can support. The current estimate is that there will be 100 slots for parachains, but this number can shrink or grow in the future. The Polkadot Network allocates slots for becoming a parachain via an auction mechanism — the highest bidder is able to secure a parachain slot for some fixed time duration by locking up DOTs (the native cryptocurrency of Polkadot) in a Proof-of-stake system. This means that to become a parachain in the Polkadot Network, you would need to purchase a large amount of DOTs and lock them up for as long as you want to continue being a parachain.
The Cosmos Network on the other hand has no fixed rules of membership — anyone can build a hub or a zone. Hubs are themselves sovereign blockchains built with the intention of connecting a bunch of other blockchains. Two examples are the Cosmos Hub, which was recently launched by the Tendermint team, and the Iris Hub, a Hub that plans to connect blockchains which primarily operate in China and other parts of Asia. This hub-and-zone model makes inter-chain communication more efficient, because instead of connecting to every other blockchain, each blockchain only needs to connect to a hub.
Closely related to membership is the difference in governance processes on the two networks. In the Polkadot Network, governance decisions are determined by the amount of DOTs voters have. There will be a formal mechanism for voting on-chain, but it has not been finalized and the latest updates are here. Other than regular stake-weighted voting, Polkadot also uses the idea of a council to represent passive stakeholders. This council is a group of people, starting with 6 people and adding one every two weeks until 24 people. Each of the members is elected through an approval vote. While the specific details of this governance process are yet to be finalized, the implications are that there are ways to change parameters in the Relay Chain such as block time, block reward, etc., as well as ways to change membership rules for parachains. For example, the Polkadot governance process could change the number of DOTs required or the auction mechanism to become a parachain. A common misperception is that DOT holders can vote to kick out parachains at will, but in reality DOT holders can only change the process of membership. This means that a bonded parachain stays bonded throughout its entire lease.
On the other hand, there is no single “governance” process for the Cosmos Network. Each hub and zone has its own governance processes and there is no central set of rules that apply to the entire network of blockchains. When people talk about “governance of Cosmos”, they are referring to is the governance of the Cosmos Hub, the blockchain launched by the Tendermint team. The Cosmos Hub has a set of rules that lets anyone send a text proposal, and Atom holders are allowed to vote on it, where their votes are weighted by the number of Atoms they own. This is an example of what a proposal looks like. To learn more about the intricacies of the governance process, this blog post by Chorus One is a good primer on the governance of the Cosmos Hub.
Difference #3: Inter-blockchain Communication
Another differentiator between Polkadot and Cosmos is the architecture of their inter-blockchain communication protocol and its design goals. Polkadot is targeting arbitrary message passing between parachains. This means that Parachain A can call a smart contract inside Parachain B, can transfer a token between the chains, or any other type of communication. Cosmos on the other hand is focusing on asset transfers between chains, which is a simpler protocol. Right now, both communication protocols are fairly under-specified and have not been built. More detail about the two specifications can be found here: IBC (inter-blockchain communication) and ICMP (inter-chain messaging among parachains).
The biggest challenge in inter-blockchain communication is not how to represent data on one chain on another, but instead how to handle the case where the chain that the data originates from forks and reorganizes to exclude the transaction. This is where Cosmos and Polkadot differ the most because of the architectural designs.
Polkadot uses two different mechanisms for securing interchain communication. First, having shared security makes it easier to exchange messages. A byproduct of shared security is that all parachains have uniform levels of security, and as a result each chain can trust one another. To understand this, let us use the example of getting Ethereum (high security) and Verge (low security) to interoperate. If we wanted to represent Ethereum on Verge, we could lock up ETH and mint some ETH-XVG tokens on the Verge blockchain. However, due to low security, an attacker could 51% attack the Verge chain and send a double spend to the Ethereum blockchain, allowing the attacker to withdraw more ETH than he actually owns. Because of this, it is difficult for high-security chains to trust low-security chains when sending each other messages. This becomes even more complicated when messages are passed to multiple different chains of different security levels.
In theory, having uniform shared security is a nice way of securing interchain communication. However, to achieve this, the protocol must be able to shuffle validators assigned to each parachain often and randomly. This leads to the classic “data availability problem”, which is that each validator must constantly download the state for each parachain it is assigned to. This is one of the most difficult problems in the space today and it is unclear that Polkadot will be able to solve it.
Second, Polkadot uses the concept of Fishermen, which are “bounty-hunters” on the Polkadot Network who watch Parachains for malicious activity. This is, in some sense, a “second line of defense” against malicious activity. In the case that the validators for a specific parachain finalize an invalid block, the Fishermen can submit a proof to the relay chain and effectively roll back the entire state of the Polkadot Network and all the parachains within it. During interchain communication, we are most worried about one chain reorganizing and the other progressing as per normal, but Polkadot ensures that everything is rolled back if an invalid block is discovered.
Cosmos takes an entirely different approach to interchain communication. Since each blockchain has its own validators, it is entirely possible that there are zones which are “evil” with colluding validators. This means that when one zone wants to communicate with another zone, zone A needs to trust the Cosmos Hub (for routing) and validators in zone B. In theory, it sounds inefficient because people in zone A will have to look up the validators in zone B before they decide to send a message to it, but I believe in practice it will not be so bad. “Famous” validators such as Polychain Labs or Zaki Manian’s iqlusion will likely validate many different blockchains, and over time build a reputation for being a “good validator”. This means that when zone A sees that zone B is validated by Polychain Labs and iqlusion, they may decide to trust it.
However, even if people trust a chain, it can still get taken over by malicious actors and cause problems. Let us use this example, which was taken from this talk:
Let us say that the small red dots represent a token called ETM, the native currency of the Ethermint zone. Users in Zone A, B and C want to use ETM for some applications within those zones and they trust the Ethermint zone, so they do an IBC message which transfers ETM to these zones. Now assume that the Ethermint validators collude and start double spending, arbitrarily moving around coins, and so on. This will have an effect on the rest of the network, since ETM tokens also exist on different zones. However, the only people which will be affected by this are people who hold ETM tokens within Ethermint or within other zones. It is not possible for the evil validators within Ethermint to arbitrarily corrupt other zones except itself. This is the purpose of the Cosmos architecture — to ensure that malicious activity cannot affect the entire network.
Conversely, if an invalid state transition occurs on the Relay Chain (global state) and is not picked up by the Fishermen, this could affect every parachain in the Polkadot Network. We cannot assume that parachains are distinctly different objects because they ultimately still share one global state with the rest of the network.
Difference #4: Consensus Algorithms
The Polkadot Relay Chain uses a consensus algorithm invented by the team called GRANDPA. This algorithm allows the Relay Chain to finalize many blocks from all the parachains quickly and can also accommodate a large number of validators (over 1000). Simplistically, this is because not all the validators need to vote on every single block — instead, validators can vote on a single highest block they think is valid, and the algorithm transitively applies the vote to all ancestors of that block. Through this, the algorithm finds the set of blocks which have a supermajority vote and considers that final. GRANDPA is still under development and we do not know how it will perform in the real world.
The parachains can use a variety of consensus algorithms to come to local consensus. Polkadot provides a software development kit (Substrate) that comes with 3 consensus algorithms out of the box: GRANDPA, Rhododendron, and Aurand. It is likely that more algorithms will be added to Substrate and will be usable within the Polkadot Network.
On the other hand, each blockchain in the Cosmos Network can use any consensus algorithm that adheres to a certain specification known as the ABCI spec. This specification is created to standardize communication between chains. Right now, only the Tendermint algorithm fits this spec, but there are other efforts to create other consensus algorithms that fit this specification. At a high-level, the Tendermint algorithm works by having every validator talk to each other to approve/reject any single block, creating finality on a per-block level. The algorithm is fast and has been stress-tested in a live environment with 200 validators and 6-second block times during Game of Stakes. The Cosmos team also provides a software development kit with the Tendermint algorithm being usable out-of-the-box. This blog post is a good primer on consensus algorithms, and the features of Tendermint that make it useful.
The biggest downside of Tendermint is that it has a high communication overhead between validators. This means that while it could work fairly fast with ~200 validators, it will be much slower with 2000 validators. However, the trade-off here is that you get safety in asynchrony. This means that in a network partition, instead of having 2 different histories of transactions which will eventually merge (and 1 history will get discarded in the process), the network will halt instead. This is important because if you see a transaction that is “finalized”, it will never be reversed even in the worst network conditions.
My personal opinion on this is that comparing the two projects on the basis on which consensus algorithm they use is not particularly useful in the long run. Both the projects are creating architectures that will allow many different consensus algorithms to be used in the future. The vast majority of applications today should work fine whether they use Tendermint or one of Polkadot’s consensus algorithms.
Difference #5: Substrate vs Cosmos SDK
Both Polkadot and Cosmos offer a software development kit, called Substrate and the Cosmos SDK respectively. They are both intended to make it easy for developers to start building their own chains, and include various modules out-of-the-box, such as governance modules (voting systems), staking modules, authentication modules, and so on. The main difference between the two is that the Cosmos SDK supports Go, whereas Substrate supports any language that compiles to WASM (Web Assembly), giving more flexibility to developers.
They are both very new frameworks for building blockchains, and will add more features in the coming years. Doing a deep dive into both and examining the exact developer experience of building an application using either SDK is another blog post in itself. If you want to see that, write to me on Twitter @juliankoh.
Conclusion
Although this post is extremely long and detailed, it is still not exhaustive. The differences between Cosmos and Polkadot are difficult to grasp and have many nuances which I may have missed. It was surprisingly difficult to get a full picture of the two projects and sometimes documentation changed from day to day. Both projects are still in their infancy and will greatly evolve over the next year — some points which I have raised may become defunct soon. In conclusion, I have come to believe that the biggest advantages of Polkadot over Cosmos are the following:
- Application developers do not need to bootstrap their own security
- If they can solve data availability, interchain messaging under shared security is easier
- They seem to be more ambitious with Substrate (WASM, more consensus algorithms & modules out-of-the-box)
- Focus on arbitrary message passing better for cross-parachain contract calls. (Still unsure of use case today)
- Seems to have more developers building version 1.0
Conversely, the advantages of Cosmos compared to Polkadot are the following:
- Cosmos is live. Polkadot is not.
- Polkadot has a restrictive & possibly expensive parachain membership process
- More customizability is better for specific projects (e.g, Binance)
- Evil validators of parachains could spread corruption throughout entire network. Cosmos restricts corruption to only within the zone & corresponding assets
- Cosmos SDK used by many projects already
- Focus on asset transfers simpler & easier to get right. Proven use case today.
Thank you to everyone who has answered my endless stream of questions, especially Zaki Manian & Gautier Marin from Cosmos and Alistair Stewart from Polkadot. The amazing Whiteboard Series from NEAR Protocol (Alex Skidanov) was instrumental in helping me understand both projects. These links curated by Linda Xie about Polkadot & Cosmos also helped me narrow down the scope of my blog post so it would remain readable. Special thanks to Cheryl Yeoh for brainstorming, proofreading, and helping to come up with the idea to write this post.
