You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: llms.txt
+2-1Lines changed: 2 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@
6
6
This directory lists URLs for raw Markdown pages that complement the rendered pages on the documentation site. Use these Markdown files to retain semantic context when prompting models while avoiding passing HTML elements.
7
7
8
8
## Metadata
9
-
- Documentation pages: 270
9
+
- Documentation pages: 271
10
10
- Categories: 12
11
11
12
12
## Docs
@@ -190,6 +190,7 @@ Docs: Polkadot Protocol
190
190
- [Chain Data](https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/reference-parachains-chain-data.md): Learn how to expose and utilize chain data for blockchain applications. Discover runtime metadata, RPC APIs, and tools for efficient development.
191
191
- [Asynchronous Backing](https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/reference-parachains-consensus-async-backing.md): Understand how asynchronous backing pipelines parachain block production, the protocol changes it introduces on the Relay Chain, and how parachains participate safely and efficiently.
192
192
- [Elastic Scaling](https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/reference-parachains-consensus-elastic-scaling.md): Learn how elastic scaling in Polkadot boosts parachain throughput, reduces latency, and supports dynamic, cost-efficient resource allocation.
- [Cryptography](https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/reference-parachains-cryptography.md): A concise guide to cryptography in blockchain, covering hash functions, encryption types, digital signatures, and elliptic curve applications.
194
195
- [Data Encoding](https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/reference-parachains-data-encoding.md): SCALE codec enables fast, efficient data encoding, ideal for resource-constrained environments like Wasm, supporting custom types and compact encoding.
195
196
- [Interoperability](https://raw.githubusercontent.com/polkadot-developers/polkadot-docs/master/.ai/pages/reference-parachains-interoperability.md): Explore the importance of interoperability in the Polkadot ecosystem, covering XCM, bridges, and cross-chain communication.
<!-- Parachain blocks secured by the Polkadot relay chain are processed through a mulit-step pipeline called the [Inclusion Pipeline](/reference/parachains/consensus/inclusion-pipeline). -->
8
8
9
-
## Introduction
9
+
Asynchronous backing (often shortened to ***Async Backing***) is a parachain [configuration](https://github.com/paritytech/polkadot-sdk/blob/f204e3264f945c33b4cea18a49f7232c180b07c5/polkadot/primitives/src/vstaging/mod.rs#L43) set by on-chain governance. It allows collators and validators to build *some* number of blocks ahead of the relay chain during the **generation** and **backing** steps of the [Inclusion Pipeline](/reference/parachains/consensus/inclusion-pipeline).
10
10
11
-
Parachain blocks secured by the Polkadot relay chain are processed through a mulit-step pipeline called the [Inclusion Pipeline](#inclusion-pipeline).
11
+
Async Backing improves throughput of the overall Polkadot Network by using coretime more efficiently, and enables the parallel processing needed for rollups to further scale throughput via [Elastic Scaling](/reference/parachains/consensus/elastic-scaling){target=\_blank}.
12
12
13
-
Asynchronous backing (often shortened to **_Async Backing_**) decouples the steps of this pipeline which enables parallel processing. Specifically, it allows for the generation and backing steps to kick off for a given parablock *before its parent block completes the pipeline*.
14
-
15
-
The introduction of this technique improves throughput of the Polkadot network and lays the foundation for many blocks of the same parachain to be processed in parallel via [Elastic Scaling](/reference/parachains/consensus/elastic-scaling){target=\_blank}.
13
+
## Configurations
14
+
The following configurations can be set by onchain governance, dictating how many blocks ahead of the relay chain a given parachain's collators can run:
16
15
17
-
## How Async Backing Works
16
+
*[`max_candidate_depth`](https://github.com/paritytech/polkadot-sdk/blob/f204e3264f945c33b4cea18a49f7232c180b07c5/polkadot/primitives/src/vstaging/mod.rs#L49): the number of parachain blocks a collator can produce that are not yet included in the relay chain.
17
+
*[`allowed_ancestry_len`](https://github.com/paritytech/polkadot-sdk/blob/f204e3264f945c33b4cea18a49f7232c180b07c5/polkadot/primitives/src/vstaging/mod.rs#L54): the oldest relay chain parent a parachain block can be built on top of.
18
18
19
-
Before diving into *asynchronous* backing, it is helpful to first review each component of the pipeline.
19
+
## Synchronous VS. Asynchronous Processing
20
20
21
-
### Inclusion Pipeline
21
+
In the synchronous scenario, both the collators and validators draw context from the Relay Parent of the prior parablock, which lives on the relay chain. This makes the Backing and Generation steps tightly coupled to the prior parablock completing the inclusion pipeline. As a result, one parablock can be processed every other relay blocks, and only `0.5` seconds are assigned for execution.
**Context**: Context of state is provided as input in order for collators and validators to build a parablock during the generation and backing stages, respectively. This context is provided by two sources:
25
+
---
26
+
displayMode: compact
27
+
config:
28
+
themeCSS: "
29
+
#item1 { fill: #450693; stroke: #450693; } \n
30
+
#item2 { fill: #8C00FF; stroke: #8C00FF; } \n
31
+
#item3 { fill: #FFC400; stroke: #FFC400; } \n
32
+
#r { fill: #eb4172; stroke: none; } \n
33
+
#p1padTop { display: none; } \n
41
34
42
-
***Relay Parent**: The relay chain block which a given parablock is anchored to. Note that the relay parent of a parablock and the relay block including that parablock are always different. This context source lives on the relay chain.
35
+
/* Hide ALL task labels (inside or outside), across breakpoints */
***Unincluded Segments**: Chains of candidate parablocks that have yet to be included in the relay chain, i.e. they can contain parablocks at any stage pre-inclusion. The core functionality that asynchronous backing brings is the ability to build on these unincluded segments of block ancestors rather than building only on ancestors included in the relay chain state. This context source lives on the collators.
**Generation**: Collators *execute* their blockchain's core functionality to generate a new block, producing a [candidate receipt](), which is passed to validators selected for backing.
47
43
48
-
**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.
**Inclusion**: Validators gossip [erasure code chunks]() and put the parablock through the final [approval process]() before a parablock is considered *included* in the relay chain.
46
+
"
47
+
themeVariables:
48
+
sectionBkgColor: '#fff'
49
+
gantt:
50
+
numberSectionStyles: 1
51
+
barHeight: 70
52
+
gridLineStartPadding: 100
53
+
---
54
+
gantt
55
+
dateFormat YYYY
56
+
axisFormat %y
57
+
tickInterval '10year'
51
58
52
-
### Sync VS. Async
59
+
R1 : r, 1905, 1907
60
+
R2 : r, 1911, 1913
61
+
R3 : r, 1917, 1919
62
+
R4 : r, 1923, 1925
63
+
64
+
SPACING : p1padTop, 1905, 1907
65
+
SPACING : p1padTop, 1911, 1913
66
+
SPACING : p1padTop, 1917, 1919
67
+
SPACING : p1padTop, 1923, 1925
53
68
54
-
In the synchronous scenario, both the collators and validators draw context from the Relay Parent of the prior parablock, which lives on the relay chain. This makes the Backing and Generation steps tightly coupled to the prior parablock completing the inclusion pipeline. As a result, one parablock can be processed every other relay blocks.
69
+
section P1
70
+
X : item1, 1900, 1901
71
+
Backing : item2, 1901, 1906
72
+
Inclusion : item3, 1906, 1912
73
+
74
+
section P2
75
+
X : item1, 1912, 1913
76
+
Backing : item2, 1913, 1918
77
+
Inclusion : item3, 1918, 1924
78
+
```
79
+
</div>
80
+
81
+
In the asynchronous scenario, where both the collators and validators have access to [Unincluded Segments](/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.
82
+
83
+
This results in one parablock being processed *every* relay block, and allows for more time to execute during the Generation step (0.5s --> 2s).
@@ -86,50 +125,62 @@ In the synchronous scenario, both the collators and validators draw context from
86
125
gantt
87
126
dateFormat YYYY
88
127
axisFormat %y
89
-
%% this next line doesn't recognise 'decade' or 'year', but will silently ignore
90
128
tickInterval '10year'
91
129
92
130
R1 : r, 1905, 1907
93
131
R2 : r, 1911, 1913
94
132
R3 : r, 1917, 1919
95
133
R4 : r, 1923, 1925
134
+
R5 : r, 1929, 1931
96
135
97
136
SPACING : p1padTop, 1905, 1907
98
137
SPACING : p1padTop, 1911, 1913
99
138
SPACING : p1padTop, 1917, 1919
100
139
SPACING : p1padTop, 1923, 1925
140
+
SPACING : p1padTop, 1929, 1931
101
141
102
142
section P1
103
-
X :item1, 1900, 1901
104
-
Backing : item2, 1901, 1906
105
-
Inclusion : item3, 1906, 1912
143
+
X : item1, 1900, 1902
144
+
Backing : item2, 1902, 1912
145
+
Inclusion : item3, 1912, 1918
106
146
107
147
section P2
108
-
X : item1, 1912, 1913
109
-
Backing : item2, 1913, 1918
110
-
Inclusion : item3, 1918, 1924
111
-
```
148
+
X : item1, 1906, 1908
149
+
Backing : item2, 1908, 1918
150
+
Inclusion : item3, 1918, 1924
151
+
152
+
section P3
153
+
X : item1, 1912, 1914
154
+
Backing : item2, 1914, 1924
155
+
Inclusion : item3, 1924, 1930
112
156
113
-
In the asynchronous scenario, where both the collators and validators have access to Unincluded Segments 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.
157
+
section P4
158
+
X : item1, 1918, 1920
159
+
Backing : item2, 1920, 1930
160
+
```
114
161
115
-
This results in one parablock being processed *every* relay block, and allows for more time to execute during the Generation step (0.5s --> 2s).
162
+
Notice how `P2` starts before the backing stage of `P1`
|**Parablocks included every**| 12 seconds | 6 seconds |**2x** more parablocks included |
191
-
|**Parablock maximum execution time**| 0.5 seconds | 2 seconds |**4x** more execution time in a parablock |
192
-
|**Total Computer Gain (per core)**|||**8x Compute Throughput**|
243
+
section F22
244
+
SPACING : p1padTop, 1901, 1930
193
245
194
-
## Configurations
195
-
The following configurations can be set by onchain governance:
196
246
197
-
*[`max_candidate_depth`](https://github.com/paritytech/polkadot-sdk/blob/f204e3264f945c33b4cea18a49f7232c180b07c5/polkadot/primitives/src/vstaging/mod.rs#L49): the number of parachain blocks a collator can produce that are not yet included in the relay chain.
198
-
*[`allowed_ancestry_len`](https://github.com/paritytech/polkadot-sdk/blob/f204e3264f945c33b4cea18a49f7232c180b07c5/polkadot/primitives/src/vstaging/mod.rs#L54): the oldest relay chain parent a parachain block can be built on top of.
0 commit comments