UPDATE: Join us the Web 3 Chat discussion: http://tiny.cc/web3chat, #polkadot channel. You can also ask questions on the Web 3 subreddit

Disclaimer: all opinions on this blog are mine and mine only. I write about projects I enjoy. Back in December 2013 I wrote extensively about a little-known project called Ethereum, which has often been misunderstood but worked out quite well. Others projects I have covered had their heart in the right place but missed the mark despite on-boarding some of the brightest minds in the field. My opinion does not represent the view of my employer, investors or partners. Finally, nothing written here should be construed as investment advice. And with this out of the way…

Introduction

In my previous post, I highlighted the importance for both startups and corporates to stay chain and protocol agnostic at a time when fragmentation in our vertical is taking place at an exponential rate. We are at least years away from any form of generally accepted Dapp standardization in the same fashion *AMP is generally accepted as the archetypal model for web service stack as of 2017.

The need for cross-chain communications has been present from day one, a need best exemplified by the original BTC Relay project, dating back mid-2015. Yet, if you think this blog post was about 2-way pegs and transferring value between chains, then this is exactly why you need to continue reading. Heterogenous multichain solutions are not just about ‘making chains talk to each other’, the way Vitalik’s Ethereum whitepaper was not just about a ‘better bitcoin’.

Let’s dive into a vision of a fully decentralized “federation” of chains, allowing both open and closed networks to have trust-free access to each other: not just for exchanging value, but also for processing data. Think killer apps which leverage both holy grails of scalability and privacy, but also benefit from pooled security and trust-free interchain ‘transact-ability’.

On a side note… If you’re still not sure why such a solution needed, it’s probably because you haven’t yet hit the barriers of blockchain development. ‘ICOs’ and whitepapers are a dime a dozen these days, but in the corridors of conferences and at the offices of the companies actually building Web 3 solutions, blockchain maximalism is long dead. I think due to unprecedented price speculation, many hope ‘everything’ could be built on a single platform.The fact of the matter is that anyone serious about building Dapps will tell you that such an all-encompassing platform simply doesn’t exist.

Polkadot in a nutshell

Polkadot is a creative commons protocol specification and a free and open source licensed project. It is a complementary protocol that will allow for different blockchains to leave their silos and interact seamlessly.

Back in November last year, the Polkadot team released with surprisingly little fanfare their whitepaper describing a mechanism by which not only value, but also data could be shared back and forth across existing or future chains (dubbed ‘parachains’). In terms of use cases, we can imagine end users participating anonymously in an Ethereum smart contract driven token sales using Zcash coins, or encouraging the development of entirely new state machines more suitable for IoT scenarios. For example, such a state machine could present weaker guarantees on transaction ordering while increasing transaction throughput. These new chains could then settle their balances on the Ethereum public chain.

I think the Polkadot paper did not register on many people’s radars at the time of its release, simply because of the lack of marketing (Parity Technologies has a reputation for not engaging in the Twitter or Reddit ‘games’), the deafening noise from the bitcoin-heavy conversation regarding two-way pegs, and the lack of matching token sale regrettably deemed so necessary these days to attract attention of any kind.

How does Polkadot achieve its goals? As Peter Czaban would say, “it’s a minimal global consensus layer, a future resistant way of enabling all autonomous agents to collaborate using rules executed by arbitrary state machines”. But what about the rest of us that speak actual English? Well, what it does is allow for an easy solution to scaling by allowing multiple chains to share the same security layer without having to accrue mining resources themselves (the main challenge to the simplest chain scaling solution), AND without having to resort to merge-mining either.

In other words, Polkadot is an innovative way to connect the hundreds of different technologies out there to each other. An “Internet of Blockchains” might be an adequate albeit slightly crude description.

A better one might be, to quote Sunny Aggarwal, “a pluggable consensus network” — essentially each parachain gives up sovereignty in deciding chain finality in exchange for being able to talk to each other as part of a constellation of blockchains and other consensus at scale solutions.

What Polkadot isn’t

Polkadot is not another Turing complete blockchain, even if it comes from the main developer of Ethereum, Gavin Wood. It doesn’t run code, nor is it a good means to pay for groceries.

