background

first level title

background

Previously, the development of the blockchain has always been an arms race of the public chain. The new public chain aims to explore faster performance and lower cost, so as to be able to support the possible large-scale commercial use of the blockchain. However, there are still some teams that may want to build a blockchain that runs alone, but it is very difficult to build a blockchain and maintain it, and it is difficult for the team to have extra energy to do what they originally wanted to do. superior. However, the development of the industry cannot be hindered by the difficulty of building a chain, so Layer 0 projects like Polkadot or Cosmos came into being.

Substrate is an open-source, general-purpose blockchain development framework that provides the underlying public components required for blockchain development, allowing ordinary developers to quickly develop a blockchain application to verify their own ideas. During the design and development of Substrate, one of the primary considerations is to ensure the scalability of the software. Parity engineers considered various possible usage scenarios during development, such as various types of public chains, private chains, alliance chains, cross-chains, etc. Substrate also supports WASM smart contracts and pluggable consensus mechanisms, and is compatible with the Polkadot network.

The Cosmos SDK is an open-source framework for building multi-asset public proof-of-stake (PoS) blockchains, such as the Cosmos Hub, as well as permissioned proof-of-authority (PoA) blockchains. Blockchains built using the Cosmos SDK are often referred to as application-specific blockchains. The goal of the Cosmos SDK is to enable developers to easily create custom blockchains from scratch that can natively interoperate with other blockchains. We see the Cosmos SDK as an npm-like framework for building secure blockchain applications on top of CometBFT.

SDK-based blockchains are built from composable modules, most of which are open source and available to any developer. Anyone can create modules for the Cosmos SDK, and integrating already built modules into your blockchain application is as easy as importing them. More importantly, the Cosmos SDK is a capability-based system that allows developers to better reason about the safety of interactions between modules.Regarding the Substrate framework and the Cosmos SDK, we can simply have a basic understanding of them through a comparison chart:

But at first glance, what the two do is similar. They both help developers to quickly create a chain, and it is in line with the current popular concept - modular blockchain. This can't help but make many people curious. The two How do they compare. And such questions were finally discussed on the Polkadot Forum.

A developer posed this relatively specific question:

Can the Cosmos SDK and Substrate be compared on a technical level? more specifically:

1. Is there really an advantage to using Rust over Go?

2. Which platform is superior in terms of tools/libraries/ecosystem etc.?

3. Is it "easier" to develop with Substrate or Cosmos? (I know this is subjective, but still want to hear some opinions)

4. Which is easier to learn?

5. Can both achieve the same function? (For example, I want to create a separate DeFi blockchain, why would I choose one over the other?)

Shawn Tabrizi, Parity's software engineering director, is mainly responsible for improving the developer experience in the Substrate ecosystem, and also participates in Polkadot's core software development, providing Polkadot with functions such as shared security, cross-chain communication, and parallel chain slots. It is appropriate for him to answer this question.

Here's his answer:

First, while understanding your starting point for some of the above questions, I suggest you divide your questions into questions about the core pillars of the platform, i.e. things that cannot be changed, and questions of a more ephemeral nature.

For example: I think it's fair to say that Cosmos is probably the "easier" platform to build and learn at the moment. This is largely because they use the Go language, which seems friendlier to new developers. When Cosmos started launching chains, by the time Polkadot started launching parachains, Cosmos was 1-2 years ahead of schedule, and I think it's fair to point that out. In the end, I think some of their things are simpler because they're more focused on creating a token/DeFi centric blockchain than a general purpose compute centric blockchain, but that's beyond me to really understand scope.

On these issues, I would like to point out that while Cosmos may be easier to learn, we are absolutely doing everything we can to change that, and I hope that decisions about building unstoppable decentralized applications are not based on "which is easier today" . Instead, when choosing a platform to build your business on, you need to choose one that makes the right decisions, both technically and philosophically.

In this case, I think this is where we would argue that Polkadot has a significant advantage over all other next-generation blockchain platforms.

