Web 3.0 Revisited — Part Three: “Polkadot: How it could integrate with 4 blockchain networks — and what’s in it for us as developers”.
--
Disclaimer: all opinions on this blog are mine and mine only. My opinions does not represent the view of any of my employers, investors and/or partners. Last but not least, nothing written here should ever be construed as investment advice.
Introduction and thanks
In my previous post, I described what Polkadot was and, perhaps more importantly, what it wasn’t. Today I will describe how it works at a high level, and help you understand cross-chain transaction relaying.
The more complex aspects of the technology, such as Polkadot’s POS consensus algorithm and its relay chain specifications will be covered in later posts.
Thanks to Peter Czaban, for spending the time imbuing me with his technical expertise and of course to Gavin Wood, for having written a paper that’s both clear and concise while allowing me to paraphrase some of his Polkadot riot channel comments. Thanks also to both Rob Habermeir and Edward Thomson for taking the time to review this document.
Benefits summary
Firstly, here’s a quick lexicon reminder: a “parachain” references any existing or future blockchain connected to the Polkadot relay chain. And a “state machine” is simply the brains or “CPU” of any given chain (in the case of Ethereum, that would be the EVM). State machines aggregate then process the changes engendered by each transaction broadcasted on the network. This is why you may have sometimes heard of “state transition functions” — essentially they modify the “state” of a chain to a new one, taking into account what has been updated, added or deleted.
Any message can be sent from one parachain to another through the Polkadot relay chain. These messages can, for example, trigger a smart contract method. These methods, in turn, can then accomplish anything the parachain’s state machine is capable of.
These could include, depending on the parachain’s capabilities:
- Linking private to public chains (e.g. IBM Hyperledger contracts calling others contracts living on the Ethereum public chain and then proceeding based on the returned results)
- Allowing cross chain value transfers (e.g. sending Zcash to the bitcoin network, or ether to the bitcoin network)
- Smooth migration to newer/better chains : tired of current chain? Just “transition” to the new kid on the block (chain)
- Access to the execution of complex operations currently unavailable on existing platform due to constraints such as missing support for floating point arithmetic operations
- Direct access to oracles and other authenticated data feeds for smart contracts
It’s very important to understand that different state machines can be used for different tasks:
- Some have very small state proofs making it easier to implement efficient light clients, often by using simple state machines limited to token transacting (such as Waves)
- Some make privacy simpler (such as Zcash)
- Some are designed with enterprise permissioning in mind (such as Iroha)
- Some might be better suited to formal verification (such as Tezos)
So, how does Polkadot actually work?
While the official whitepaper might remain arcane to many, the actual implementation is (thankfully) fairly easy to understand.
“Interchain transactions are effectively indistinguishable from standard externally- signed transactions.” In plain English, this means relay-chain maintainers called ‘validators’ manually move transactions from the output queue of the original parachain into the input queue of the destination parachain. The validators verify state transitions by running nodes of any given parachain. They are what’s called “bonded” — meaning they put down a security deposit which they’d lose if caught behaving improperly. That’s it for the basic concept.
This has an important implication: how many chains Polkadot ends up supporting is intrinsically linked to how many implementations of such relay contracts are developed. Some will require a modest amount of work, while other are far less trivial and may even only prove possible if the maintainers of the chains in question “play ball”.
To date, only parts of Polkadot have been built, and the project will probably only start in earnest once funded. For this reason, everything in this series of blogs must be considered as tentative only, since the actual implementation of Polkadot could change quite a bit between now and its release.
Let’s take a look at a four practical examples. “Chains” varies wildly in terms of implementation and therefore eventual compatibility, so I had to select an array of technologies that gave a broad overview of the opportunities and challenges ahead.
Ethereum-like solutions and Polkadot
Ethereum is the current gold standard for smart contract implementation and most enterprise private chains have selected it as their platform of choice. To interconnect Polkadot to Ethereum and all “Ethereum-like” chains is critical to the success of the project, as it would mark the beginning of an interoperability standard between Polkadot and most “permissioned chains” currently in various levels of development at Fortune 500 companies.
Polkadot to Ethereum transaction routing takes essentially the form of a Solidity smart contract called a “break-in” contract. The process of moving Polkadot relay chain data into Ethereum is incentivized through a payment disbursed to anyone forwarding a useful block with a valid header.
The currently estimated price of operating the Ethereum-forwarding bridge is approximately 540,000 gas per day. It’s therefore fair to say that the ongoing cost of this contract, especially as Ethereum is set to scale-up through its own R&D, will be reasonable (the Polkadot paper references USD $45 a year, which might be a bit optimistic but still give a good sense of scale). A single basic transaction forwarded over the bridge would cost around $0.11; additional contract computation would evidently cost more.
Various buffering and bundling transactions strategies will further help keep the costs down over time.
A lot of these performance and cost improvements depend heavily on the development of Ethereum itself. Should Ethereum introduce primitives such as Schnorr signatures as part of their Metropolis (or other) fork, we could see a near zero overhead above basic costs for validating the signature and executing underlying transactions.
The other way around (Ethereum to Polkadot) would work in a similar way. An Ethereum contract trying to contact a parachain part of Polkadot would use a ‘break-out’ solidity contract. That contract would take payment and use the ‘log’ instruction built-in Ethereum to prove its existence. Validity will be required from the validators running a full node, but lightweight methods are conceivable, which includes the use of third-parties submitting proof of invalid headers and punishing impostors.
Bitcoin-like solutions and Polkadot
While integrating smart contract enabled chains (especially EVM-enabled chains) to Ethereum seems to be a given milestone in the Polkadot roadmap, it would be foolish to ignore the granddaddy of cryptocurrencies and current total market capitalization leader, bitcoin.
Polkadot to Ethereum interactions rely on the fact that Ethereum is perfectly able to host both break-in and break-out contracts with a total of say, 144 validators rotated daily (note that number was chosen arbitrarily — as the more validators, the better). Furthermore, Ethereum’s constantly evolving nature leaves the door open for even more efficiencies in terms of validation through the introduction of new features via hard forks.
Unfortunately, the current bitcoin implementation has a far, far more limited feature set, with most clients accepting only multisig with a maximum of 3 parties. To extend this to a higher number, never mind 144, would require for bitcoin to update its protocol via a hard fork, something that has historically been proven to be difficult to coordinate. And while the regular introduction of new features are received positively within the Ethereum ecosystem (just check out this upcoming list of changes in Metropolis), hard forks are severely frowned upon in the bitcoin world.
This is a problem because the security of the deposits (“bonds”) scales with the rotation of the validators. One solution would be to operate with a smaller, but more heavily bonded validator set, but this would also require setting an upper limit to the amount of funds that could be exchanged between the two blockchains.
It’s not impossible that we will one day see a bitcoin parachain, as you probably know that a bitcoin fork of some kind is around the corner. It’s been said that the supporters of the bitcoin segwit fork are also open to new ideas such as Schnorr signatures, which would considerably simplify integration. Regardless, it’s likely we’ll see Polkadot to bitcoin integration take place only after the more straightforward Ethereum interoperability because of the cooperation required between stakeholders (read: the development communities).
IOTA-like solutions and Polkadot
Out of the many projects out there in the blockchain space, some including IOTA rely neither on blocks nor chain. This creates a set of challenges I thought would be valuable to study as it will help us gauge the limit of “chain” interoperability as we understand it today.
Paraphrasing Gavin Wood comments on the matter — the issue is IOTA doesn’t have any kind of globally definite state or transactions, and as such producing a light-client proof that a given transaction has happened is basically impossible. Since producing such proof is one of the two key requirements of Polkadot for integrating sovereign “chains”, it would be a non-trivial, and possibly impractical task.
IOTA isn’t a blockchain but rather a DAG. As such, there is no “parent hash” to track which transactions have happened. Essentially, you need to constantly track a globally-defined state as it becomes practically final. This absolute finality itself isn’t a great issue, as practical finality is enough (i.e. the “community defined” 120 blocks for Ethereum and 6 block for Bitcoin).
However, the globally-defined state is really important. IOTA only seems to give practical finality in fragmented and not-necessarily linearly-correspondent pieces.
The good news? There could probably be some form of workaround, including — as suggested by Gavin Wood — maintaining a separate merkle tree of all transactions of at least a certain amount of depth in the DAG and treating that merkle root as the global state.
Cosmos-like solutions and Polkadot
Polkadot is not the only project out there promising chain-to-chain interoperability, even though it’s currently the only one supporting remote smart contract method calls across chains, while other focus on the value exchange side of things. So, how would Polkadot interoperability solution integrate with another token exchange solution, such as Cosmos? Let’s have a look.
Paraphrasing Gavin Wood once again, we’ve seen little reason to believe Cosmos would ever connect outside of the “tendermint universe”. Polkadot, on the other hand, makes very few assumptions about its own parachains; a transition-specifying block can be independently and quickly verified in relation to a parent hash (a “light-client”) and there are some means for the validators to exert their collective authority.
That said, should Cosmos were able to make some sort of interconnection, then there’s no reason Polkadot would not. Cosmos is designed for interconnecting specifically tendermint token chains. It has some low-level messaging protocol, it’s trust-bound and this is heavily reliant on certain aspects of the tendermint model such as instant finality.
So, what’s in it for us developers?
As a blockchain developer, you will probably want to ‘mix and match’ state machine functionality as no chain currently support all features, no matter what their marketing teams might claim. I personally do not think this situation will change for many years to come, to the contrary, if anything I believe fragmentation will only be on the increase.
It’s likely that if you are serious about blockchain development beyond PoCs, you will find yourself in a situation where you’ll need to create you very own state transition engine, specific to your industry vertical (healthcare, legal, IoT, etc) with its own (sometime regulatory framework imposed) characteristics. This is where Polkadot shines.
Just like web frameworks allow developers to focus on their site functionality and not worry about the underlying “plumbing”, Polkadot gives you a playground for building state machines where both communications and state transitions have their security guaranteed by the whole Polkadot relay chain stake (the collective ‘bonds’). You won’t need to worry about acquiring a minimum threshold or a well distributed community of miners, for example, which in themselves are tremendous catch-22 challenges to overcome for fledgling projects.
Furthermore, Polkadot brings a single finalization mechanism for all chains. Finality simply means the point at which transactions up to that block in any given chain is considered ‘canonical’ — in other words, the “true”’ state of the chain at that particular moment. Some blockchains, like Ethereum and Bitcoin, define finality by forming a community/exchanges consensus around a certain number of blocks having passed. That number is roughly 120 for the Ethereum Homestead release and 6 for bitcoin. Other chains use different mechanisms and have finalization “built-in”.
When adopting Polkadot, parachains essentially give up sovereignty of finalization in exchange for the capability to interact with each other.
Last but not least, a standardized messaging queue is provided for you — all the routing is done as part of the validation process, which translates into an easy on-boarding for developers. Your transactions are guaranteed to be routed to the right parachain, no matter what.
Conclusion and next steps
This post was getting a (tad) too long, so I had to break it down into two halves. In the next post, I’ll publish a intermediary mini-FAQ based on all the questions you sent me to date (and there were a lot, thank you!). This will be later followed by a further blog post analyzing the POS model implemented by the Polkadot relay chain.
As usual, you can join the independent, community driven conversation on the Web 3 slack: http://tiny.cc/web3chat, #polkadot channel.
I hope this was useful. Note that you can also ask general questions on the r/web3 subreddit or make technical comments on the official /r/polkadot_io subreddit.
About the Author
Stephan Tual is the Founder and COO of Slock.it.
Previously CCO for the Ethereum project, Stephan has three startups under his belt and brings 20 years of enterprise IT experience to the Slock .it project.
Before discovering the Blockchain, Stephan held CTO positions at leading data analytics companies in London with clients including VISA Europe and BP.
His current focus is on the intersection of blockchain technology and embedded hardware, where autonomous agents can transact as part of an optimal “Economy of Things”.
If you enjoyed reading this, please log in and click “Recommend” below.
This will help to share the story with others.
Twitter: @stephantual
Contact: stephan@slock.it
