What is Parachain?
What is Parachain? Defined as a series of subchains belonging to the main network of Polkadot, can operate independently. Parachain is a blockchain fork tied to Pokadot’s Relay Chain main chain, which connects to the main chain based on proof of Sharding protocols and database designers, incorporating Proof of Validity, and Proof validators. of Stake to generate blocks.
What problem does Parachain solve?
Parachain is the solution to a problem. As with any solution, it cannot be understood without understanding the problem first. So let’s start by looking at the problems blockchain technology faces that make us begin to explore the design space for something like parachain.
1. Parachain solves the problem of block scaling
A few years ago, it became clear that the transaction throughput of simple Proof-of-Work (PoW) blockchains like Bitcoin, Ethereum, and countless others was simply too low.
Proof-of-Stake (PoS) systems can achieve higher throughput than PoW blockchains. The PoS system is secured by bonded capital instead of effort spent – the opportunity cost of liquidity versus burning electricity. The way they work is to select a set of validators with known economic identities who will lock the tokens in exchange for the right to “validate” or participate in the consensus process. If they are found to have misinterpreted that procedure, they will be cut, which means some or all of the locked tokens will be burned. This provides a strong incentive for misconduct.
Since the consensus protocol doesn’t revolve around wasted effort, block times and agreements can go much faster. Solutions to PoW challenges do not need to be found before a block can be generated, so the cost of creating a block is reduced to just the cost of creating and distributing the block.
However, PoS on-chain consensus requires the full consent of 2/3+ validators for everything that happens at Layer 1: all logic is done as part of the blockchain’s state machine. This means that people still need to check everything. Furthermore, validators may have different views of the system based on information they receive over the asynchronous network, making it more difficult to agree on the latest state.
2. Flexibility and specialization
The Virtual Machine is stupid and doesn’t give you any flexibility. Currently, most Ethereum DeFis or dApps must live on a Blockchain network running on a virtual machine in order to function. But to develop on a private blockchain is expensive in terms of cost and time. If developed on a private blockchain then they know that can specialize and can help them leverage more leverage.
Realizing these problems, the Polkadot team set out to find a solution that would allow developers to create and deploy unified purpose-built blockchains under a common source of security, with the ability to be able to communication between different blockchains; a heterogeneous sharding solution, which we commonly call Parachain.
Concept origin of Parachain
Parachain is an example of a shared protocol. Sharding is a concept borrowed from traditional database architecture. Instead of requiring every participant to check every transaction, the protocol’s structure requires each participant to check some subset of transactions, with enough redundancy for byzantine participants (depending on maliciousness). mind) cannot sneak into invalid transactions – at least these malicious codes go undetected and get slashed (burned), with those transactions reverted (re-validated from scratch).
Sharding and Proof-of-Stake work together to allow a parachain server to provide full security across multiple parachains, even without all participants checking all state transitions.
How does Polkadot’s Parachain work?
In this section we dive into the Parachain protocol. The essence of this protocol simulates the process of initializing a Parachain block from an external author and putting the block on the Relay Chain. This is the principle that all Polkadot Parachains and parallel parachains connect to the Relay Chain mainnet and mint its subblocks.
The algorithm used in this section is a proof of stake consensus algorithm that combines proof of authority, proof of stake and sharding algorithm.
This is also the specific description of the Relay-Chain chain of Polkadot’s main blockchain network and the actors that provide security and input to this blockchain.
The actors include the following:
- Validator (Validator): These nodes are responsible for validating the proposed parachain blocks. By checking the Proof-of-Validity (PoV) of the block and make sure that PoV is confirmed. Authors must deposit stakes of DOT tokens as collateral when initiating a parachain validation process and be burned by the guillotine if they are proven to have miscalculated.
- Collators, collations: These nodes are responsible for creating Proofs-of-Validity that validators know how to check. Creating a PoV usually requires you to be familiar with the transaction format and block generation rules of the parachain, as well as having access to the full state of the parachain.
- Fisherman (Fisherman): These are permissionless, user-run nodes whose goal is to catch misbehaving validators in exchange for a bounty. Collaborators and validators can also act as Fishermen. Fishermen are not essential to security and are not covered in depth in this document. These are permissionless, user-run nodes whose goal is to catch misbehaving validators in exchange for a bounty. Collaborators and validators can also act as Fishermen. Fishermen are not essential to security and are not covered in depth in this document.
We can simply imagine this process as a Pipeline, where Collators send Validators blocks to request validation. The Validator then validates the block using PoV, signing statements describing a positive or negative statement for the block from the outside. And with enough active statements, the block can be recorded on the Relay Chain.
The case of recording bad status is not a veto but will lead to conflict, with people on the wrong side getting slashed (burned). If another Validator later finds that a Validator or group of Validators incorrectly signed a status requesting a block to be valid, those validators will be dropped and the verifiers will receive their funds. reward.
However, there is a problem with this formula. In order for another validator (Validator) to be able to check the work of the previous validator pool after completing the block, the PoV must remain available so that the other validator can fetch and check the work. PoVs are expected to be too large to put directly on the blockchain, so we require an alternative data availability diagram that requires validators to demonstrate that the input to their work will still be available and so their work can be checked. Empirical tests tell us that multiple PoVs can go from 1 to 10MB during heavy loads.
Here is a description of what the Pipeline includes: the path that a parachain block (or parablock for short) takes from creation to inclusion in the Relay-chain and becoming a Parachain:
- Validators are selected and assigned to the parachains according to the verification routine (Validator Assignment routine).
- The Collator provides the parachain block, also known as the candidate chain (Candidate Parachain) or Candidate, along with a PoV for the candidate.
- Collator transfers Candidate and PoV to specified Validators for the same parachain via the Collator Protocol.
- The validator assigned to a parachain at a given time participates in the Backup Candidate Baking subsyterm to validate the candidates that have been submitted for validation. Candidate that collects enough signed valid states from Validators is considered Backable Candiadte. The Candidate Baking subsyterm is a representation of the collection of valid signatures of a previous Validator group.
- A Relay Chain block Author (Block from the main chain), selected by BABE, notifies the Backable candidate for its parachain to include in the Relay Chain block with its support. The Backable Candidate added to the Relay Chain will be considered as a fork of the Relay Chain.
- Once a Backable Candiadte (parachain block) is included in the Relay Chain, further parachain candidates must wait for the PoS consensus of the network and are not considered part of the parachain until it is proven to be.
- Next in the Relay Chain, the Validator joins the system Availability Distribution Subsystem to ensure the availability of Candidate. Information about Candidate will be recorded in the Relay Chain block.
- After the Relay Chain state machine has enough information to consider the candidate’s PoV as available. Candidate is considered part of the parachain and converted into a full parachain block, or parablock for short.
*** Note that candidate may not be included in any of the following ways:
- Collactor cannot propagate Candidate to any validator specified for parachain.
- Backed Candidate cannot be further validated by any Validator once it has entered the Candidate backed Subsystem.
- Candidate is not generated from the main chain (Relay Chain author block) to be included in the Relay Chain.
- Verified Candidate is not considered available during the timeout and is removed from the Relay Chain
Almost when the block (candidate) is waiting to be accepted as a parachain and is putting the data backup subsystem waiting for consensus verification from other parachains. The main chain’s validator Relay Chain is called a validator set of a group of Prachains called Validator of Prachains that are randomly taken to verify the candidate, which may contain 1% malicious code. Besides, the Validator of prachains in this case is randomly sampled at a rate of <= ⅓, which can lead to a false and misleading set of validations. Therefore, it is necessary to have a secondary validation process from the Collator and Validator before it is put into the system. This system ensures security, and the child blocks of each Prachain will be created on this mechanism.
To recall some of the components in the loop process of a Candidate (parablock):
- Candidate: lis a block (code) transferred from the Collator to the Validator
- Seconded: a validator sent to other validators
- Backable: properties have been verified by a Validator representing the majority of Validators in the network
- Backed: Verified & and backed up on Relay-chain.
- Pending availability: Is Backed but must wait for verification from Relay Chain.
- Included: Verified and approved to be a Parachain of Relay Chain
- Accepted: Could be Backed, available, and undisputed
The above content is compiled by coin68 from the whitepaper of Web3foundaition, the founding team of Pokadot. Why can Parachain work independently? How do parallel parachains connect to each other? How to bridge Relay Chain with Bitcoin’s blockchain network or Ethereum’s machine? Look forward to reading in the next section.
Parachain is a blockchain fork to Relay Chain in the Polkadot blockchain network structure. Each Parachain will be an independent platform and has its own ecosystem, connecting the Relay Chain Main Chain and parallel Parachains, but ensuring the same Proof of validator protocol structure for consensus throughout the network. This structure allows data to be shared, but not all of the network’s information. And must require verification before connecting to the network. With this mechanism, users and developers of blockchain software can take advantage of shared data and connect all blockchain networks around the world. This can be considered a breakthrough in the network design of blockchain when identity verification, block scalability and security are the three big question marks for today’s blockchain platforms.