How Polkadot tackles the biggest problems facing blockchain innovators

Excitement is growing in the Polkadot community as we edge closer to our scheduled release in Q3 2019.

We know that developers in particular are awaiting details on how to best prepare for Polkadot. If we have not yet had a conversation with you or your project, please reach out and join our online community on Riot or Twitter.

This blog post outlines why we believe Polkadot will be a leading blockchain platform and why developers and projects are interested in building on it.

Polkadot is attempting to solve many of the largest issues facing blockchains today including:

• Interoperability
• Scalability
• Speed
• Security
• Privacy
• Developability
• Governance

This blog post will illuminate how Polkadot solves these problems with a multichain framework that allows for stand alone blockchains or hosted blockchains, that we call parachains, to interoperate.

While parachains can actually have a more general structure than a blockchain, our hosted parachain architecture can be considered as a diverse range of chains that share a pool of security while intercommunicating with other blockchains.

This unique architecture enables diverse blockchains to share features and leverage one another’s innovations.

Interoperability — Connecting Blockchains

Since Bitcoin’s genesis block in 2009, there has been a boom in innovation in the blockchain ecosystem. Even so, most of the dollar value has accumulated to only a few chains. Transferring value from one chain to another is perhaps the simplest desire for many in the blockchain community. Today, this is most easily accomplished through a centralised exchange. There are numerous reasons as to why such exchanges are less than ideal and it underlines the greater problem: the blockchain ecosystem consists of distinct, siloed chains.

We envision a future where any arbitrary message, including value, can be transferred between chains. Arbitrary messages are any kind of data structure or data that can be transferred. Communicating arbitrary messages unlocks a host of use cases that were not possible before. For example, an IoT device can feed its data to an oracle chain which verifies its integrity and transfers that data to an insurance DApp to pay out and settle an insurance claim.

Using multiple chains that interconnect will also help to spread the transaction load across many more nodes, which should decrease the cost of executing smart contracts and at the same time improve scaling and decentralisation.

Scalability — Increasing throughput

Scalability is a key obstacle that hampers DApp usage and development. Developers naturally gravitate towards the most popular chains with the largest user base, reinforcing network effects. This is a sensible decision but it increases the strain on the most popular networks and it makes it is harder for new chains, which offer value and unique innovations, to enter the blockchain ecosystem.

The Polkadot platform was designed to alleviate these “winner take all” effects with its hosted multiple parachain architecture. At the heart of the platform is the Relay Chain which connects the chains together by coordinating the cross-chain transactions and providing the consensus mechanism for the whole platform.

The multiple parachain architecture is designed to provide a horizontal scaling solution where a very high number of transactions can be processed in parallel. Polkadot also allows for parachains to have state machines that can be customised for particular tasks, which will enable efficiencies in storage and speed.

One possibility is that DApps could have their own dedicated and purpose-built parachain. This means that other parachains can have simpler state machines because the heavy lifting of smart contracts is contained within a dedicated parachain. DApp developers can benefit from leveraging an existing and scalable parachain and won’t have to worry about running their own chain.

Native Speed — Executing Transactions with Rust

In addition to the benefits provided by horizontal scaling Polkadot will also offer an increased execution speed within the state machines. To understand how this occurs, we will point to a new technology called Substrate, a recently announced product from Parity Technologies. The Relay Chain, and each parachain, will be built using Substrate.

Substrate is written in Rust; however, the core functionality that comprises the state machine has also been written in WebAssembly (Wasm). This allows for two possibilities when the core functionality executes: either it runs natively using the compiled Rust code, or it runs through the Wasm interpreter.

Rust allows for fast (native speed) code execution while Wasm provides improved flexibility but with a lower number of operations per second. A Polkadot node will run code natively, in Rust, if it is the latest version of the code (the version number is stored on the blockchain); however if a node has an older version, as compared to the one shown on chain, then it will make use of the Wasm interpreter for code execution.

Old nodes don’t necessarily have to be the latest version: the flexibility offered by the Wasm interpreter is that the state machine can be updated by retrieving a new state transition function that’s stored in a block on the blockchain. While this is slower than Rust, Wasm-based chains are faster than EVM chains.

The dual coding of the core functionality is one of the tricks employed to avoid hard forking: a topic that will be explained later in governance section.

The combination of customised state machines and the switch to native code execution, or Wasm at worst, will allow for noticeable speed increases. The fast speed should be attractive to DApp developers who need to appeal to users accustomed to the speed of centralised servers.

Security — Leverage existing security for new blockchains

