Blockchains today come in a pretty standard form consisting of two parts. The first part is the consensus algorithm, which provides security. The second part is the state machine, which provides the aspects of the chain that are worth obtaining security over. Ethereum, Bitcoin, Zcash, and others are all secured by variants of Proof-of-Work consensus, but the kinds of transactions and accounts they handle — the things that make up their unique state machine — are all different. Picture a developer who comes up with a great idea for a new blockchain, one which can provide efficient privacy or wealth distribution or some other exciting feature. While the developer works on implementing that unique state machine, they also have to implement some kind of consensus algorithm, and when they launch their chain it has to compete with others for security resources. This brings overhead and insecurity to developing new blockchain projects.

Let me introduce 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 is called that because it not only lends security to attached parachains, but also provides a guarantee of secure message-passing between them. One key feature of parachains is that the computations they perform are inherently independent. Fully generalized systems of turing-complete smart contracts run into issues in determining which transactions will “collide” with each other, meaning that transactions which could potentially be parallelized are often run in sequence, wasting valuable computation time. Drawing clear boundaries between parachains means that we can execute all of them at once without fear of collision — if we have 10 parachains, we can perform 10 times the work using the same source of security.

. . .

Highly-specialized parachains have another purpose: they can implement data storage and transaction operations in a most efficient manner for their problem domain, without being shoehorned into a blockchain-specific scripting language or virtual machine. At their core, models like Bitcoin Script and the EVM were designed with the goal of interoperability in mind, but systems making use of these models pay the increased cost of execution for all parts of their implementation, not just those which are meant to be accessible from other systems running on the same network. By contrast, Polkadot parachains communicate with each other by asynchronous message passing, and as such only pay the cost of data uniformity at exactly the boundaries where parachains meet.

Note that it’s still possible to create a parachain that provides a framework for fully general, turing-complete smart contracts. A simple example would be a parachain powered by the EVM. Contracts implemented on this parachain would both benefit from and be inconvenienced by the generality and interoperability of Ethereum smart contracts for the reasons given above. The primary difference is that it’s fully opt-in. We consider Polkadot’s ability to integrate focused solutions while retaining the optionality of using extremely general frameworks to be one of its most powerful features.

One of the most intriguing use-cases for parachains is as a tool for scalability. It is possible to create parachains which have their own parachains, and so on. This creates a tree-like structure that can be used to perform highly distributed computations without reducing the overall burden on the root relay chain itself. The main problem is ensuring data availability — parachain blocks are meant to be accompanied with a proof of validity that remains available to anyone to check for at least a certain period of time. Validators are responsible for ensuring the proof for blocks they verify remains available. Unfortunately, it’s not possible (or at least very difficult) to prove that messages which were supposed to be sent haven’t been without moving the message on-chain. We can avert this problem with largely reputational guarantees: when relatively trusted parties pinpoint a validator as withholding data, they can be punished. This can also be generalized to a system of coin-votes or multi-layered courts. In order to reduce the effectiveness and practicality of malicious and false reports, each report of misbehavior should be accompanied by a non-refundable burn of funds. When enough people are watching a computation, as in the case of first-level parachains, necessary data will typically be available. Another strategy for mitigation involves designing parachains in such a way that stored value can be withdrawn when a chain appears to be stalled or attacked, although this is difficult when that chain executes smart contracts which lock funds or administer their own expenses autonomously.