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.
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.
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.
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.
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.
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.
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.