Preparing to build on Polkadot

We previously outlined the main reasons why we think Polkadot will be attractive to developers by tackling the most critical issues limiting blockchain adoption and innovation. In this blog post, we will propose a number of suggestions that will help developers to best prepare for Polkadot’s launch.

We believe it is possible for developers to continue working with the technology that they are already familiar with. Our goal of developability is to remove as many barriers as possible to building decentralized technologies, although it will ultimately be better to switch to working with a language that compiles to Wasm. The reasoning behind this is something we will expound in this blog post.

Here we follow two topics: 1) a development path for decentralised applications (DApps) to be on-boarded to the Polkadot platform, and 2) an introduction to how developers can build a fully featured parachain that can participate in Polkadot’s multichain environment.

DApp developers who wish to deploy smart contracts on Polkadot do not have to create a parachain since Polkadot will have parachains that have Turing complete state machines. If you are interested in developing a parachain, we get into what you need to implement, what you would use to implement it, and what you can do once its implemented.

Building DApps and parachains for Polkadot

At this point, developers are probably asking, “is there anything we can do to prepare for Polkadot’s launch?”

The answer is “Yes”!

We are very keen to meet with teams interested in building DApps natively on a Polkadot parachain or in building new parachains. Our recommendation is to write smart contracts and the parachain runtimes in a language that compiles to Wasm.

There is a possibility of having EVM based parachains that would allow developers to continue to use Solidity to write smart contracts. However, we don’t recommend this, as Ethereum intends to move to Wasm once sharding is implemented. Fortunately, there a tool is being worked on called Yul (renamed from Julia) that compiles Solidity to Wasm.

In the long-term, we expect Wasm to be a natural choice for blockchain development and is why we suggest that developers should begin to investigate Wasm smart contracts. For further reading on Wasm, see Parity’s explanation of Wasm and their introduction to writing smart contracts in Wasm.

DApps built on Polkadot

There are a two primary development paths to create a DApp that will eventually be deployed to Polkadot: (1) write it in Wasm such that it will run on a native parachain, or (2) deploy a DApp using Solidity on an EVM based chain. The latter will be appealing to developers who want to work with the currently available tooling, but switching to Wasm would be better for the long term.

Following option (1) is about preparing for parachains being launched in the future. It is possible write and test DApps in Wasm and test them on either Kovan or a self-deployed PoA network. Fredrik Harrysson from Parity presented how to run Rust contracts on Kovan with WASM at EthCC. It is worth noting that the limited tooling around Wasm smart contracts may make testing more difficult. More information can be found in Parity’s blog post that covers a Wasm VM and smart contracts.

For developers who would prefer to follow option (2) and continue writing DApps in Solidity, then we would recommend mirroring the above suggestion. However, the deployment would be to an EVM based PoA chain, which allows developers to test the data flows and get a working product with some level of scalability. When Ethereum is bridged to Polkadot it will allow existing DApps to benefits from the new functionality offered, including scaling and cross-chain messaging.

Setting up a PoA chain is straightforward, multiple tutorials already exist, and eventually, they can be bridged to Polkadot after the genesis block is created (expected Q3 2019). Assuming the trend to Wasm continues and Ethereum successfully implements Sharding, we strongly recommend using Wasm as the primary language.

The plan of action is as follows:

• Deploy a PoA chain and a bridge contract.
• Get the DApp working with the PoA chain.

Bridges provide the message passing functionality that will connect stand-alone chains to Polkadot. The platform will have many different chains, of various types, bridged to it in the future.

Building a parachain

Parachains were first mentioned in the whitepaper and were explored in more detail in a previous blog post entitled “Polkadot: The Parachain”:

“A parachain (parallelizable chain) is a simpler form of blockchain, which attaches to the security provided by a ‘relay chain’ rather than providing its own. The relay chain [provides] security to attached parachains, but also provides a guarantee of secure message-passing between them.”

The latter removes the need for bridging contracts since message-passing is integrated into the protocol.

Creating a parachain that’s native to Polkadot will require understanding Substrate. More details can be found in Dr. Gavin Wood’s presentation at Event Horizon and in the Substrate subdirectory of the Polkadot GitHub.

The design of Polkadot’s multichain architecture allows developers to specify the notion of their parachain’s validity. To implement a parachain, developers need to implement a state transition validation function, decide upon a state format, and a transaction pooling mechanism. Once you’ve implemented your parachain, there are a couple of extra steps involved in integrating it with Polkadot. To do this you will need to deploy the state transition validation function onto the Relay Chain, then distribute a collator node client with includes the transaction pooling mechanism.

Creating all of these pieces requires thinking about how a collator node should construct the blocks of your chain and how the validity of these blocks can be checked and confirmed by a validator node. There are two options here: (1) write the collator node from scratch, or (2) use a shell collator node that can run different kinds of state machines. At the time of writing, we don’t have the specs for writing a collator node, although more details will be forthcoming as more PoCs are release.

One requirement is that the state machine is written in a language that compiles to Wasm. This is a design choice that ensures a great amount of flexibility, such as on-the-fly updates to the runtime. As research develops, parachains can easily be upgraded to implement the latest technologies, such as sharding.

We expect that the code of popular parachains will be copied and reused in other chains, and even used in stand-alone blockchains. The Web3 Foundation invites developers to start creating parachains as well as a whole host of other general components that are critical to Polkadot’s success, such as block explorers, wallets, alternative implementations of relay nodes and collator nodes. Reach out on Riot to get in touch with someone on the team.

Looking to the future

Once Polkadot launches, the benefits offered to developers will be very attractive. Whether it be interoperability between blockchains and parachains, the increase in scalability, the increased speed from numerous execution efficiencies, or the dynamic on-chain governance system, there are numerous reasons to consider development on the Polkadot platform.

We hope this blog post provides additional clarity on the necessary migration for developers who have already deployed a DApp on Ethereum, are looking to build on Polkadot, or are just getting started!

We are on schedule to launch the network by Q3 2019. As we move toward future proofs-of-concept and testnets, we encourage community members to help us move the project forward and to join us in bringing the Polkadot Network to life.

We invite everyone to download Polkadot’s code, compile it, and connect to the global testnet. After installation be sure to ask for some testnet DOTs in our chat channel on Riot!

Happy BUIDLing!