Add async backing technical reference

[charlesHetterich]

• still need to finalize diagrams and give better context of them

📝 Description

Provide a clear and concise description of your changes.

🔍 Review Preference

Choose one:

• ✅ I have time to handle formatting/style feedback myself
• ⚡ Docs team handles formatting (check "Allow edits from maintainers")

🤖 AI-Ready Docs

If content changed, regenerate AI files:

• ✅ I ran python3 scripts/generate_llms.py
• ⚡ Docs team will regenerate (check "Allow edits from maintainers")

✅ Checklist

• Changes tested
• PaperMoon Style Guide followed

[github-actions]

Automated style guide suggestions (1-4 of 4)

[Copilot]

Pull Request Overview

This PR adds new documentation for Polkadot's asynchronous backing and inclusion pipeline features, explaining how rollup blocks are processed and validated in the relay chain.

• Introduces comprehensive documentation for asynchronous backing, including configuration options and visual comparisons between synchronous and asynchronous processing
• Adds a new page explaining the inclusion pipeline stages (Generation, Backing, and Inclusion)
• Updates the llms.txt index to reflect the new documentation pages

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 9 comments.

File	Description
reference/parachains/consensus/inclusion-pipeline.md	New documentation page explaining the multi-step pipeline for rollup block processing, including Generation, Backing, and Inclusion stages
reference/parachains/consensus/async-backing.md	New comprehensive documentation on asynchronous backing, including governance configurations, processing diagrams, and multi-core scenarios
llms.txt	Updated documentation index with new page entries and incremented page count from 269 to 271

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Incomplete sentence. The sentence "Notice how P2 starts before the backing stage of P1" appears to be cut off and should be completed or followed by additional explanation.

Suggested change

	Notice how `P2` starts before the backing stage of `P1`
	Notice how `P2` starts before the backing stage of `P1`. This illustrates the core benefit of asynchronous backing: multiple parachain blocks can be generated and begin their backing process in parallel, rather than waiting for the previous block's backing to finish. As a result, block production and validation are pipelined, increasing throughput and reducing latency across the network.

[Copilot]

Placeholder text "in progress" should be removed or replaced with actual content before publishing.

Suggested change

	*in progress*
	Let's compare how block production and validation differ between synchronous and asynchronous processing.

[charlesHetterich]

This is ready for feedback. I split this up into two technical reference pages

• Async Backing
• Inclusion Pipeline

Everything is in good condition besides the section titled Synchronous VS. Asynchronous Processing. Before I continue spending time on it, I wanted to get feedback how to structure this section, where it should live, or if it should just be removed entirely. The intention of the section is to provide a visual understanding of what async backing is.

Additionally there are 3 empty links in inclusion-pipeline.md

• candidate receipt
• erasure code chunks
• approval process (in reference to the final approval process of the inclusion pipeline)

Which, I was hoping there are definition these could link to?

[brunopgalvao]

Left my review. Overall I would focus on making sure the concept of async backing flows well for readers. I left some comments that can help in the direction.

[brunopgalvao]

Suggested change

	**Backing**: A subset of active validators verify if the parablock follows the state transition rules of the parachain and sign *Proof of Validity* (PoV) statements that can have a positive or negative outcome. With enough positive statements, the block is backed and included in the relay chain, but is still pending approval.
	**Backing**: A subset of active validators verify the parablock and sign validity statements (backing statements) about the Proof of Validity (PoV) statements that can have a positive or negative outcome. With enough positive statements, the block is backed and included in the relay chain, but is still pending approval.

PoV (Proof of Validity) is the state transition proof that collators produce, not what validators sign. Validators sign "validity statements" or "backing statements" about the PoV.

[brunopgalvao]

Suggested change

	**Context**: Context of state is provided as input in order for collators and validators to build a parablocks during the generation and backing stages, respectively. This context is provided by two sources:
	**Context**: Context of state is provided as input in order for collators and validators to build parablocks during the generation and backing stages, respectively. This context is provided by two sources:

