troubles.md -

A high-level view of low-level code

Comparison of Inter-Blockchain Communication Technologies

A question we often get asked about Polkadot is how it compares to other blockchain technologies that nominally share the same goal. Blockchain interoperability is rightfully a hot topic right now, with many projects large and small in development. Many people in the blockchain space have come to the realisation that the siloing off of different chains leads to sluggish innovation - since the security of a chain is directly proportional to the number of users it has, it’s hard for new chains to get off the ground even if they have many interesting and useful features. Plus, it means that if an application wants to leverage a certain currency it must either have a measure of centralisation or be built on the application platform offered by that currency. Interoperability can solve these problems by having some measure of shared security, and by allowing users to easily convert coins between chains in a secure way (without trusting a third party). Some of the larger projects in the space that are attempting to solve this problem:

They are not quite solutions to the same set of problems - inter-blockchain communication (IBC) is a wide field and it’s not necessarily possible for any one product to solve all the problems within it. However, they do share some goals. All of them attempt to allow you to transfer tokens between existing chains in some way or another, which is understandable since that is the most immediate user-facing benefit of IBC. Many users are dissatisfied with existing exchanges and they’re one of the few remaining components of the blockchain ecosystem with no good and well-adopted decentralised solution as of yet. Not all users can use centralised exchanges, too, because of legal issues. Some of these chains attempt to solve problems that are separate from IBC, but I’ll skim over those because it’s not relevant to this discussion.

A quick summary:

There are 3 broad categories here

I’ll cover these technologies based on different use-cases, I will try to give each product a fair shot but keep in mind that I work for Parity Technologies, the team behind the development of Polkadot, and as such my knowledge of Polkadot is much deeper than my knowledge of these other technologies. I try to be a fair propagandist but I can’t cover what I don’t know. Please send all complaints and corrections to @meatwithdreams on Twitter.

Use case 1: Generic Message Bus

One possible use case of IBC is just generic communication between decentralised technologies - the kind of message bus that something like RabbitMQ might be used for in the centralised world. This means that any blockchain technology - not just cryptocurrencies - can communicate with each other seamlessly. This might be useful for something like a decentralised market that wants to use other currencies for payment instead of rolling its own. Obviously this also allows one to move tokens between cryptocurrencies.

Cosmos and Polkadot have general communication in mind and don’t necessarily mandate that the messages that are exchanged be transfers of value, although I think that Polkadot more directly addresses this concern for reasons that I’ll get into soon. Wanchain and ICON only intend to be financial exchanges and don’t attempt to tackle non-currency decentralised information exchange at all, which is not necessarily a bad thing. Aion does allow arbitrary information exchange but seems to not care too much about how much transactions cost - its hybrid PoW/PoS system can only inflate transaction fees by increasing the real-world resources required to create a block, not to mention that bridges have no shared security1 and so to get secure and decentralised inter-chain transactions you would realistically either have to roll your own bridge (in which case, why bother with a decentralised bridge) or go via some more popular chain which can inflate costs since the more popular chain will by definition be under a greater load. So you can send non-value-bearing messages on Aion but I don’t see how it could be as efficient as Cosmos or Polkadot.

The reason I think that Polkadot tackles this better is simply because nowhere in the system does Polkadot address tokens at all. The only token that must exist anywhere on the system is Polkadot’s native DOT token, whereas Cosmos Hub appears to be aimed at tokens first with arbitrary messages being a second-class citizen. They do, however, seem to realise this limitation and intend to address it further down the line.

I put this use case first because it’s probably the least immediately-pressing need out of all the needs addressed here. Most blockchains nowadays are cryptocurrencies, but one would hope that with ergonomic and efficient blockchain toolkits like Parity Substrate and Cosmos SDK we will see more use of blockchains for non-currency use cases. Obviously this is a biased opinion - I know Polkadot a lot better than Cosmos and writing this article has been funded by the developers of Polkadot - but I believe that Polkadot more directly addresses non-value-bearing communication.

Use case 2: Decentralised Exchange

Probably everyone’s immediate thought when it comes to IBC is a decentralised alternative to Shapeshift. An exchange that is totally decentralised could be resistant to deliberate manipulation or censorship.

Polkadot has a pretty weak showing here. It has a shared security model and aims to have low fees for transferring data between chains so it could make for a very good foundation for a DEX, but as far as I know there are none in development or even in the planning stage. Parity Substrate, an ergonomic blockchain development platform, could make the creation of a DEX on top of Polkadot simple and efficient but that doesn’t change the fact that as of now there is no DEX-on-Polkadot project in development.

