Polkadot vs Cosmos


#1

Polkadot vs Cosmos

This discussion is intended to promote discussion and understanding of the differences between the projects. There is probably much about about Polkadot that I don’t understand well. For me, I helped @jaekwon and @ebuchman peer review the Cosmos design back in the summer of 2016 and we have made no major changes. Give the the use cases for blockchains that have emerged, I think Cosmos anticipates the need of the next several years for blockchain developers.

Cosmos and Polkadot are both developer friendly systems for building new generation of blockchain applications that are more scalable, user friendly and flexible. Every scalable blockchain design must answer a few fundamental questions. This is a compare and contrast between how Cosmos and Polkadot answer these question. You could answer the same questions for Eth 2.0 or other projects.

I’d like to thank Dan Robinson for coming up with this framing of next gen blockchain projects.

  1. Is there one global order of blocks or is relative ordering sequencing only done on as needed basis?

Polkadot : Yes. In Polkadot, there is one master Relay chain. No transaction is finalized until it’s been ordered by the master chain.

Cosmos: No. There are many Cosmos hubs and they only submit data to each other when exchanging IBC packets. If IBC packets are infrequent, a Zone will only rarely submit blocks headers to the Hub. This enables centralized fast zones to exist rather the restricting the whole system to the speed of a single master chain.

  1. How are state changes authorized?

Polkadot: Collators must stake DOTs(staking tokens) to produce valid updates to parachains. Collators perform the same function as Cosmos zone validators and will use a pluggable consensus to generate updates.

Cosmos: Anyone can create a Cosmos Zone or Hub and use either an existing staking token or create a new one. They will use either trusted parties or a Bonded BFT validator set.

Cosmos Rationale: We reject the 1 world computer vision. Cosmos is designed to build a connected world of secure BFT computers rather than 1 world computer.

  1. How do you exchange state between chains?

Polkadot: Any user can transfer data between parachains by getting a collators to produce a block with the exit and getting a receipt of finality from relay chain and presenting to the corresponding chain. The contract between the state machines is specified be the respective developers. Developers will have to develop standards that enable safe chain to chain interaction but potentially any interaction is possible.

Cosmos: Users can exit a to another Zone via the Hub. They submit a receipt (IBC Packet) that the Zone finalized the exit transaction over the IBC channel between the Zone and The Hub. The job of the hub is to make sure that any authority is exclusively held by the zone that submitted a proof and the zone has the authority to make the change. In the case of a simple token transfer, the Hub checks that the Zone had the right to transfer a token because of the balance the Hub maintains for the Zone contains the token and that the Token hasn’t already been sent to another zone.

Cosmo Rationale: We believe this ecosystem also the Hub to have the minimum complexity. This makes it a natural place for the economic nodes to connect and should be very secure and stable. This pushes complexity to the edge of the network.

  1. How do you protect the soundness of the system against invalid state transitions?

Polkadot: Some combination of random collator elections and Fishermen are designed to ensure that parachains never deviate from rules specified in on chain code stored on the Relay chain.

Cosmos: Cosmos is designed to tolerate occasional invalid state transitions and failure in zones rather try to prevent them. A corrupted validator set can steal user funds or debase the token supply but the Hub will ensure than tokens that do not originate in the Zone will never be double spent and that other invariants are maintained. We fundamentally believe that as long as it is relatively easy to parse what risks a user is exposed to they can price the risks of a Zone failing on the assets they hold.

My personal opinion is that Fishermen are not an incentive compatible as a soundness solution. Fisherman also add a lot annoying complexity to universal gas pricing on computation in the network that ends being very constraining for parachain designers.

  1. How do ensure data is available? Vitalik’s write up of the data availability problem

Polkadot: Relay node validators will attest to validating erasure code based light client proofs of data availability for all parachains

Cosmos: Tendermint consensus is a proof of data availability for an honest validator set and Cosmos is designed to tolerate failure in the case of malicious validator sets. In the worse case, governance could intervene or challenge response over the IBC channel is an option.

  1. How does it prevent forks/halts?

