Peter Goodspeed-Niklaus
053bfc2d0c
* move old implementers' guide, add skeleton of new * Split the old implementers' guide into the new one's sections This is mostly a straightforward copying operation, moving the appropriate sections from the old guide to the new. However, there are certain differences between the old text and the new: - removed horizontal rules between the sections - promoted headers appropriately within each section - deleted certain sections which were in the old guide's ToC but which were not actually present in the old guide. - added Peer Set Manager to the new ToC * remove description headers It is redundant and unnecessary. Descriptions fall directly under the top-level header for any given section. * add stub description of the backing module * add stub description for the availability module * add stub description for collators * add stub description for validity * add stub description for utility * highlight TODO and REVIEW comments * add guide readme describing how to use mdbook * fix markdownlint lints * re-title parachains overview * internal linking for types * module and subsystem internal links * .gitignore should have a trailing newline * node does not have modules, just subsystems
3.1 KiB
Whence Parachains
Parachains are the solution to a problem. As with any solution, it cannot be understood without first understanding the problem. So let's start by going over the issues faced by blockchain technology that led to us beginning to explore the design space for something like parachains.
Issue 1: Scalability
It became clear a few years ago that the transaction throughput of simple Proof-of-Work (PoW) blockchains such as Bitcoin, Ethereum, and myriad others was simply too low.
TODO: what if there were more blockchains, etc.
Proof-of-Stake (PoS) systems can accomplish higher throughput than PoW blockchains. PoS systems are secured by bonded capital as opposed to spent effort - liquidity opportunity cost vs. burning electricity. The way they work is by selecting a set of validators with known economic identity who lock up tokens in exchange for earning the right to "validate" or participate in the consensus process. If they are found to carry out that process wrongly, they will be slashed, meaning some or all of the locked tokens will be burned. This provides a strong disincentive in the direction of misbehavior.
Since the consensus protocol doesn't revolve around wasting effort, block times and agreement can occur much faster. Solutions to PoW challenges don't have to be found before a block can be authored, so the overhead of authoring a block is reduced to only the costs of creating and distributing the block.
However, consensus on a PoS chain requires full agreement of 2/3+ of the validator set for everything that occurs at Layer 1: all logic which is carried out as part of the blockchain's state machine. This means that everybody still needs to check everything. Furthermore, validators may have different views of the system based on the information that they receive over an asynchronous network, making agreement on the latest state more difficult.
Parachains are an example of a sharded protocol. Sharding is a concept borrowed from traditional database architecture. Rather than requiring every participant to check every transaction, we require each participant to check some subset of transactions, with enough redundancy baked in that byzantine (arbitrarily malicious) participants can't sneak in invalid transactions - at least not without being detected and getting slashed, with those transactions reverted.
Sharding and Proof-of-Stake in coordination with each other allow a parachain host to provide full security on many parachains, even without all participants checking all state transitions.
TODO: note about network effects & bridging
Issue 2: Flexibility / Specialization
"dumb" VMs don't give you the flexibility. Any engineer knows that being able to specialize on a problem gives them and their users more leverage.
TODO: expand on leverage
Having recognized these issues, we set out to find a solution to these problems, which could allow developers to create and deploy purpose-built blockchains unified under a common source of security, with the capability of message-passing between them; a heterogeneous sharding solution, which we have come to know as Parachains.