Aion, too, comes out poorly here. It’s a pure communication platform and does not attempt to supply a DEX on top. Its bridges do not have shared security, which means that it’s possible for bridges to smaller chains to monopolise transfer to the DEX and increase fees, not to mention that they could censor transactions too. You could build a DEX on the Aion chain itself using a smart contract, but Aion’s smart contract platform implementation is extremely suspect2 (see the linked footnote for part of my analysis of Aion’s FastVM). I might write up a whole new article on problems that I have with Aion’s implementation but for the sake of this article I’ll ignore the implementation and only cover the fundamental ideas behind Aion itself in order to give it the best shot possible.

Cosmos does intend to supply a DEX but it doesn’t have an implementation yet. Having said that, their analysis of the issues that one might run into while creating a DEX on Cosmos is thorough and I am convinced that they have a competent team that could execute the creation of such an exchange. The vague design described in that document is both simple and elegant.

Wanchain and ICON are both exchanges first, which very little effort given to arbitrary communication. ICON is a large, complex beast that appears to care first about maturity, reliability and fostering a community of trust rather than attempting to build an exchange that is totally trustless. One of the ways they try to create this maturity and trust is with the concept of an “I-score”.

The I-score is a scoring mechanism that takes many variables into account and outputs a single number that represents a node’s trustworthiness. The I-score controls everything on the network - block rewards are given not based on stake or on creation of a block, but based on your I-score ranking. You can only become a member of ICON’s governance by maintaining a high I-score. A problem here is that ICON’s whitepaper makes absolutely no attempt to explain how this is measured. They mention that it’s calculated with “deep learning”, but how is the training done? It appears that (at least to start with) the I-score will use an offline-trained neural network trained, of course, by ICON. ICON controls the initial neural network and their whitepaper makes no attempt to describe how on-chain neural network training would work; one must assume that they control the continuing training too. Machine learning isn’t magic and it certainly isn’t unbiased - the input and the training parameters are fundamental and can be manipulated to optimise for a scoring mechanism that benefits them.

I should say that I’m not accusing the ICON Foundation of doing such a thing, but this is anathema to the whole point of decentralised systems. If you have to trust ICON to correctly train their neural network then why not just trust a centralised exchange - many of which have a longer and more reliable history of trustworthiness than ICON does.

Wanchain, despite having the dorkiest name in blockchain, has the lofty aspiration to displace banks entirely. It also seems to be the only one of the technologies covered in this article that has a customer-facing application that you can use today, all the others still being in development or only in use by partners. The Wanchain Foundation hopes to displace existing financial products by supplying a fully-featured smart contract platform based on Solidity and the EVM, assumably this choice was made to allow Wanchain to leverage the existing Solidity community and Ethereum’s ecosystem of financial products like Bancor and TheDAO. The whitepaper states that their hope is to allow Wanchain to be used for loans, currency exchange, deposit negotiation and many other roles that are traditionally filled by traditional banks. I have some issues with the choice of reusing the EVM and Solidity (which I’ll get into in my review of these networks’ smart contract platforms) but I can definitely understand why it was made. As far as I can see, Wanchain’s USP is to be “Ethereum Done Right”, implementing proof-of-stake consensus and inter-chain communication on top of a blockchain that fundamentally has the same state machine and runtime as Ethereum does. Even its cross-chain communication works almost precisely the same as our own Parity Bridge, although I have no way to know if their implementation was inspired by ours or if it was independently invented. Wanchain is a great example of stealing good ideas from existing projects without trying to reinvent the wheel and I’d say it probably has a good chance of getting good traction as long as its implementation is high-quality, although it’s quite a narrowly-targeted technology that doesn’t really attempt to do anything new.

Use case 3: A “Normal” Cryptocurrency

