What are some differences between Substrate and Cosmos SDK?

1

This is a question I was wondering about recently a lot - everybody is comparing Cosmos and Polkadot here and there but how does the developer experience actually look like? Does anyone here know both Cosmos SDK and Substrate to compare those on a technical level? More precisely

  • Is having Rust a real advantage in comparison to Go?
  • Which one has a better tooling/libraries/ecosystem/etc?
  • Is it “easier” to develop with Substrate or Cosmos? (I know, it’s subjective, but would love to hear some opinions)
  • Which one is easier to learn?
  • Can you do the same thing with both? (let’s say I want to create some standalone DeFi blockchain, why would choose one over the latter?)

I know it’s a very opinionated question but I would love to hear any thoughts on this! Thank you

4 Likes
2

It will be hard to really give a deep (and unbiased) comparison of these two platforms, so I won’t attempt.

But I did want to make a few comments based on your post.

First is that while I understand where you are coming from with some of the questions above, I urge you to separate your questions between those about the core pillars of the platform, things which cannot be changed, and those which are more ephemeral.

For example: I think it would not be wrong to say today that Cosmos is probably the “easier” platform to build and learn with today. A lot of this comes from the fact they use Go, which seems much more friendly to new developers. It is also fair I think to note they have 1 - 2 years of a jump start from when cosmos started launching their chains, to when Polkadot started launching parachains. Finally, I believe some things are more simple on their side because they focused a lot more on creating blockchains centered around tokens / defi, versus blockchains centered around general computation, but this is where I am speaking beyond what I truly know.

What I want to point out about those questions is that even though Cosmos may be easier to learn on today, we are definitely trying our best to flip that, and I would hope that decisions about building unstoppable decentralized applications are not chosen about “what is easiest today”. Instead, when picking a platform to build your business on top of, you want to select the one which makes the right technical and philosophical decisions.

In that context, I think this is where we would argue that Polkadot has major advantages over all other next generation blockchain platforms.

  • For computational scaling, we use parallelization of execution via sharding (which is working in production today; not part of a future roadmap).
  • For resource / economic scaling, we use shared security provided by the relay chain.
  • For liveness, we use a split of BABE for block production, and GRANDPA for finality.
  • For future compatibility and performance, we use Wasm at the heart of all state transition functions.
  • For ease of mind and performance across all of our software, we use Rust.
  • For agility of development, we have on-chain governance and upgrades at the heart of our technologies.
  • and so on…

These are not things which are easy to understand the importance of by looking at NFT drops, comparing TVL, or even reading a whitepaper. These are decisions which compound with every block that your chain produces. The impact of these decisions are felt in many years, and through many crypto bull and bear cycles. Through new laws and regulation, and the ability for platforms to nimbly navigate those changes.

Anyway, this is my perspective on the topic, rather than my answer to your question. I hope it can guide you toward finding the questions which are important, and the answers you need.

29 Likes
3

And the fact that this is stored onchain, I think, is biggest differentiating factor of substrate compared to all of its competitors. I strongly think that it is only a matter of time before all blockchains realize that this is the best way to create future-proof blockchains and adopt a similar approach. Today, WASM is probably the best option, although it might change.

As for the main topic, I personally would love to actually step up to the challenge and meetup with a seasoned Cosmos SDK developer for a weekend hackathon, where e.g. we each get a full day to teach the other person, and at the end exchange conclusions. It would be hard to do it unbiased, but worth a try. This has been on my mind for almost a year now, but it has been hard to find the bandwidth to initiate it.

11 Likes
4

I’m sure @Emily_Parity can help you with setting this up :wink:

5 Likes
5

Thank you Shawn, it summarizes very well what I’ve thought - though shared security is coming to Cosmos as well so I wonder whether it is “on par” with the one Polkadot already has. But yeah, I have always seen forkless upgrades & WASM runtime as the most significant advantage of our ecosystem, it’s a true killer feature.
Also, you are right about the jump start, I think we need another year to get all the parachains properly integrated and finally bring some innovative features - so one year can do a lot.

1 Like
7

That would be really awesome, I know some people who are organizing a Cosmos conference in Czechia next year so I would definitely be interested in setting this up if you are up to it.

3 Likes
8

