Popular science | Five differences between Cosmos and Polkadot

Both Cosmos and Polkadot are projects that focus on blockchain interoperability, and there have been many discussions about the differences between the two. If you are not familiar with these two projects, Linda Xie has sent a series of tweets to introduce these two projects, which can be a good starting material.

Although there have been many posts analyzing the difference between these two projects, I think most of them are biased or not detailed enough. Through this post, I will explore these two projects in more depth from architectural trade-offs to philosophy.

Why build a new blockchain?

Why do some projects choose to build a blockchain that specializes in hosting applications from scratch, rather than writing applications on existing blockchains in the form of smart contracts? There are two main reasons for this.

First, the existing smart contract platform does not necessarily meet the flexibility and customizability required by the application. For example, if the application you want to build requires a custom hash function, writing it to the Ethereum will consume a lot of gas, because this function needs to be executed once in the Ethereum virtual machine every time it is called. One solution is to propose adding this function as a pre-compiled contract to the Ethereum protocol. However, unless this function is also widely used in other applications, the probability of this proposal will not pass. By writing a new blockchain from scratch, you have the freedom and flexibility to design the core logic of the blockchain to meet the needs of your application.

• Comment: What value does the blockchain provide?
• Zuckerberg’s “killing skills”, will Facebook become the world’s largest bank?
• North Korea has a pot? New research shows that the theft of Coincheck is actually done by Russian hackers.

Second is the issue of autonomy. Applications built on smart contract platforms must accept platform governance and adhere to their rules, from rules that affect user experience, such as block time and gas pricing, to decisions such as rollbacks that change state.

Correspondingly, the autonomy chain loses the ability to communicate seamlessly with other applications because the applications are built on blockchains that use different state machines. Both Cosmos and Polkadot address this issue—Cosmos uses the Hub-and-Zone model and Polkadot uses the Relay Chain/Parachain model.

Readers need to have a certain understanding of these two projects, this article focuses on sorting out the differences between the two.

1. Local security vs global security

The security models used by Cosmos and Polkadot vary greatly. In a nutshell, Polkadot's workflow is as follows:

– Polkadot's network architecture –

Parallel chains are blockchains in a Polkadot network. These chains have their own state machines, their own rules, and their own block producers, that is, collators. Each parallel chain is essentially an independent state machine, and any type of special function, consensus algorithm, transaction fee structure, etc. can be used. In the Polkadot network, all parallel chains have the same parent chain, called the relay chain, which contains the "global state" consisting of all parallel chains. The trunk chain has its own consensus algorithm called GRANDPA Consensus (grandfather consensus) that quickly determines the blocks on the parallel chain. Through this model, Polkadot's parallel chain implements “security sharing” – if there are 1000 verifiers on the trunk chain for high security, any parallel chain connected to this relay chain will benefit. In this way, the parallel chain can have its own state machine and customize the rules, and can share the security of the parent chain with hundreds of parallel chains.

The hood door of this model consists in verifying the state change on the parallel chain by the verifier on the relay chain. For example, the verifier may for some reason always reject the block proposed by the auditor on a chain, and the block on this trunk chain can never be added to the global state. To avoid this as much as possible, Polkadot shuffles the verifiers, allowing them to randomly validate parallel chains, reducing the probability that the same verifier will always verify the same parallel chain. Polkadot also has a certifier called Fishermen, who constantly checks the verifier for malicious behavior.

Cosmos uses a completely different network architecture.

– Cosmos network architecture –

In the Cosmos network, each chain runs independently and has its own security mechanism instead of a local/global security model like Polkadot. Each chain has its own consensus mechanism, and a single verifier is responsible for protecting the security of the chain. The Cosmos network uses a central-partition model for interoperability, and each partition (independent chain) can "send tokens" to other partitions through the center (also a separate chain). This protocol, called IBC (cross-chain communication), is a protocol that implements token transfers between chains and chains. The IBC agreement is still under development , initially supporting token transfers and eventually supporting cross-chain delivery of all types of messages.

