Understanding Polkadot's Parachain Protocol: The Candidate Backing Subsystem
Polkadot’s network runs on trust, but what makes it truly secure? Enter the Candidate Backing Subsystem—a critical protocol where validators decide which parachain blocks make the cut. Curious how this process keeps Polkadot fast and secure? Let’s explore the mechanics behind the magic.
The Parachain Protocol in Polkadot manages the life cycle of parachain blocks, from their creation to their inclusion on the Relay Chain. Operating across multiple parachains in parallel, it optimizes network efficiency while upholding the highest standards of security. This intricate process is enabled by a set of interdependent subsystems, each playing a unique role in ensuring that parachain blocks are properly validated and backed.
A critical component of this protocol is the Candidate Backing Subsystem, responsible for validating parachain blocks before they are included in the network. Validators play a key role in this process, verifying that blocks meet strict validity requirements and securing consensus across the network.
Before we delve into the Candidate Backing Subsystem, it's essential to understand the roles of collators and validators.
Collators
Collators maintain parachains by aggregating parachain transactions into parachain block candidates and producing state transition proofs (Proof-of-Validity, PoV) for validators.
The Proof-of-Validity includes:
- The block, which contains the list of state transitions.
- The values in the parachain's database that are modified by the block.
- The hashes of the unaffected points in the Merkle tree.
Collators maintain a full node for the Relay Chain and a full node for their particular parachain. They collate and execute parachain transactions to create an unsealed block and provide it with a PoV to one or more validators responsible for proposing a parachain block.
Collators don't provide security guarantees––the network relies on having at least one honest collator to accept user transactions and build blocks.
Validators
Validators are tasked with verifying proposed parachain blocks by checking their Proof-of-Validity (PoV) and ensuring the PoV is available for a set period. They have funds locked on-chain, which the network can partially or fully take if they misbehave.
Some validators are assigned to specific parachains by the Validator Assignment Routine and are known as para-validators. They connect with collators, who submit the candidate blocks and PoV through the Collator Subsystem.
Para-validators participate in the Candidate Backing Subsystem to ensure the candidate blocks follow the parachain's state transition rules. Since parachain states get stored in Merkle trees, para-validators can verify state transitions without having access to the entire state with only the PoV.
Candidate backing subsystem
Before discussing the details of the subsystem, it's important to understand some key technical terms and concepts used within it.
What is a candidate?
A candidate is a parachain block waiting to be added to a relay chain block. To simplify, we call it a candidate block.
What is the validity statement?
Parachain validators can issue two types of validity statements for a candidate block:
Seconded: This statement means the validator has verified the candidate block and is proposing it to other parachain validators for further validation. This statement can only be issued if para-validators have received a candidate block from the collator and the para-validator has yet to second another candidate or sign a Valid statement for the received candidate block. At this point, para-validators who issue the Seconded statement are unaware of any statement by any other para-validators for this candidate block.
Valid: This statement indicates that the candidate block is valid. This statement can only be issued if para-validators have received a candidate block from the other para-validators assigned to the parachain.
A Seconded statement indicates that a para-validator has already validated the block and proposed it to other para-validators for their validation. As a result, a Valid statement can only be issued if the block has already been seconded, ensuring it has passed initial validation.
Only para-validators assigned for a particular parachain can second candidate blocks, and they are limited to seconding one candidate per depth per active leaf in the relay chain. Before asynchronous backing, the depth was always 0.
Active leaves are the most recent blocks in the relay chain that still have no children. They should descend from the latest finalized block.
Backable Candidate vs. Backed Candidate
A candidate block becomes backable when it receives enough supporting validity statements from the parachain validators. In legacy backing (before asynchronous support), a candidate required two supporting votes to be considered backable.
After a candidate becomes backable, the relay chain block author selects one for each parachain to be included in the relay chain block. When a backable candidate receipt is included in the relay chain block, it becomes a backed candidate. The candidate block is considered included when its header is included in the subsequent relay chain block.
Overview
The Candidate Backing Subsystem ensures that each parablock proposed for inclusion in the relay chain meets strict validation requirements. Specifically, a parablock must be seconded by at least one parachain validator and approved by a quorum of validators.
Parablocks that don't gather enough validator votes confirming their correctness are rejected. If a candidate block that was initially validated is later found invalid, the validators who voted for it may face slashing penalties.
The Candidate Backing Subsystem produces backable candidates for inclusion in new relay chain blocks. It accomplishes this by:
- Issuing signed validity statements.
- Tracking validity statements received from other validators.
- Combining these validity statements into backing for specific candidates once enough support is obtained.
This subsystem does not determine which candidate is ultimately included in the relay chain; that decision is left to the block author. However, once a sufficient quorum of validators agrees on a candidate's validity, the subsystem notifies the Provisioner (a utility subsystem), who then triggers the block production mechanisms to include the parablock in the relay chain block.
Candidate backing message
Second
The Collator Protocol Subsystem sends the SecondMessage to the Candidate Backing Subsystem to validate a candidate block and proposes it to other validators for further validation.
Functionality: The Candidate Backing Subsystem requests validation from the Validation Subsystem and generates the appropriate validity statement based on the validation result.
If the candidate is invalid and recommended by the validator's own Collator Protocol Subsystem, a message with the candidate's hash is sent back to the Collator Protocol Subsystem. This allows the collator that recommended the invalid candidate to be penalized.
If the candidate is valid, the subsystem signs and dispatches a Seconded validity statement to peers, but only if the validator has not already seconded another candidate or signed a Valid statement for the requested candidate. After that, the issued validity statement is stored in the validator's statement table.
Signing both a Seconded and Valid statement for the same candidate is considered double-voting, a misbehaviour with a severe penalty.
Statement
The StatementMessage represents a validator's assessment of a specific candidate received from other parachain validators and is sent by the Statement Distribution Subsystem to the Candidate Backing Subsystem.
The Statement Distribution Subsystem is responsible for collecting the validity statements from other para-validators and distributing the validity statements to other para-validators.
Functionality: If the validity statement in the message is Valid, it gets stored in the statement table of the current parachain validator.
If the validity statement in the message is Seconded and contains a candidate that belongs to our assignment, request the corresponding PoV from the backing node via AvailabilityDistribution.
After getting PoV, launch validation and issue our validity statement. Also, store the validity statement in the statement table.
If there are disagreements regarding the validity of this assessment, they'll be addressed through the Disputes Subsystem. Meanwhile, agreements count directly to the quorum.
GetBackableCandidates
The GetBackableCandidatesMessage is a request sent by the Provisioner Subsystem (Utility Subsystem) to the Candidate Backing Subsystem to retrieve a set of backable candidates that could be backed in a child of the given relay parent.
Functionality: The Candidate Backing Subsystem identifies candidates from the provided list that have received enough supporting statements from parachain validators and returns these backable candidates through the response channel.
In the legacy backing system (before asynchronous support), a minimum of 2 supporting statements are required.
In Conclusion
The Candidate Backing Subsystem plays a crucial role in Polkadot's Parachain Protocol, ensuring that only properly validated blocks are eligible for inclusion in the Relay Chain. Securing validator consensus and upholding strict validation rules, contributes to the integrity and security of the network. While this subsystem is key to the functioning of parachains, it operates alongside other essential components that together maintain Polkadot’s robust multi-chain architecture.
More Gossamer
- Chat directly with the team → Discord
- Learn more by checking out the → Docs
- Keep a tab on the progress → Twitter
About ChainSafe
ChainSafe is a leading blockchain research and development firm specializing in protocol engineering, cross-chain interoperability, and web3 gaming. Alongside its contributions to major ecosystems such as Ethereum, Polkadot, and Filecoin, ChainSafe creates solutions for developers across the web3 space utilizing expertise in gaming, interoperability, and decentralized storage. As part of its mission to build innovative products for users and improved tooling for developers, ChainSafe embodies an open-source and community-oriented ethos to advance the future of the internet.
