This article is from the Odaily Planet Daily with permission to reprint.
This article is a roadmap for the underlying core technology of parachains-the content about which protocols, APIs and code paths are needed to fully demonstrate a self-sufficient and safe parachain. This article will not cover which APIs need to be exposed by the parachain toolkit in order to use the parachain functions-but only introduce how these functions are implemented and the underlying APIs (if any) they provide to the verification function.
category
We will use the following categories to describe features:
Runtime: The runtime code of the relay chain, which is used to specify the key state of the consensus and update the state that must be maintained or executed by all full nodes.
Networking: A protocol used for nodes to communicate with each other and transmit information in the network.
Node: A state or update that must be maintained or executed by some or all of the nodes under the chain. Usually interact with network components and refer to runtime state.
Subprojects and functions:
This section contains different sub-projects and the functions that make up these sub-projects.
Infrastructure/API
Peer Set Management
Category: Network
The verifier assigned to the parachain needs a way to discover and connect to the collator in order to obtain fresh parachain blocks for verification.
The collator needs to discover and connect to the validator in order to submit the parachain block.
Fishermen need to talk to verifiers and verifiers to obtain available data and distribute reports.
Some connections are long-lived, and some are only used for a single request.
Peer Set Management
Category: Network
Validators assigned to parachains need a way to discover and connect to collectors in order to obtain fresh parachain blocks for verification.
Collectors need to discover and connect to validators in order to submit parachain blocks.
Phishers need to communicate with validators and collectors to obtain available data and distribute reports.
Some connections are long-lived, and some are only used for a single request.
Custom libp2p sub-protocol
Polkadot Parachain involves many different network protocols. Ideally, we can generate each task as a separate future task, and communicate with other protocols or node codes through channels as needed. This needs to be changed in Substrate and libp2p.
distribution
auction
Category: Runtime
Parachain auction and registration. This feature has been implemented and follows the Parachain Allocation — Research at W3F document.
Parachain auction
Category: Runtime
Parathreads are parallel chains that are pay-as-you-go. This includes an on-chain mechanism to resolve the auction of collectors and ensure that they generate a block.
The role of the node-side part of the parallel thread is to allow the collector to actually place the bid and to be configured to place the bid under what conditions.
Validator assignment
Category: Runtime
Assign validators to parachains. The validator is only allocated to the parachain in a short time. Adjustable parameters include the length of time allocated to each parachain and the lead time that the network knows the allocation of validators.
protocol
Witness cycle
Category: Network
A black box network component used to cyclically send proof messages (Candidate, Valid, Invalid) between validators in any given chain to create a quorum that can contain blocks on it.
Usability erasure code
Category: Node/Network
For each potential block considered as a parachain, erasure coding is performed on the PoV and outgoing messages of the block. Call the number of blocks on the relay chain for the relay chain block, and this parachain block is considered to be included in n. The erasure code is divided into n parts, of which any f + 1 can be recovered (f is the maximum number of failed nodes allowed = ~ n / 3). The i-th verifier stores the i-th code and provides it to any inquirer.
PoV block acquisition
Category: Network
A black box network component used by verifiers or phishers on the parachain to obtain the PoV block referenced by the hash in the proof for verification. This should be fast when getting the “current” PoV block (near the beginning of the chain, or related to the block currently being constructed). When acquiring “old” PoV blocks, it should be possible and with the aid of recovery from usability erasure coding.
Parallel thread auction voting
Category: Node/Network
Configure how and when collectors vote in parallel thread auctions.
Collection loop
Category: Node/Network
The main event loop of the collector node:
- New Relay Chain Block B
- Synchronize the new parachain head P wrt B
- Create a new sub-block of P
- Submit to validator
Cross-chain messaging
The largest sub-item in the parallel link diagram-how to send messages between parallel links. This involves the state machine sequencing of incoming messages, the protocol used to obtain these messages, and the node logic used to persist the messages.
Its design is based on the concept of a one-way channel composed of senders and receivers between parachains. In each relay chain block, each parachain has the opportunity to send messages on each channel it controls, and it controls half of the sending part. It will also try to process messages in order on half of each receiving channel it controls: messages sent at block height “b” must be processed before messages sent at block height “b + 1”. Messages on different channels sent on the same block height will be processed in some clearly defined order.
This means that for the sending height of the most recently processed message on all channels it receives, the maximum height difference of the receiving segment is 1. The minimum processed transmission height of the receiving segment is called the “watermark”. All messages sent to this segment on all channels before or at the height of the watermark have been processed.
Terminate CandidateReceipt format
Category: Runtime / Node
CandidateReceipt is a wrapper for the parablock header submitted to runtime. It contains a commitment to data encryption, which is essential for verification or interpretation of parablocks, including the hash of witness data and outgoing message data.
The CandidateReceipt format should be terminated according to the XCMP mentioned above-most importantly, it should be changed to retain the bitfield and message_root fields that are submitted to each open channel state in an encrypted manner.
End the PovBlock format
Category: Runtime / Node
The PovBlock or Proof-of-Validity block contains all the data needed to validate the parablock. It will need to contain incoming message queues and potentially outgoing message queues.
CST update procedure
Category: Runtime
Based on the storage definition and update logic of the Channel State Table (CST) of CandidateReceipt provided in the relay chain block.
CST admission certificate generation and inspection
Category: Node
The full node of the relay chain is a tool for generating project proofs in the CST, and a light client or cropped node checks these proofs.
MQC storage and distribution protocol
Category: Node
The state of each channel is described by the Message Queue Chain (MQC, Message Queue Chain), which is a hash chain, and the link is defined by “(M, b, H)”: the most recently sent message, the previously sent message The height of the block where the message is located, and the hash value of the previous link.
All nodes of the sending parachain are responsible for maintaining all MQC links, up to and including the links whose b is less than the watermark of the receiving parachain.
The complete node of this para will know all the MQC headers of its channel because they are generated by executing this block. This will require collaboration with the Cumulus team (https://github.com/paritytech/cumulus) on the API.
We will need a network in which collectors of parachains can discover and obtain relevant parts of the MQC passed in from all channels.
Channel registrants and economics
Category: Runtime
Parachain opens or closes the runtime logic of the channel by depositing a deposit. The number of channels that can be opened by parallel threads will be limited.
paras is used in runtime logic to open and close channels by putting down deposits. The number of channels that parathread can open will be limited. The channel to be closed should remain open until the receiver’s watermark reaches the block height required for closing.
Fishing/Slashing
Validity/availability report handler
Category: Runtime
In Polkadot, a malicious parachain group can forcefully contain invalid or unusable parachain blocks. The job of the phisher is to monitor these blocks and report them to the runtime. This item is related to report processing procedures.
The W3F research article on usability/validity provides a holistic view of the dispute resolution process: usability and validity-W3F research.
One of the main unresolved actions that need to be taken is the “rollback” that occurs when the dispute resolution process concludes that an error has occurred. When we mark a parachain block as invalid or unavailable, we need to roll back all parachains to a point before this state. We also need to roll back the state of the relay chain, because there may have been a message sent from the parachain to the relay chain, and now it needs to be rolled back. The easiest way is to circumvent this problem by delaying the upward message, but this will greatly affect the user experience of parachain participating in slot auctions, board voting, etc. Assuming we cannot avoid this, we will have to find a way to roll back the specified state of the relay chain.
Double voting Slash handler
Category: Runtime
In the witness process, the validator can only submit a “candidate” message for a given relay chain block. If a “candidate” message is posted on a parachain block, you cannot post a “valid” or “invalid” vote on the parachain block, because the “candidate” message is an implicit validity vote. Otherwise, simultaneous “valid” and “invalid” voting on a given parachain block is illegal.
The runtime handler needs two conflicting votes as parameters, and needs to slash the offender.
Effectiveness/availability phishing
Category: Node
The verifier can also choose according to the VRF availability and effectiveness-W3F research and adopt this code path. The validators and phishers will select the parachain block for re-verification. In these steps:
- Try to restore the PoV block and fall back to erasure code. If it is not available, a report is issued.
- Try to verify the PoV block. If it is invalid, a report is issued.
- Double voting phishing
Category: Node
Nodes that observe double voting during the witness process should submit a report to the chain to trigger Slash.
stage
The roadmap is divided into multiple stages. Compared with the previous stage, each stage represents another set of deliverables or iterations on black box components.
Phase 0: MVP
The initial stage-this is a parachain without slashing (completely secure) or cross-chain messaging. It is basically the registration and verification of the PoC that works normally.
Infrastructure/API:
- Custom libp2p sub-protocol
- Peer Set Management
task:
- auction
- Parallel Thread Auction
- Validator assignment
protocol:
- Proof of circulation (black box: gossip)
- Usability erasure code (black box: gossip)
- PoV block acquisition (black box: gossip)
- Collection loop
Cross-chain messaging:
- Terminate CandidateReceipt format
Phase 1: Fishing and Slashing
This stage marks the progress of parachain security. Once completed, the parachain is a mature and secure aggregation primitive in cryptoeconomics. This stage also includes the implementation of XCMP, but it has not yet been fully activated.
protocol
- Availability erasure code (black box: targeted distribution)
- PoV block acquisition (black box: directional distribution and acquisition)
Fishing/Slashing
- Validity/availability report handler
- Double voting Slash handler
- Effectiveness/availability phishing
- Double voting phishing
Cross-chain messaging:
- Terminate the PoVBlock format.
Phase 2: messaging
This stage marks the delivery of cross-chain messaging.
Including almost everything left in the XCMP section.
