PolkaWorld
Polkadot, the first Chinese community, will take you to find new opportunities in the Web 3.0 era!
The author of this article is Jenner @ Patract Labs.
This article is based on Polkadot’s 6be14014 submission (2020/12), the purpose is to introduce Polkadot’s system architecture from the perspective of parachains.
Roles
Architecture diagram
chain
- Relay chain: Relay chain, responsible for platform security.
- Parachain: Parachain, has its own independent state and business logic, and shares the security provided by the relay chain.
node
- validator: The validator is responsible for the block generation of the relay chain, while verifying the proof from the collector, and voting for consensus with other validators. The full nodes of the relay chain need to mortgage DOT.
- collator: Collector, collects parachain transactions and state transfer proofs (collation) for verifiers. The full node of the parachain, and the full node service of the embedded relay chain, does not necessarily need to mortgage DOT, and can be motivated by the parachain. Note that the collator of parallel threads needs to hold DOT in order to participate in the auction of block qualification.
- fishermen: fishermen, monitor verifiers and collectors, check invalid candidate receipts. Either collator or validator can be used as fishermen and need to mortgage DOT.
Parachain node structure
Parachain nodes mainly have the following two changes.
consensus
The role of collator on the parachain is similar to the validator on the previous independent chain. However, collator only provides candidate blocks, which are then handed over to the validator on the relay chain for consensus. Therefore, parachain no longer needs its own consensus mechanism. Of course, the selection mechanism for collator can be retained.
Double service
The difference between parachain nodes and single chain nodes in the past is that a relay chain full node service needs to be started. The built-in relay chain full node service includes the overseer (introduced in the “relay chain node structure” section about overseer) and subsystem services, and the overseer_handle is shared with collator and registered as collator_side on collator_protocol. Therefore, the collator can interact with the validator through the oppositeer, such as passing information about candidate blocks. In addition, the full nodes of the parachain also need to “follow” the block generation of the relay chain through the embedded relay chain node. The so-called “follow” means that the best block of the full node of the parachain is the corresponding parachain block contained in the best block on the relay chain, and the same is true for the final block.
Relay chain node structure
relay_chain
In addition to the necessary basic components on the relay chain, the more important ones are the overseer and the subsystem.
overseer
overseer
Overseer mainly has the following functions:
- Start and shut down a series of subsystems
- As a message bus between subsystems
- Monitor external events and trigger the corresponding tasks of the subsystem
Message protocol
The overseer sends two types of messages to the subsystem: Communication and Signal.
- Communication: The messages exchanged between subsystems are encapsulated in the Communication type, and are delivered to the specified subsystem according to the encapsulated message type. For example, subsystem A sends a message M to subsystem B: 1. A sends AllMessages::B{M} to the overseer; 2. After the overseer receives it, it sends FromOverseer::Communication{M} to B.
- Signal: System messages, such as block import, block termination, and shutdown subsystem, are encapsulated in Signal. System messages will be broadcast to all subsystems.
Subsystem
There are 18 subsystems in the current design, of which 3 are not fully realized.
Collator related
- collation_generation_subsystem : collator generates collation when the block is updated
- collator_protocol_subsystem: Collation requests and responses, perform corresponding tasks according to the role of validator/collator
Candidate block consensus
- candidate_selection_subsystem : trigger a request for collation, request a vote after receiving the collation
- candidate_backing_subsystem : vote on collation and sign the statement
- statement_distribution_subsystem: broadcast statement
- pov_distribution_subsystem: Broadcast PoV
- apporoval_subsystems (TODO): recheck the candidate block before finalize
Usability related
- availability_distribution_subsystem
- bitfield_signing_subsystem
- bitfield_distribution_subsystem
- availability_recovery(TODO)
Tool Subsystem
- candidate_validation_subsystem: verify the candidate block
- provisioner_subsystem ：Provide block production data related to parachain
- runtime_api_subsystem: call runtime api
- availability_store_subsystem: Store availability data
- network_bridge_subsystem: The bridge protocol used to transfer collation-related data between nodes
- chain_api_subsystem
- misbehavior_arbitration(TODO)
Collator
Take the Collator on the parachain as an example to introduce how nodes cooperate with subsystems.
start up
- When the parachain is started, build_polkadot_full_node starts a full node of the relay chain, including the overseer and subsystem, and is registered as collator_side in the collator_protocol_subsystem. If you want to start the node as a collator, you need to set –collator when starting, similar to the previous independent chain setting –validator to start the validator node.
- follow_polkadot: update the parachain according to the block produced by the relay chain
- Initialize collation_generation_subsystem and register collator.produce_candidate at this time to generate collation.
- Register the para_id where the Collator is located on the collator_protocol_subsystem.
- start_collator: polkadot_full_node.client.execute_with(StartCollator}, collator and polkadot_full_node share an opposite_handler.
Prepare candidate blocks
- After collation_generation_subsystem starts, it will circulate handle_incoming. Handle_new_activations after receiving ActiveLeavesUpdate.
- propose a candidate block
- build_collation: Build Collation of candidate blocks
- Start the wait_to_announce task and register as a StatementListener. When receiving Statement::Seconded from validator, broadcast the current candidate block
- request_full_validation_data_ctx Get the data ValidationData that assists in validation on the relay chain.
- task_config.collator -> produce_candidate
- collator_signature_payload signature
- Generate CandidateReceipt (hash containing erasure_root and CandidateCommitments), and send CollatorProtocolMessage::DistributeCollation to collator_protocol_subsystem.
Notify validator
- collator_protocol_subsystem monitors Communication (CollatorProtocolMessage), process_msg processes the message. After receiving DistributeCollation, check para_id, and then distribute_collation broadcasts to validator.
- determine_core: calculate the core assigned to the current parachain
- determine_our_validators: calculate the set of validators allocated to the parachain, including the current set and the set allocated next
- connect_to_validators: connect the current validator set and the next group of validators at the same time
- distribute_collation: Check that collation is on active-leaves, and collation does not appear on the relay parent
- After connecting the new validator, handle_validator_connected in the collator protocol subsystem
- Send a CollatorProtocolMessage::Declare to validator to register collator
- If the validator is a set of validators belonging to the parachain, then advertise_collation will send CollatorProtocolMessage::AdvertiseCollation to the validator to notify the validator that it is ready to send the collation.
Respond to request
- Receive validator message CollatorProtocolMessage::RequestCollation
- send_collation: respond to validtor. The response message contains CandidateReceipt and PoV, and sends CollatorProtocolMessage::Collation(request_id,receipt,pov) to the validator. Since this is communication between nodes, the relay of the overseer can only act between the subsystems within the node, so this message is encapsulated in NetworkBridgeMessage::SendCollationMessage, and forwards the message to the validator through network_bridge_subsystem.
Block
- When the statement on the relay chain is checked (the state is seconded), the collator announces_block on the parachain, which is temporarily synchronized.
- The best block and final block follow the block generation of the relay chain.
More
In fact, the interaction between Collator and subsystems described above can also be said to be a parallel chain block production process from the perspective of Collator. The block production process of the parachain from the perspective of the Validator will be introduced in “The Block Production Process of Parachain Nodes”.