The underlying consensus algorithm is a proof-of-stake variant that’s Byzantine Fault Tolerant. The validator nodes provide security for all chains within the platform, including the relay chain and all parachains. These nodes check the validity of all blocks. If a block is correct then the validators ‘seal’ the block and give approval for the block to be added to the chain.

Validators are economically incentivised to behave honestly and are rewarded by receiving a pro-rata pay out of DOTs. Should a validator behave maliciously or faulty they will have their stake of DOTs ‘slashed’ (decreased).

Attacks against the platform are related to the value of DOTs. If the price of DOTs is low then it could be cheap to purchase a significant number of DOTs in order to affect the outcome of the consensus mechanism. This is true of any POS blockchain; however, due to the public nature of blockchains it should be easy to spot most attacks.

It can be argued that new blockchains decrease the security of other chains when miners, or validators in general, migrate to the new chains. Polkadot is different. As validators seal the blocks of all chains they can be seen as providing a ‘pool of security’. New chains can therefore tap into the security already provided rather than provide their own. This allows for experimentation without decrease the security of existing chains.

Adding or removing more parachains does not require adding more validators. The security of the platform is broadly independent of the number of chains; however, an increased user base, from an increased number of parachains, can increase the total economic value of the platform which can help to provide greater economic security. As DOTs become more expensive, attacking the consensus algorithm will also become more expensive.

More validators will improve network resiliency by improving the amount of decentralisation.

Data Privacy — Private Transactions and Permissioned Chains

One problem with current blockchains is that all data that transacts across the network is public. This is an issue for organisations who wish to benefit from using a blockchain but need to keep certain information private. Now that the GDPR is in effect, there is an even greater need for keeping data private.

To overcome this problem organisations need to run their own blockchain. Running this chain in isolation can ensure data privacy but it can’t benefit from shared features provided by interoperability. One possible solution, in the current environment, is to have a proof-of-authority sidechain. This enables transactions on a public blockchain Ethereum to contain encrypted data.

Parity is already working on permissioned chains and private transactions. For more information, check out their blog post, “Private Transactions, WebAssembly, and Permissioning: New Features Supported by Energy Web Foundation to Power a Blockchain for Energy”.

The good news is that running a permissioned chain on top of Polkadot will be relatively easy. The private transaction technology that Parity developed for Ethereum can also be implemented on Polkadot for parachains. There is the freedom to have private transfer of data without losing out on the benefits of interoperability.

Developability — Making life easier for developers

Although developability is critical for blockchain platforms, it is not often discussed. We think about usability a lot when we talk about product design, however for application platforms developability is the most important thing to attract developers to get apps built and put onto the platform.

Currently, developer teams have to write a lot of code for things like networking and consensus, but really all they might care about is the functionality of a state machine. The Substrate framework allows for creating different kinds of chains in an easier fashion.

Developers won’t have to reinvent the wheel every time inspiration strikes. They can build a parachain using Substrate and therefore spend more time working on product design and development.

Governance — Adaptive and upgradeable blockchain management

Polkadot uses a sophisticated governance mechanism that allows it to evolve gracefully over time at the ultimate behest of its stakeholders. Changes to the protocol will be handled via on-chain governance system, the outcomes of which are binding but not irreversible. The governance system can itself be changed by coinholders.

Governance is planned to be based on:

• Referenda
• Adaptive quorum biasing (avoids the need for quorums to pass referenda)
• Council (made up of 12–24 elected accounts who decide what the defaults are in the case no one shows up to vote)
• Approval voting

Note that the final governance model will not be finalised until close to the launch of the network.

Polkadot’s governance model is enabled through the various novel mechanisms mentioned in this article. These mechanisms include an adaptive state-transition function that is upgradeable and stored on-chain. This is defined in a platform-neutral computational language (i.e. WebAssembly).

The governance system of Polkadot is founded wholly around the idea of stakeholder voting. A key and unfailing rule is:

All changes to the protocol must be agreed upon by stake-weighted referendum; >50% of stake will always command the network.

Dive deeper into Polkadot’s governance system by watching Gavin Wood presentation at EdCon. See also this one-page explanation of the diagram.

Next Steps

Polkadot’s next Proof of Concept will be released in the coming months. POC-2 will include a framework for parachains and the ability to pool security on the Relay Chain. Stay tuned for further updates.

Questions or want to contribute? Reach out to us via Riot.

In our next post, we will outline a possible migration path for DApps and the ways developers can prepare for Polkadot’s release next year.

*Correction: The number of Proofs of Concept prior to genesis is not finalised. We had previously reported three POCs.