It’s not a particularly new concept, even though it’s unique in its early implementation. The Pokadot paper does a good job in that regard, crediting the work by Max Kaye as well as Chain Fibers dating back 2014.

It’s not finished either. Parts of it are PoC phase but most of it won’t be released for many months and potentially even years after the project is funded — making it open to your comments and suggestions.

It’s certainly not ‘magic’. Once your wrap your head around how it relays data from A to B it’s actually relatively simple to understand and eventually master.

And finally, it’s not a competitor to Ethereum, Bitcoin, or any other chain — in fact, it’s even compatible with other cross-chain solutions such as Cosmos.

Polkadot vs…

When I helped launch Ethereum, I spent much of time comparing it to other platforms in order to position it. Looking back, things were much simpler then — considering how fragmented the landscape has become, this section will form the lion’s share of this first, introductory blog post.

Vs. Cross chain solutions

First off, let’s check how Polkadot compares to Cosmos and other ‘existing’ cross-chain solutions. These are considerably simpler from a design standpoint, and therefore less likely to have bugs and/or delays in their deployment. But simply put, Cosmos and others focus on value transfer between chains. Polkadot, on the other hand, is more generalized to allow for cross-blockchain interactions between disparate smart contracts.

There are many uses cases, especially in the IoT space where my company Slock.it operates, where the main challenge is transferring data and executing function calls between platforms. For example, I might want to find, from an Ethereum smart contract, the GPS coordinates of a given object that’s registered on Hyperledger.

The second benefit of Polkadot over these solutions is its shared security model. Writing connectors is one thing, but building a new, vertical specific blockchain is difficult — very difficult in fact. As a developer I’d much prefer to focus on delivering value add to my customers in the form of feature set, and not having to worry about hitting the correct threshold of mining power. Cross chain solutions cannot help me here, but Polkadot can. That’s not to say the two are at odds — in fact, Cosmos developers recently announced they were looking forward to work with the Polkadot team, demonstrating a much needed healthy mindset of cooperation, not competition.

Vs State Channels

It’s no secret I’m a big proponent of state channels. How does Polkadot compare to projects such as the Raiden network? Well, state channels hold a major requirement for deposits to be in place if you want them to be really secure. This works great for projects such as Slock.it where deposits are intrinsic to our business model, but it doesn’t always apply to every vertical. With Polkadot, not only you do not have to put up a deposit to access a parachain, but nothing stops you from also build state channels on top of parachains. State channels also have limitations in terms of extensibility as a whole where Polkadot does not, since it can theoretically support any state transition logic.

Vs ‘Enterprise Chain’ solutions

But wait, aren’t all these exciting features going to be part of enterprise chains anyways? After all, EntETH, Hyperledger, Qtum and many, many others have promised both scalability and privacy as part of their consensus at scale mechanisms. Their limitation lies in how they intend to implement these mechanisms. Neither hiding data behind a VPN, nor arbitrarily limiting access to the network by operating private nodes or ‘permissioned ledgers’ are in my view solutions to scalability and privacy — they are merely temporary workarounds. Note that there’s nothing wrong in wanting to operate a private chain — in fact, permissioned solutions are probably today’s implementations of choice in the corporate space — but Polkadot will provide trust free data exchange between these solutions, extending their reach and functionality rather than competing with them directly.

The real advantage on offer here is that it allows for a Fortune 500 company to opt for a particular solution such as Hyperledger while another opts for say, QTUM. By pledging to use Polkadot, both corporate giants can select a solution — today — with the confidence their products will eventually be able to talk to each other tomorrow.

Vs Ethereum ‘2.x’ and other EVM-based solutions

One very important point to keep in mind is that Polkadot is not competing against Ethereum, or any EVM-based solutions for that matter. There are, of course, some shared goals with these projects, including the use of PoS technology for example. It’s also very likely we’ll see innovations from one project such as Ethereum Serenity ‘flow’ to Polkadot and vice versa. Think of Polkadot as a “a blockchain platform”, meaning a platform for developing, experimenting with, deploying and maintaining other blockchains.

Vs BaaS-like projects

Ah, the controversial BaaS, or Blockchain as a Service (such as Microsoft Azure’s Bletchley Park). Some question why one might want to negate every single advantage of running Blockchain code by deploying it on someone else centralized network, but the reality is that many companies will be happy to use cloud-hosted or BaaS products regardless.