I think that “interchain security” from cosmos attempts to sound like shared security, but is really nothing like it. Something like shared security cannot be backported to an existing protocol. It requires design from the ground up to support it, all the way for us from Wasm as a shared language for state transition functions, to the parachains protocol and PoV/PVF (Proof of Validity, Parachain Validation Function), and the existence of the relay chain itself.

Not saying anything bad here, since all of this is very technical, but if you think that cosmos can simply “add shared security” to their ecosystem, it implies to me that there is not a full and deep understanding of what shared security is and how Polkadot provides it. We should do better on this, but as much as we can explain things on our side, it is very easy for other teams to pretend to do the same thing with just “words”.

This is the same as chains calling themselves decentralized, open, secure, fault tolerant, etc… It is easy to use those words to describe anything. It is hard for things to actually be those words.

Here is a rough draft of a twitter thread I was going to post that talks about the differences between Polkadot’s Shared Security, and the thing that cosmos had talked about building. The thread never got posted because the proposal on the Cosmos side was rejected, I chose not to publish anything rather than fighting a ghost of the past.

Interchain Security Twitter Thread (ROUGH DRAFT)

Nearly 6 years after the Polkadot whitepaper emphasized the importance of shared security, the Cosmos Hub is trying to follow along. However, unlike Polkadot, Cosmos is trying to bootstrap these decisions after the fact, and onto a protocol which ultimately was not designed to support it well. Let’s go into that.

Shared Security has been a key part of Polkadot’s design, since the first commit to the original whitepaper in November of 2016. At the time, it was named “pooled security”, but has been a guiding light to every architectural decision made since that time.

822×516 135 KB

The Cosmos Hub just released a new whitepaper for “Atom 2.0”, an extension of their existing protocol, of which one of the new principles is “interchain security”. The Cosmos team is positioning this feature to be similar to the shared security provided by Polkadot, but these two technologies could not be more different.

1172×188 78.5 KB

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

The Cosmos ecosystem is composed of sovereign chains, most commonly built with the Cosmos SDK. Interchain security proposes that validators of the Cosmos Hub will be forced, by governance, to also participate as a validator for other chains.

To do this, validators of the Cosmos Hub will need to run additional executable binaries for each of the chains which will be provided “interchain security”. Failure to do their job will result in their staked ATOM tokens getting slashed.

The problem is that this design is not scalable, and cannot be scalable in the way that the Cosmos ecosystem is currently engineered. Imagine that the hub wants to provide security to just 100 other chains. This would require that node operators will now need to run 100 blockchains, probably on 100 separate machines to prevent competing computational resources.

This design also puts validators at a greater risk of being attacked through malicious binary upgrades. It can be hard to trust software from hundreds of teams, all which you are required to run, and all of which can target sensitive keys you store on those machines.

Polkadot on the other hand was designed from the beginning with shared security in mind, and has used a meta-protocol to abstract away running multiple blockchains within a single ecosystem in a truly scalable and safe way.

That meta-protocol is Wasm.

You can think of Polkadot compatible blockchains as two parts: a client and a runtime. Each client acts as a Wasm executor and the blockchain runtime (aka the state transition function) is a Wasm blob which can be executed inside a safe sandbox.

1536×732 88.1 KB

You can compare this to a game console, which is designed to play many different games. The console itself, like the Polkadot client, is just a host for running the game. With Substrate, our blockchain development sdk, we allow you to easily design “games” (runtimes) which are compatible with this console.

1600×651 96.6 KB

In that context, you can think of the Polkadot binary as an “all-in-one”. Polkadot validators run an executable that can run any of the parachain’s Wasm runtime. That means, the single Polkadot binary can turn itself into any blockchain in the Polkadot ecosystem in real time.

1600×1055 149 KB

Validators in the Polkadot ecosystem play a single role at any point in time. From our validator pool, some are selected to validate the relay chain, and the rest are split up among the many parachains which Polkadot also secures. This selection process is random, and changes over time, countering possibilities of collusion from a subset of bad actors.

This means that the entire Polkadot ecosystem and its wide range of application-specific blockchains can be secured using a single well reviewed executable. Then, all the other blockchain’s state transition functions run in a sandbox that keeps the network and node operators safe too.

But wait… there is more.

Cosmos has finally figured out the rough basics of pooled economic security that already exists on Polkadot today, but it completely forgets about the deeper role of a multi-chain security hub.