For compute scalability, we parallelize execution via sharding (this is already running in production today; not part of the future roadmap).

For resource/economic scalability, we use the shared security provided by the relay chain.

For liveness, we use BABE for block production and GRANDPA for finality.

For future compatibility and performance, we use Wasm as the core of all state transition functions.

To make all of our software easy to use and improve performance, we use Rust.

To develop agility, we put on-chain governance and upgrades at the core of our technology.

etc...

The importance of these things is not easy to understand by looking at NFT launches, comparing Total Value Locked (TVL), or reading white papers. These decisions are accumulated with each block produced by the chain. The impact of these decisions will be felt for many years.

In addition, regarding Cosmos’ inter-chain security issues, Shawn added:

I think Cosmos' "interchain security" tries to sound like shared security, but in reality they are not the same. Things like shared security cannot be backtracked in existing protocols. Supporting shared security needs to be designed from the bottom layer, from the shared language of Wasm as a state transition function, to the parachain protocol and PoV/PVF (validity proof, parachain verification function), and the existence of the relay chain itself.

It's the same chains that call themselves decentralized, open, secure, fault tolerant, etc...it's easy to describe anything with those words. Getting things to actually be those words is harder.

The following is the first draft of a Twitter thread I intend to publish discussing the differences between Polkadot’s shared security and the builds that Cosmos is talking about. Since the proposal on the Cosmos side was rejected 34 , I chose not to publish anything, rather than fighting the ghosts of the past. (Note: When Shawn answered this question, the cosmos 2.0 proposal had just been rejected, but in early 2023, cosmos 2.0 was officially passed)

secondary title

Interchain Security Twitter Post (Draft)

Nearly 6 years after the Polkadot white paper emphasized the importance of shared security, the Cosmos Hub is trying to follow suit. However, unlike Polkadot, Cosmos tries to guide these decisions after the fact and applies them to a protocol that ultimately fails to support it well. Let's dig deeper.

Shared security has been a key part of Polkadot's design since the original white paper was first submitted in November 2016. At the time, it was called "pooled security" but has been the guiding principle guiding every architectural decision since.

Contents in the picture:

In other words, Polkadot can be thought of as being equivalent to a set of independent chains (e.g., the set containing Ethereum, Ethereum Classic, Namecoin, and Bitcoin), except for two very important points:

1. Pool security;

2. Inter-chain tradability without trust. It is these points that make us consider Polkadot "scalable". In principle, problems to be deployed on Polkadot can be massively parallelized across a large number of parachains. Since all aspects of each parachain can be performed in parallel by different parts of the Polkadot network, the system is somewhat scalable.

The Cosmos Hub published a new white paper on "Atom 2.0", an extension of their existing protocol, with one of the new principles being "interchain security". The Cosmos team positions this feature as similar to the shared security provided by Polkadot, but the two technologies are actually quite different.

Contents in the picture:

Inter-chain security: Security is a necessary foundation for building key components of the Cosmos network, and the inter-chain security environment of the Cosmos Hub will be enriched with new features to make it more practical, efficient and collaborative.

So, how will interchain security on Cosmos work? How does shared security on Polkadot work? What are the key differences here, and how do they really compare?

The Cosmos ecosystem consists of sovereign chains, usually built using the Cosmos SDK. Inter-chain security proposal Cosmos Hub validators will be enforced by governance to participate in the validation of other chains. To do this, validators on the Cosmos Hub need to run additional executable binaries for each chain that will provide "interchain security". If they fail to meet their duties, the ATOM tokens they staked will be slashed. The problem is that this design is not scalable and cannot be as scalable as the current design of the Cosmos ecosystem.

Imagine if the Hub wanted to provide security to 100 other chains, node operators would now need to run 100 blockchains, possibly on 100 separate machines, to prevent competing computing resources. This design also increases the risk of validators being attacked by malicious binary upgrades. It's hard to build trust with hundreds of teams of software, all of which you need to run, and all of which may be targeting sensitive keys you store on those machines.