It could even be for good reasons — for example, BaaS might be incontournable if we wish to keep up with the transaction throughput of an AirBnB or Uber, offer simpler key management to end users, or even permit simpler interactions with existing SaaS solutions. To quote Gavin Wood on the matter, “The critical thing is that optionality be retained — similarly by Linux being open source, you keep the optionality to audit and understand the codebase; this was instrumental in gaining its adoption in Android and by large enterprises such as IBM.”

Vs exotic consensus mechanisms

There are dozens of options for consensus mechanism in the wild that transcend traditional blockchain constructs. Let’s take IOTA’s Tangle for example, which offers neither blocks nor chains, but an eventual consistency mechanism instead. It allows for the scaling of simple token value transfer, not smart contracts, and its eventual consistency is applicable to certain scenarios but not all.

Factom goes even further and does away completely with the state transition concept altogether. However, the very utility we are after for Dapps results from the output of such a shared state machine. It’s a solution to scalability issues of course, but it doesn’t solve the problems we face as Dapp developers.

Compared to these ‘non-chain’ chains, Polkadot co-secures chains, allowing for some substantial degree of scalability (dozens to hundreds of chains all running in parallel all feeding off the same overarching security mechanisms) — and it also provides some provision for interaction with existing chains of differing consensus mechanisms such as Ethereum and PoA, plus, by virtue of the EVM meta-protocol layer, a reasonable expectation to be able to integrate more as they come along.

Vs off-chain compute services

Projects such as Truebit or Oraclize.it offer auditable off-chain compute services. Again here we’re looking at cooperation, not competition — in fact, any solution that works with Ethereum will work with Polkadot, including Golem.

As you can probably tell by now, Polkadot is not limited to connecting chains to each other, but can also be used as a relay between arbitrary information providers (including the very interesting Town Crier project) and consensus at scale protocols.

Vs Sidechains

You’ve of course heard about 2-way pegs, side-chains and merge-mining before, in fact, by now this stuff sounds borderline prehistoric considering the breakneck-pace at which technologies like Ethereum have evolved in the meantime. Regardless, Polkadot shares the general, loose idea of extensibility of side-chains, but unlike side-chains one its main goals is pooled security across chains, whereas with side-chains you as a developer are expected you to build up a community of miners secure enough to protect the asset you issue.

Vs ‘overlay’ Blockchain Protocols

Some ‘overlay’ (or ‘meta’) blockchain protocols such as melon — build on existing chains — share some synergies with Polkadot in that they will be most effective if it is possible for them to trustlessly interact across chains. In that sense, Polkadot as a trust-free cross-chain interconnect would be beneficial to their vision.

Vs “Roll your own”

Is any of this necessary at all? Couldn’t you just create local adapter on virtual machines and connect chains manually? I’ll include this one because it is often asked. Of course, given the right amount of time, skills and resources, anything is possible to ‘roll out on your own’, including entire operating systems. That doesn’t make it wise or practical. In the context of Web 3, Polkadot makes it easy to have private chains, experimental blockchains and leverage existing blockchains trustlessly and scalably — to roll out one’s own version of such framework, keeping up to date with the dozens of options out there and make sure it’s entirely secure is no easy feat, and would require years of development better spent elsewhere (such as building an amazing end-user product!)

Another point, Polkadot maintains decentralization throughout whereas ‘black boxes’ converting from chain A to chain B re-introduce centralization, single points of failure and vendor locking. I can’t really think of an instance where this would be preferable over using a FLOSS project.

End of Part 2

That was a long post, but I feel it was necessary to set the scene before we dug deeper in the platform. Next post, we’ll go through the Polkadot feature set and its technical aspects: how it actually works, how it relays data back and forth between chains, and we’ll briefly touch on its potential governance mechanisms.

Thank you to Peter Czaban, Ryan Zurrer, Gabriel Beeby and David Peyronnin and the whole of the Polkdadot Watercooler Riot Channel for their valuable comments and feedback writing this article.

Next blog post should come out in a few weeks. In the meantime, if you have questions, join the Web 3 slack at http://tiny.cc/web3chat, there are already hundreds of us hard at work building the next web!