Thread by @AlexSkidanov

1/ An authoritative tweet storm on @cosmos vs @polkadotnetwork shared security / atomicity.

Before we go, a reminder that you can learn more about the technical intricacies of the protocols in our whiteboard sessions with them:

2.1/ [Validators assignment and Runtime] We have a hub, and we have heterogeneous (as in, with different runtimes) spokes (zones / parachains). There's a set of validators on the hub that want to validate the spokes. How do they get a binary with a particular runtime?

2.2/ In Cosmos validators choose whether to validate a Zone based on whether they find the economics of the zone meaningful. If they like the Zone and choose to validate it, they find a way to download a binary for the zone, and then join to validate it.

2.3/ In Polkadot validators get assigned to the Parachains, and thus must have a way to automatically get the runtime. The runtime is provided as a WASM bytecode, that is stored on the Relay Chain (Polkadot's hub).

3.1/ [Validators rotation] In Polkadot the validators rotate between chains relatively frequently, while in Cosmos they are largely statically assigned. Thus, even a very slow adaptive adversary would be able to corrupt zones with few validators.

3.2/ Short to medium term I anticipate most of the zones being validated by most of the Hub validators, but longer term it will no longer be the case, and the Zones that have only a small subset of the Hub validators will be rather vulnerable.

3.3/ Importantly, in Cosmos if a Zone different from the one on which I have my assets gets corrupted, the Zone on which my assets are stored is never affected. In Polkadot it is not the case, and it brings us to the biggest and most important difference.

4.1/ [Atomicity] Say a spoke is adaptively corrupted and an invalid block is produced and finalized to the hub.

This is certainly a possibility, validators' first and foremost goal is to make money, so assuming that the majority of them are not corruptible is unreasonable.

4.2/ In Cosmos if a BFT consensus is reached on a block by the Zone's validators, and such block is snapshoted to the Hub, it's canonical. Hub has no concept of an invalid state transition, and if later it is shown that the block was invalid, no rollback will occur.

4.3/ Importantly, it means that any assets that were transferred from such zone to other zones will not be brought back.

Consider an example with two zones, on the first zone Alice and Bob each has 100 wrapped DOGE tokens, and Eve has none.

4.4/ Say then Eve colludes with validators and they create an invalid block which assigns all WDOGE to Eve, and she then sends them via IBC to Carol, who is an honest merchant on another Zone, and Carol provides the service to Eve.

4.5/ In Cosmos the Hub maintains the balances of the tokens in each Zone, and from perspective of the Hub Zone A has no more WDOGE. It is up to the Zone how to deal with the invalid block in the past, but they cannot reimburse the tokens back to Alice and Bob.

4.6/ It is considered to be a failure on the Alice's and Bob's end to use a Zone without ensuring it has sufficient security.

It is similar to how if Ethereum Classic rolls back, Ethereum will not rollback to keep any "atomic swaps" that occurred in the meantime atomic.

4.7/ It is drastically different from how Polkadot would handle the same situation. Consider a similar scenario. This time let's also explicitly have the Relay Chain on the diagram.

4.8/ In the same scenario, where an invalid block was snapshotted to the Relay chain, once it is detected (by the means of a fisherman raising an alarm), the block on the Relay chain that snapshotted the invalid block on a parachain also becomes invalid.

4.9/ So do any blocks on other Parachains that depended on that relay chain block. This causes a system wide reorg. Alice gets her WDOGE back, but this time Carol loses them.

4.10/ Thus, in Cosmos for as long as a participant is sure their particular Zone is not corrupted, any assets they have are final, and any block in the Zone that has 2/3 validators signing on it is final, which might result in a loss of atomicity if some other Zone is corrupted.

4.11/ In Polkadot all cross-chain TXs are atomic, but corruption of a single parachain can result in the entire system reorg.

It is a fundamental dilemma in sharding under an adaptive adversary, read more here: near.ai/shard2

5/ In the meantime, we at @nearprotocol are actively researching how to reduce the probability of adaptive corruption. Here's a talk I gave a month ago with more details, and a sneak peak at our approach.