The biggest difference in Cosmos's architecture compared to Polkadot's architecture is that the state of each partition is only protected by its own certifier. For a partition to get a lot of security, you need to set up your own set of certifiers, which can be difficult for small applications. However, for those applications that want more control, this is a big bright spot. For example, the currency security begins with its own nodes acting as verifiers for the currency chain to facilitate the continued operation of the decentralized exchange. In this way, the coin has full control when testing the coin chain and adding new features. I think that the currency is unlikely to give up the power to decide which deals can be chained, but if you want to develop on the Ethereum or Polkadot platform, you can't give up that power. Because of this, I think that companies like Telegram, Facebook, and Kakao will choose to build their own blockchain and gain control, and it is unlikely to communicate with other chains in the future.

2. Governance and participation

The second major difference between Polkadot and Cosmos is governance and participation. In a Polkadot network, there is only one relay chain and some parallel chains that share the verifier with this relay chain. According to current estimates , the maximum number of parallel chains is 100, but it is likely to decrease or increase in the future. The Polkadot network bids for the right to use parallel chains through an auction mechanism – the highest bidder needs to lock a certain number of DOTs (the native currency on Polkadot) in the PoS system in order to have a parallel chain in a certain period of time. Use right. This means that to use the parallel chain on the Polkadot, you need to buy and lock a large number of DOTs until you no longer want to use this parallel chain.

The Cosmos network does not have a fixed participation rule – anyone can create a center or partition. The center is a blockchain with autonomy that is designed to connect to other blockchains. Here are two examples, one is Cosmos Hub , which has recently been brought online by the Tendermint team; the other is Iris Hub , which is designed to connect blockchains that primarily run in China or other Asian countries. This center-partition model improves the efficiency of cross-chain communication because the partition chain only needs to be connected to the center and does not need to be connected to every other chain.

– Center-partition model can connect multiple chains more efficiently –

Due to different participation rules, there are also differences in the governance processes between the two networks. In the Polkadot network, governance decisions depend on the number of DOTs that the voter pledges. There will be a formal mechanism for voting on the chain, but it has not yet been finalized. Click here for the latest developments. In addition to adopting a mechanism for determining the weight of voting by pledge, Polkadot has also formed a committee to represent inactive equity holders. The committee consists of six people at the beginning, adding one person every two weeks until the end of 24 people. Each committee member is elected by voting in favor of voting . The specific details of the governance process have not yet been finalized, which means that there are many ways to change the parameters of the relay chain, such as the block time, block rewards, etc., as well as the participation rules of the parallel chain. For example, Polkadot's governance process can change the bidding mechanism for parallel chain usage rights or the number of DOTs required. A common misconception is that DOT holders can discard a parallel chain by voting. In fact, DOT holders can only change the engagement process. That is to say, once a parallel chain is auctioned, the right to use this chain is enjoyed throughout the lease period .

On the other hand, there is no single “governance” process for the Cosmos network. Each center and partition has its own governance process, so there is no set of core rules that apply to all chains throughout the system. What we mean by "Cosmos Governance" refers to the governance of the Cosmos Hub, the chain that is brought online by the Tendermint team. The rule of Cosmos Hub is that anyone can send a text proposal, voted by the ATOM holder, and ATOM's pledge determines the voting weight. I want to know what the proposal looks like. Here is an example. If you want to learn more about the governance process, you can read this post by Chorus One, which is a starting point for understanding the Cosmos Hub governance mechanism.

3. Cross-chain communication

Another difference between Polkadot and Cosmos is the cross-chain communication protocol and its design goals. Polkadot is designed to achieve arbitrary messaging between parallel chains. That is to say, parallel chain A can call the smart contract in parallel chain B to realize token transfer or other type of communication with parallel chain B. Cosmos focuses on cross-chain asset transfers, and its protocol is simpler. At present, these two communication protocols are still to be refined and have not yet been completed. You can view the details of the two protocols, IBC (cross-chain communication) and ICMP (cross-chain communication between parallel chains).

The biggest challenge facing cross-chain communication is not how to represent data on one chain on another, but how to deal with chain forks and chain reorganizations. This is the biggest difference in the architectural design between Cosmos and Polkadot.