All of the chains mentioned here get efficiency, finality and transaction-time improvements over most existing popular blockchains by avoiding proof-of-work (PoW) security in favour of proof-of-stake (PoS)3. I don’t have enough time or space to get into precisely why that is - there are plenty of articles explaining the difference out there - but just take my word for it for now. The ugly duckling here, again, is Aion. Aion does use PoS but it states that only “60%” of the blockchain will be secured using it, not going into further detail as to what that means. The other 40% is secured with a novel PoW algorithm that they call “Proof of Intelligence”, essentially using neural network training instead of hashing. This seems to be for no good reason relative to the security of the network, as far as their whitepaper states it’s just to incentivise creation of specialised neural network training hardware. If that’s the case, one wonders why they don’t just implement this PoW as a separate blockchain or to just use their own personal Aion token wealth to pay for third parties to develop this hardware. Polluting the blockchain implementation with it just seems to serve to lower the efficiency of the network for everyone for the sake of incentivising creation of hardware that most of them will never use.

Cosmos Hub’s token (the Atom) and Polkadot’s token (the DOT) are intended really for staking only and don’t have much intention of being used for real transactions, although since they are and must be value-bearing there’s no reason why they couldn’t be. Wanchain and ICON both seem to have the intention of being used for payments and other financial products like loans - Wanchain especially targets this exact use case - but no one network really comes out on top in this regard.

Use case 4: An Applications Platform

This is going to be the most biased-sounding section, since I really do think that Polkadot comes out significantly ahead of the others in this regard. I’ll try to explain my thinking, though, and hopefully I convince you that this isn’t just propaganda (it is propaganda, but importantly it’s not just propaganda).

Wanchain is just Ethereum Plus. If you understand Ethereum’s pros and cons then the same is basically true for Wanchain. I definitely understand their choice here - no need to reinvent the wheel if you’ve already got a community of developers and a virtual machine implementation tailor-made for blockchain - but the EVM has many problems. It’s inefficient, and that leads to real problems even without time-to-execute being a factor. Lots of custom instructions and magic runtime-implemented functions have to be added to the EVM interpreter to get around the fact that these functions cannot be implemented in Solidity (even in inline EVM assembly) without massively increasing the gas price of the executed function. The inefficiency also means that any language built for the EVM must be very low-level and closely reflect the semantics of the EVM itself, since if an abstraction has a cost then that directly causes your users to pay a noticeable amount more to use your product. This also leads many developers to resort to inline assembly, completely disabling the already-flimsy safety rails provided by Solidity. That’s not to mention that the only decently-supported language that compiles to EVM is Solidity, and I don’t have time to get into all the complaints about that language but suffice to say that it’s difficult to write safe, ergonomic or efficient code using it.

Cosmos Hub avoids being an applications platform entirely. As far as I can tell it only supports token transfer and communication and does not even attempt to provide a scripting language. Their philosophy is that smart contracts should be supplied by connecting to an external chain that supplies the smart contract logic, a philosophy that I agree with. Unlike Polkadot, Cosmos does not run chain verification logic on the Hub chain itself and therefore it does not already have an included runtime that can be co-opted for applications.

ICON glosses over dApps entirely in its whitepaper. It states that dApp code will not be included on the blockchain itself but will be downloaded from a separate storefront with only the application storage stored on the ICON blockchain. No information is given as to whether the applications will run on a custom VM or whether the software will be a normal application (the latter option essentially removing the point of having dApps entirely since there’s no way to verify that everyone is running the same code). It’s also unclear precisely how the dApp store will work since it’s given barely a paragraph in the whitepaper.

I don’t want to keep kicking Aion in the teeth but the truth is that its application platform implementation is extremely questionable. They state that the VM is “based on the JVM” but the only way in which it’s based on the JVM appears to be that their in-development scripting language is a strict subset of Java. I actually don’t hate this decision - it allows them to piggyback off tooling development for the best-supported programming language in the world - but their VM appears to just be a fork of an EVM implementation with the word sized reduced from 256 to 128. The decision to change the word size is absolutely baffling. They state that it’s for the sake of performance, but why on earth would you reuse an existing virtual machine if you intend to change its semantics in a way that breaks most code and most assumptions in existing tooling? Why a custom Java-based language that appears to only be available for Aion, rather than Solidity? Java does not at all expose the EVM’s semantics, and this is vital for a EVM-based application layer, as I covered in my review of Wanchain’s application platform. Their precise implementation of this virtual machine is also questionable2.