Polkadot: GRANDPA for the relay chain and any consensus that supports light clients proofs in the parachains

Cosmos: Tendermint or other BFT protocols like Honeybadger

  1. Expected number of blockchains in the ecosystem?

Polkadot: ~1000
Cosmos: Unlimited


#2

Responding to question from Twitter.

  1. How do we think about validator nodes in our network?

Polkadot: Polkadot moves as much of the distributed devops as possible into the the runtime via WebAssembly everywhere. All participants in the network run the same software and play different roles depending on what staking slots of for consensus, collators, fishermen etc. Upgrades are largely automated. Normination means that operators don’t need to unilaterally There are thousands of slots and each of them at staked with different chains. Polkadot requires a strong source of randomness for committee selection and aggregate signatures.

Cosmos: Each chain has on the order of 10-300 validators. The distributed devops functionality is separate from the core software and left to the validators to build themselves. Upgrades require a lots of manual intervention. Delegation allow stake holders and operators to be distinct from each other while retaining skin in the game. We anticipate the validator sets for Cosmos chains to overlap but assort based on market forces. There are perhaps 200 operators in the world with kinds of security critical distributed devops capacity we are looking for. Future work like bringing aggregate signatures to Tendermint will allow for future chains to have 1000s of validators but the also requires 1000s of operators to emerge as well.


#3

This is a great question. I’ll interpret it below :point_down:

  1. How do Polkadot and Cosmos differ in the developer compositional environment they offer to users/developers?

Polkadot:: Polkadot is essentially operating under the sharding paradigm of interchain interactions. Because effectively the entire network is one unified state machine. The designers of a chain can expose arbitrary apis that other chains can call. One can expect that standards will emerge allowing common patterns like interchain transfers of tokens but developers can freely invented their own mechanisms for interchain interaction.

Cosmos: Because Cosmos is a network of potentially faulty state machines rather than one unified state machine, Cosmos will support sending proof carrying objects between chains rather than arbitrary chain to chain function calls. We are planning a major communication push around our compositional model for Q1 2019 but so I’ll be brief here. Initially, Cosmos will support sending static objects between chains and objects with 1 mutable parameter(their owner). This is sufficient to implement compositional patterns like Summa’s cross chain auctions or transfers of tokens between chains. I’ve long been interested in research on languages that can express more complex relationship between proofs and mutations of complex objects like Agoric’s Jessie and Kadena’s Pact and I expect that something in that domain can express virtually any financial primitive within the constraints of Cosmos. By embracing these constraints, Cosmos provides unlimited flexibility for developer designing their Blockchain state machines, a limitless ecosystem and total freedom to experiment with mechanism design.


#4

Thanks for responses Meat With Dreams!

There is a bit of “have your cake and eat it too” Engineering resources are finite. As far as I can tell from poking around in the Substrate repo. Polkadot’s main focus right is prioritizing a system where many chains share the same security and availability model and thus get the arbitrary contract to contract call api. Cosmos’s main focus is hetergeneous security and object passing api. At the heat death of the universe, I would expect future blockchains to incorporate the best of both systems.

Fundamentally this is an article about worldview and priorities not constraints.

There is an idea that instant finality makes Tendermint slow. Tendermint has comfortable done 2-3 seconds blocktimes for months over 100+ independent validators on 3 continents. This is with a lot of low hanging fruit unpicked for performance optimization.

The benefit I can see for GRANDPA is that GRANPA will be live under conditions where Tendermint will halt. One of the biggest open questions that we answered this year for Tendermint is “will the network remain live with a group of strangers running validators all over the world?”. Testnets are an extreme test of this because there is minimal economic incentive to run a testnet. Our testnets haven’t experienced any problems with liveness.

An algorithm like GRANDPA might be more resistant to censorship attacks.

As I mentioned before, you either prioritize a compositional model that assumes all chains share security or one that doesn’t. I don’t think any ecosystem will really do both for ~5 years.


#5