To ensure the security of cross-chain communication, Polkadot uses two different mechanisms. The first is the security sharing mechanism, which reduces the difficulty of information exchange. Another benefit of shared security is that all parallel chains are at the same security level, so each chain can trust each other. For ease of understanding, let's take the example of Ethereum (higher security) and Verge (lower security). If you want to represent Ethereum on the Verge chain, we can lock some Ethereum and then generate ETH-XVG tokens on the Verge chain. However, due to the low security of the Verge chain, an attacker could launch a 51% attack on the Verge chain and send a double-flower transaction to the Ethereum blockchain to retrieve more Ethereum than the actual number. Therefore, when sending messages to each other, it is difficult for a chain with higher security to trust a chain with lower security. If you are communicating messages between different chains at the security level, the situation becomes more complicated.

In theory, shared security is a good way to secure cross-chain communication. The premise is that this protocol ensures that the verifiers are frequently shuffled and then randomly assigned to each parallel chain. This creates a classic "data availability problem" where each time a verifier is assigned to a new parallel chain, the state of the new chain needs to be downloaded. This is one of the biggest problems in the current blockchain field, and whether Polkadot can be solved is not yet known.

Second, Polkadot introduces the concept of Fisherman, the “bounty hunter” on the Polkadot network, which specifically monitors malicious behavior on parallel chains. In a sense, this is the "second line of defense" against malicious behavior. If the verifier of a parallel chain winds an invalid block, Fisherman can then submit a certificate to the relay chain to roll back the state of the entire Polkadot network, including all parallel chains. During the cross-chain communication, the most worrying thing is that one chain is reorganizing, and the other chain is running as usual. Polkadot avoids this problem, and once an invalid block is found, the entire network will roll back.

Cosmos uses a completely different cross-chain communication approach. Because each chain has its own certifier, it is very likely that the certifier collusion in the partition will occur. That is, if there are two partitions that need to communicate, the A partition needs to trust the Cosmos Hub (communication hub) and the certifier in the B partition. In theory, the person in the A partition needs to investigate the certifier of the B partition before deciding to send information to the B partition. But I think the actual situation is not so bad. Well -known verifier nodes such as Polychain Labs or Zaki Manian's iqlusion may validate multiple chains and build a good reputation. That is, when the person in the A partition sees that the B partition is verified by Polychain Labs and iqlusion, it may decide to trust the B partition.

However, even if a chain is trusted by people, it may be controlled by a malicious attacker and various problems arise. A good example is mentioned in a conversation :

– Coins are scattered across different partitions of the Cosmos network –

Suppose the small red dot in the above figure represents a token called ETM, which is the native token of the Ethermint partition. Users in the three partitions A, B, and C want to use ETM to run some applications in their respective partitions, and they all trust the Ethermint partition, so they accept some ETM in their respective partitions through cross-chain communication. Now suppose that the certifier of the Ethermint partition colludes to launch a double-flower attack and arbitrarily transfer ETM tokens. This also has an impact on the rest of the network, as ETM tokens also exist in other partitions. However, only ETM token holders in Ethermint or other divisions are affected. A malicious verifier in an Ethermint partition can only destroy its own partition and cannot destroy other partitions. This is the goal of the Cosmos architecture—ensuring that malicious behavior cannot affect the entire network.

Polkadot is different. If an invalid state update occurs on the relay chain (global state) and is not discovered by Fisherman, each parallel chain in the Polkadot network is affected. Parallel chains cannot be seen as completely different things, after all they all share the same global state.

4. Consensus algorithm

The Polkadot relay chain uses the GRANDPA consensus algorithm. This algorithm allows the relay chain to quickly identify blocks from all parallel chains and accommodate a large number of verifiers (more than 1000). In simple terms, this is because not all certifiers need to vote for each block – they can simply vote for a block that they think is valid, equivalent to all blocks before the block. Approved. In this way, the GRANDPA algorithm can find a block with the highest number of votes and determine the set of blocks. The algorithm is still under development and it is not known how it will actually be implemented.

Parallel chains can use different consensus algorithms to achieve local consensus. Polkadot provides a software development kit ( Substrate ) that includes three out-of-the-box consensus algorithms, GRANDPA, Rhododendron, and Aurand. In the future, more algorithms may be added to Substrate, which can be applied to the Polkadot network.

