mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-08-06 11:55:49 +00:00
Chevdor
a30092ab42
* Add markdown linting - add linter default rules - adapt rules to current code - fix the code for linting to pass - add CI check fix #1243 * Fix markdown for Substrate * Fix tooling install * Fix workflow * Add documentation * Remove trailing spaces * Update .github/.markdownlint.yaml Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> * Fix mangled markdown/lists * Fix captalization issues on known words
51 lines
3.1 KiB
Markdown
51 lines
3.1 KiB
Markdown
# 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**.
|