Polkadot, on the other hand, designed shared security from the ground up and uses a meta-protocol to abstract running multiple blockchains in a single ecosystem in a truly scalable and secure manner. This meta-protocol is Wasm.

You can think of a Polkadot-compatible blockchain as two parts: the client and the runtime. Each client acts as a Wasm executor, and the blockchain runtime (i.e. state transition functions) is a Wasm binary large object (blob) that can be executed in a secure sandbox.

You can compare it to a gaming console, which is designed to play many different games. Like Polkadot clients, consoles are simply hosts that run games. With Substrate, our blockchain development SDK (Software Development Kit), we allow you to easily design a "game" (Runtime) compatible with this console.

In this context, you can think of Polkadot binaries as "all-in-one machines". Polkadot validators run an executable that executes any parachain Wasm Runtime. This means that a single Polkadot binary can turn itself into any blockchain in the Polkadot ecosystem in real-time.

Validators in the Polkadot ecosystem play only one role at any one time. From our pool of validators, some are chosen to validate the relay chain, and the rest are distributed among the many parachains that Polkadot secures simultaneously. This selection process is random and changes over time, resisting the possibility of collusion from a subset of malicious actors.

This means that the entire Polkadot ecosystem and its wide range of application-specific blockchains can be secured using a single vetted executable. The state transition functions of all other blockchains then run in a sandbox, keeping the network and node operators safe as well.

But wait... there's more.

Cosmos has finally figured out the rough rationale for the consolidated economic security that Polkadot already exists today, but it completely ignores the deeper role of the multi-chain security hub.

A key aspect of the Polkadot relay chain is that it tracks the state of all parachains and keeps them in sync. This means that a block confirmed on Polkadot implies the end of interaction between all chains at the same height as all parachains. This is the second point mentioned in the white paper, which is trustless inter-chain tradability.

The future will be multi-chain, and Polkadot is best suited to support this future by design.

summary

first level title

summary

Shawn's answer is full of many technical answers, which may be difficult to understand. In short, what Shawn wants to express is the following:

1. Shawn admitted that Cosmos may be easier to learn and build, partly because it uses the Go language, which is more friendly to new developers. However, he believes that when choosing a platform, the key is to choose a platform that makes the right decision technically and philosophically, not just to see which one is easier to use. In addition, to discuss the differences between the two, it is necessary to know that Cosmos has been running 1-2 years earlier than Polkadot.

2. He believes that Polkadot has advantages in many aspects, including computing scalability, resource/economic scalability, liveness, future compatibility and performance, ease of use, and development agility. These advantages may not be easy to see on the surface, but they will have an impact over time.

3. Shared security has been a key part of Polkadot's design since the original white paper was submitted in November 2016, and the Cosmos Hub only started to follow suit after publishing the new "Atom 2.0" white paper.

4. Interchain security on Cosmos is actually quite different from Polkadot’s shared security. Cosmos is not designed to scale because validators need to run additional executable binaries for each chain that provides interchain security, possibly on many independent machines. This design also increases the risk of validators being attacked by malicious binary upgrades.

In conclusion, while Cosmos is moving in the right philosophical direction with regards to interchain security, this philosophy is almost impossible to engineer into after the fact. For the past 6 years, Polkadot has been designed with interchain security in mind and has been built with these principles in mind. The future will be multi-chain, and Polkadot is best suited to support this future by design.

postscript

first level title

postscript

It seems that from a technical perspective, the Substrate framework has its unique technical advantages. On the other hand, even if Cosmos realizes its 2.0 inter-chain security, because this function is designed after the fact, it cannot fully achieve the Cards are designed from the outset with the degree of security achieved. Then, the Substrate framework and Polkadot must be unique in solving certain problems, and there must be a matching market. Just like Apple's strict requirements and relatively high threshold, it still has its advantages compared to Android, which is more open but has a lower threshold.