In the Cosmos network, there are many consensus algorithms that can be selected for each chain, as long as it is a consensus algorithm that conforms to the ABCI specification. The ABCI specification aims to standardize cross-chain communications. Currently only the Tendermint algorithm conforms to this specification, and other teams are working to develop other consensus algorithms that conform to the specification. On a more abstract level, the principle of the Tendermint algorithm is to allow each verifier to communicate with each other and determine whether a block can be chained, thus achieving determinism at a single block level. The algorithm was fast and passed the stress test of 200 verifiers, with a block time of 6 seconds in the Game of Stakes . The Cosmos team also provides a software development kit that includes the out-of-the-box Tendermint algorithm. This article is a good introduction to the consensus algorithm and the functionality of the Tendermint algorithm.

The biggest disadvantage of the Tendermint algorithm is the high cost of communication between verifiers. That is to say, although the number of verifiers is around 200, the algorithm runs very fast. Once the number of people increases to 2000, the speed will be much slower. On the other hand, the trade-off is the security in an asynchronous environment. That is to say, when a network partition occurs, there will be no case where two different transaction histories are eventually merged into one (and another transaction history is discarded), but the entire network will stop running. This is very important, once a transaction is "finally confirmed," it will not be revoked even in the worst network environment.

My personal opinion is that comparing the two projects based on consensus algorithms has no long-term significance. The architecture of these two projects will accept different consensus algorithms in the future. Most of today's applications work well with either the Tendermint algorithm or one of Polkadot's consensus algorithms.

5.Substrate vs Cosmos SDK

Both Polkadot and Cosmos offer software development kits called Substrate and Cosmos SDK . The purpose of both is to make it easier for developers to build their own blockchain, including various out-of-the-box modules, such as governance modules (voting systems), pledge modules, and authentication modules. The main difference between the two toolkits is that the Cosmos SDK only supports the Go language, and Substrate supports any language that can be compiled into WASM (Web Assembly), giving developers more flexibility.

Both of these toolkits are a new framework for building blockchains and will add more features in the coming years. An in-depth analysis of the two toolkits and a detailed experience of developing applications using the two toolkits requires an additional article. If you are interested, please leave a message to @ juliankoh on Twitter.

in conclusion

Although this article is very long and written in great detail, it still has some omissions. The difference between Cosmos and Polkadot is difficult to grasp, and there may be many details that I have not captured. It is no easy task to understand the two projects in all aspects. After all, the project documents may change at any time. These two projects are still in their infancy and will be greatly developed in the coming year – some of the points I mentioned above may not be established soon. All in all, I think that Polkadot has several advantages over Cosmos:

1. Application developers do not need to maintain security themselves
2. Cross-chain communication under the shared security model makes it easier to solve data availability problems
3. Substrate (in terms of WASM, more consensus algorithms, and out-of-the-box modules) shows great ambition
4. Contract calls across parallel chains are more focused on unrestricted types of information transfer (this use case is not yet clear)
5. Developers of version 1.0 seem to have more

In turn, Cosmos has several advantages over Polkadot:

1. Cosmos is online, Polkadot is not online yet
2. Polkadot's parallel chain participation process is more restrictive and costly
3. More able to meet the needs of specific projects (such as currency security) for customization
4. The malicious behavior of the verifier on the parallel chain can affect the entire network. In the Cosmos network, malicious behavior can only destroy individual partitions and assets
5. There are already many projects using the Cosmos SDK.
6. Focus on how to reduce the difficulty of asset transfer. There are already validated use cases.

Thanks to everyone who has been tired of answering questions, especially Zaki Manian and Gautier Marin from the Cosmos team, and Alistair Stewart from the Polkadot team. The Whiteboard Series video series released by NEAR Protocol ( Alex Skidanov ) is awesome and has helped me understand both projects. Linda Xie 's links to Polkadot and Cosmos helped me narrow down the scope of the article and make it more readable. Special thanks to Cheryl Yeoh for providing me with inspiration and ideas during my writing of this article and for reviewing this article.

Original link: https://medium.com/@juliankoh/5-differences-between-cosmos-polkadot-67f09535594b Author: Julian Koh translation & proofreading: Min Min & A sword

(This article is from the EthFans of Ethereum fans, and it is strictly forbidden to reprint without the permission of the author.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!