One of the key aspects of the Polkadot Relay Chain is that it keeps track of the state of all parachains and keeps them in lock step. That means blocks which are finalized on Polkadot imply finalization of all interactions between all parachains at the same height. This is that second point noted in the whitepaper.

818×508 134 KB

This means shared security and finality on Polkadot extends all the way to the relationships between chains, whereas interchain security on Cosmos can only go as far as protecting a single chain. This is also a fundamental advantage that XCMP has over IBC as a multi-chain message passing protocol.

In summary, Cosmos is heading in the correct philosophical direction with interchain security, but these kinds of philosophies are near impossible to design in after the fact. Polkadot has been building with these principles in mind for the last 6 years.

The future will be multi-chain, and Polkadot is best designed to support that future.

31 Likes
9

That was really useful, thanks a lot! I just wonder what’s the situation with IBC vs XCMP, could you elaborate a bit more on that? Shouldn’t Cosmos validator set supporting interchain security do a proper finalization of all connected chains in each block and thus make IBC as safe as XCMP?

3 Likes
10

Shawn this is an exceptional post. We need such comparisons to be more public and spread on the internets.

Another vertical to compare with is ETH 2.0

4 Likes
11

This is incredible @shawntabrizi - thanks for sharing!

FWIW I think this is still absolutely worth sharing somewhere. I haven’t seen a more compelling write-up on the subject.

12

there’s a new proposal - Replicated security, which we can compare with Shared security

@shawntabrizi

13

Thank you @shawntabrizi for the excellent analysis and writing

14

All this is very enlightening. We are always being compared to Cosmos and people ask us, “what do you have better”. A global overview would be welcome. Without criticism, it should be demonstrated that Polkadot is the most promising.

1 Like
15

Out of interest, how are the Cosmos chains funded? Is it via a similar structure to parachains - e.g. VC?

In terms of onboarding to interchain security, is there an equivalent of slot auctions being discussed?

The Atom 2.0 whitepaper discussed using the foundation funds to bootstrap chains and then take a stake in them - this was I think one of the more controversial aspects - ie how these decisions were made, and how there was a danger of special interests dominating.

Directionally this is also where I think Polkadot is headed, albeit in a way where we can align stakeholder interests in a way that reinforces rather than degrades the security model.

1 Like
16

I’d like to add something from the Parachain perspective. Gav once said in an interview that parachains are secure because they only need to run one honest collator for the parachain to be secure.

I didn’t know exactly what this meant at the time and it seems to be counter-intuitive, but this is where the Polkadot security mechanism shines. I found out of course when our upgrade mechanism broke, and we had to use the Code Substitute mechanism to fix it. If anything there are so many features to Polkadot it really is hard to see exactly why it was done that way - until you need to use it.

Parachains are secured basically because both the parachain collators and polkadot validators agree on the PVF that Relaychain validators can use to validate the block candidates submitted by collators. It is from a shared knowledge of the PVF that the parachains are secure.

Therefore in a highly adversarial environment for the parachain - for example, 99 dishonest collators using a different PVF but only 1 honest collator using the correct PVF, the parachain can still continue producing blocks as long as that single honest collator produces blocks that would be agreed by the Relaychain validators.

This is completely unique in the entire blockchain space, and it’s what makes Polkadot a significant milestone in understanding where blockchains can take us.

9 Likes
17

isn’t this the same how rollups work on ETH? they require one honest node too, that provide the proof

18

Honestly, I also think so. Isn’t that correct?

19

It might be now, but Polkladot was first AFAIK.

20

This isn’t correct. Collators aren’t required for securing anything. Collators are only required for liveness, aka building blocks. The security comes from the relay chain which ensures that the state transition presented by the collator is correct. For that it uses the wasm that is registered on the relay chain. So, collators can not just build random blocks that fail this validation. In a normal blockchain the majority of collators could just dictate a block, which doesn’t work here.

I get what you want to say, but this is also not entirely true. The validator is not agreeing with the collator on the PVF. The validator is using what is stored in the relay chain state and doesn’t care what the collator wants from it :wink:

3 Likes
21

from my understanding, the majority of collators can dictate a block content (not the computation though). Is this correct?

Could you elaborate why there is a need for fraud proofs in ETH L2 (like optimism) and not in Polkadot? Wasn’t that supposed to be done by Fishermen, that were deprecated?