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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- Expected number of blockchains in the ecosystem?
Polkadot: ~1000
Cosmos: Unlimited