Polkadot: The Parachain
Polkadot is a blockchain for scalable decentralized computation and interoperability. In this article, we are going to examine one of the main parts of the network: the parachain.
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.
Perhaps an even more interesting approach to scalability is the use of zero-knowledge (ZK) proofs. Modern-day non-interactive ZK proofs like ZK-SNARKs or ZK-STARKs allow us to check a proof that a known program with some known inputs and some unknown inputs was executed correctly, and learn what the output of that program was without leaking any information about the private inputs. Most commonly, ZK proofs like this are referred to as a tool for privacy, but they can also be leveraged for performance: surprisingly, the time to check this kind of zero-knowledge proof is more or less constant regardless of the complexity of the program itself, with some proofs verifying in less time than the corresponding program would take to execute! That means that even extremely complex transactions which might take hours of processing can be verified in a short amount of time by the validators of the chain. Unfortunately, the computational and memory cost to create ZK proofs is still higher than feasible for average users. Until these costs come down, ZK proofs in practice will remain a thing of the future.
But the great thing about parachains is that they are so general. By allowing each parachain to define a notion of its own validity, we can seamlessly transition from our current bulky proofs to lighter, more advanced proofs in the future. As sharding research develops, parachains can easily be added which implement the latest techniques. And that’s ultimately what Polkadot’s value proposition boils down to: that it sits at the right level of abstraction to work in both the present and the future without any unnecessary overhead. The system is designed to not only accommodate arbitrary progress, but also to have the extensibility to integrate the latest developments in scalability without a hitch.
For more questions, reach out to me on Twitter (@rphmeier ) or as rphmeier on Gitter or Riot:
For more info about the tech behind Polkadot, please visit Parity Tech’s website
Polkadot is a project brought to you by the Web3 Foundation, visit their Polkadot website