Ok, this is where my propagandist hat goes on, although I do genuinely believe that Polkadot’s application platform is world-class in the blockchain space. The Polkadot VM uses WebAssembly (Wasm) for its VM instruction set, which means you get an instruction set with world-class support from compilers like LLVM and GCC. Although we can’t reuse the excellent Wasm JIT compilers created by the V8 and SpiderMonkey teams4 we still get many performance wins over using the EVM even without a JIT at all since Wasm is very efficiently executable. Since Wasm closely reflects the execution model of real machines, much more languages can and do efficiently compile to use it. Rust, C, C++, C#, TypeScript, Java, Haskell, Idris, Purescript and more all can compile to Wasm and so can be used to write programs on the Polkadot VM. On top of this, the required interface is minimal and expressed in terms of C - so creating ergonomic and idiomatic libraries in each language to interface with Polkadot should be as easy as writing a library callable from C in the given language. Polkadot doesn’t just allow you to create dApps, but whole blockchains with relative simplicity. Although Wanchain is the closest to Ethereum in terms of implementation, I’d say that Polkadot is the technology that best continues the legacy of Ethereum, taking it to its next logical step.

Conclusion

Hopefully that was as fair as I could make it, I personally think that Polkadot and Cosmos come out on top overall but they both target developers first rather than investors/traditional corporations (ICON) or end-users (Wanchain) and since I’m a developer I can more easily see the benefits. Polkadot and Cosmos both have upsides and downsides and although I’d say that Polkadot is overall the more practical technology I can’t pretend that Cosmos doesn’t have some great tech behind it, and I wish the team and technology all the best. I’m excited for all of these technologies to come to maturity and start to see some real-world use and I hope this article has given you some insight into what project might be more useful for what use case as they do.

  1. Shared security means that the security of a given bridge is not a function of the number of nodes participating in that bridge, but a function of the number of nodes on the network total. Polkadot has this since parachains (the “spokes”) must supply a valid state root to the relay chain (the “hub”), and it appears that Cosmos with Cosmos Hub has a similar system. It’s not at all clear how ICON (TODO: Wanchain?) works in this respect. ↩︎

  2. One problem with the Ethereum Virtual Machine (EVM) is that it’s slow. Really slow. It’s an interpreted language, and not one built for fast execution at that. One common technique for increasing the speed of interpreted languages is to use a “just-in-time” (JIT) compiler, which compiles the language to machine code as you execute it. This can give speedups as much as 100x depending on the workload. There does exist a JIT for the EVM, but it’s not used because JITs are extremely dangerous. Any non-determinism in the compiler - even in the most obscure edge-cases - can be exploited by an adversary to force a hard-fork; not to mention that even if you produce seemingly-identical machine code even switching from 32-bit to 64-bit can cause different behaviour. Aion’s FastVM is a fork of the EVM JIT and as a result uses LLVM for compilation. This is, shockingly, even more dangerous than rolling your own compiler. LLVM has many sources of nondeterminism, it even has the concepts of “undef” and “poison” which are specifically made to allow the optimiser to introduce nondeterminism into the compilation process in order to improve performance. On top of the deliberate nondeterminism there are also outright bugs in LLVM’s implementation, some of which go unfixed for years because LLVM is not made to be used for creating code that runs deterministically and equivalently on different machines. Another problem with LLVM’s optimisations is that almost all useful optimisations are non-linear by definition - i.e. there exists some input where optimising that input repeated 10 times takes 100 times the amount of computation power as optimising that input repeated only once. These are called “compiler bombs” and they are a problem since now you have to measure gas price for the compilation process as well as on the runtime itself (Polkadot intends to circumvent this with its WebAssembly runtime by creating a non-optimising linear-time compiler since if the compiler is linear-time or better you can price compilation by input byte and not by runtime). If you want to hear more about my complaints with Aion’s smart contract platform, and why LLVM and JIT compilation is a bad idea, contact me on my Twitter account. ↩︎

  3. Efficiency meaning that less energy and CPU time is wasted relative to a centralised system; finality meaning that you can be 100% certain that a block cannot be reverted after a certain point; transaction time meaning that a transaction can go from being initiated to confirmed much faster. ↩︎

  4. We can’t reuse V8 or SpiderMonkey since they’re not built for determinism - there’s no way for us to verify that they produce the same behaviour on every architecture. The best we could do is fuzz a given version and file bugs where they diverge, but that must be redone for every new version and there is no reason for the V8 and SpiderMonkey teams to work on our determinism issues since for the most part they don’t affect them. Not to mention that both JITs and optimising compilers (V8 and SpiderMonkey are both optimising JITs) are independently complex beasts and we need whatever compilation scheme we use to allow us to price compilation easily. I may more deeply cover the issues with creating a blockchain virtual machine in a later post. ↩︎