[brunopgalvao]

Suggested change

	Notice how `P2` starts before the backing stage of `P1`
	Notice how P2 starts before the backing stage of P1 completes

[brunopgalvao]

This heading has no explanatory text - just a diagram. Need to add context explaining what the multi-core/elastic scaling scenario demonstrates.

[brunopgalvao]

I would suggest a smoother introduction. Maybe something like this:

Asynchronous backing (often shortened to Async Backing) is a parachain protocol feature that
significantly improves performance, enabling parachains to produce blocks twice as fast (every 6
seconds instead of every 12 seconds) with 4x more execution time per block (2 seconds instead of 0.5
seconds).

Technically, async backing is a parachain configuration that allows collators to build new blocks on
top of unincluded segments—chains of parachain blocks that have not yet been fully included in the
relay chain. This decouples parachain block production from relay chain inclusion.

Without async backing (synchronous mode), collators must wait for each parablock to complete the
entire inclusion pipeline before building the next one. This tight coupling limits throughput to one
parablock every 12 seconds (every other relay block).

With async backing enabled, collators can begin building a new block as soon as the previous block
completes the generation stage, without waiting for full inclusion. This pipelining approach enables:

• Higher throughput: One parablock every 6 seconds (every relay block) instead of every 12 seconds
• Extended execution time: 2 seconds per block instead of 0.5 seconds, allowing more complex
  computation
• Better coretime utilization: More efficient use of allocated coretime across the network
• Elastic scaling support: The pipelining foundation needed for parachains to scale across multiple
  cores

The degree of pipelining is controlled by on-chain governance through configuration parameters like
max_candidate_depth and allowed_ancestry_len.

[brunopgalvao]

And add links to key terms.

[brunopgalvao]

I would recommend adding context here for developers who are new to Polkadot - noting that synchronous backing was the old way, and the new, better way which is baked into the protocol is asynchronous backing. Something like this:

The Polkadot-parachain protocol originally operated in synchronous mode, where both collators and validators drew context exclusively from the relay parent of the prior parablock, which lives on the relay chain. This made the Backing and Generation steps tightly coupled to the prior parablock completing the entire inclusion pipeline. As a result, one parablock could only be processed every other relay block, with just 0.5 seconds assigned for execution.

The modern protocol now uses asynchronous backing, where both collators and validators have access to /reference/parachains/consensus/inclusion-pipeline as an additional context source. The Backing and Generation steps are no longer coupled to the prior block completing the full inclusion pipeline. Instead, the prior parablock only needs to complete the generation step and be added to the Unincluded Segments before the next parablock can begin the Backing and Generation steps.

This results in one parablock being processed every relay block (instead of every other relay block), and allows for more time to execute during the Generation step (0.5s → 2s).

[brunopgalvao]

And add links to key terms.

[brunopgalvao]

The inclusion pipeline is a fundamental Polkadot concept that exists independently of async backing. The current page jumps straight into technical details without explaining what it is or why it matters. We need a well-framed introduction for this page to succeed. Something like this:

The inclusion pipeline is the multi-stage process through which every parachain block (parablock) is validated and secured before being finalized in the Polkadot relay chain. This pipeline ensures that all parachain blocks meet validity requirements through progressive verification by multiple sets of validators.

The pipeline exists to provide Polkadot's security guarantees: rather than trusting a single validator group, each parablock passes through multiple validation stages with different validator sets, ensuring that invalid blocks cannot be finalized even if some validators are malicious or compromised.

Whether a parachain uses synchronous or asynchronous backing, all parablocks follow the same inclusion pipeline. The difference is in the timing: asynchronous backing allows multiple blocks to be at different stages of the pipeline simultaneously (pipelining), while synchronous backing processes one block through the entire pipeline before starting the next.

Pipeline Stages

The inclusion pipeline consists of three main stages:

[existing mermaid diagram]