Join GitHub today
Polkadot is aiming to solve many of the big problems facing blockchain technology today. It will do so by employing a multichain framework that allows for stand alone blockchains or hosted blockchains, that we call parachains, to interoperate. It is possible for chains to operate since they share a common base layer(s) that we call the Polkadot Runtime Environment.
Rob Habermeier of Parity Technologies described parachains in the following way:
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 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 (Wasm code) onto the Relay Chain, then distribute a collator node client that 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:
- write the collator node from scratch, or
- 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 released.
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.
Parachains vs DApps
One question you might have when developing a new project is whether you should create a parachain specific for your task, or whether you should deploy a DApp on top of a generic smart contract blockchain (something Ethereum-like). There is possibly a middle ground here too, but let's just consider a simple dichotomy of a bespoke parachain versus a DApp on a generic smart contract chain.
Possible pain points:
- Must right your own state machine.
- Parachains must be proposed in a referendum and will only be included in Polkadot if the DOT holders agree to do so.
- Can write native code for the state machine which means it can be very fast (must use a language that compiles to Wasm).
- Can control transaction costs within your own parachain. They could be zero.
It is also possible to copy/ paste the code of someone else's parachain, which might have a generic smart contract state machine, and you simply add your own native modules. The modules would allow for some functionality to be removed from the smart contracts which means that the execution ought to be faster.
In order for a parachain to be included after a referendum, it may be worthwhile to offer tokens of your parachain as a reward to validators or even to all coinholders. This may increase the likelihood of your parachain being included on Polkadot.
Possible Pain points:
- May have to pay the gas costs of the underlying parachain.
- Execution is likely to be slower than code that is compiled natively.
- The underlying chain will not be tailored to your specific task, which could lead to many development and runtime issues.
- Sharing the parachain with other use cases may incur decreased speed and scaling.
- No vote needed to deploy.
- Less development time.
- Less development knowledge needed.
Parachains and bridging
Parachains will be able to send messages (including transactions) to each other without the need for smart contracts to perform the bridging functionality.
Sending (or receiving) messages from (on) a parachain will likely be done within a module of the client software, also without the need for bridging contracts. However, it will be possible to deploy a bridge contract on to a smart contract capable parachain if desired.
More information on bridging can be found on the bridges page.
To learn more about the practical process of parachain deployment, please read more at the following: link.