Skip to content

Commit 317b284

Browse files
charlesHetterichcharlesHetterich
committed
fixed mermaid chart
1 parent 86f6a2f commit 317b284

File tree

6 files changed

+78
-239
lines changed

6 files changed

+78
-239
lines changed

‎.ai/categories/polkadot-protocol.md‎

Lines changed: 25 additions & 111 deletions
Original file line numberDiff line numberDiff line change
@@ -777,11 +777,10 @@ The following configurations can be set by on-chain governance, dictating how ma
777777

778778
## Synchronous VS. Asynchronous Processing
779779

780-
*in progress*
781780

782-
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 block, and only `0.5` seconds are assigned for execution.
783781

784-
<div className="merm-16x9">
782+
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.
783+
785784
```mermaid
786785
---
787786
displayMode: compact
@@ -790,20 +789,29 @@ In the synchronous scenario, both the collators and validators draw context from
790789
#item1 { fill: #450693; stroke: #450693; } \n
791790
#item2 { fill: #8C00FF; stroke: #8C00FF; } \n
792791
#item3 { fill: #FFC400; stroke: #FFC400; } \n
793-
#r { fill: #eb4172; stroke: none; } \n
794-
#p1padTop { display: none; } \n
792+
#r { fill: #eb4172; stroke:none; font-size: 20px; } \n
793+
svg text { font-size: 20px !important; } \n
794+
svg .sectionTitle { font-size: 20px !important; } \n #p1padTop { display: none; } \n
795795

796-
/* Hide ALL task labels (inside or outside), across breakpoints */
796+
/* Hide ALL task labels by default */
797797
text.taskText,
798798
text.taskTextOutside,
799799
[class*='taskText'] tspan { display: none !important; } \n
800800

801-
/* Keep outside labels + section titles styled */
802-
.taskTextOutside, .sectionTitle { fill: #000 !important; color: #000 !important; font-weight: 700; } \n
801+
/* Show labels for the 'r' group (inside or outside, incl. tspans) */
802+
text.taskText[id^='r'],
803+
text.taskTextOutside[id^='r'],
804+
text[id^='r'] tspan { display: inline !important; font-size: 20px; color: #000 !important; } \n
803805

806+
/* Keep section titles styled */
807+
.sectionTitle { fill: #000 !important; font-weight: 700; font-size: 18px; } \n
804808

805-
svg { width: 100% !important; height: auto !important; aspect-ratio: 21 / 9; } \n
809+
/* Hide the first two section titles (F1, F2). Change indexes if needed. */
810+
.sectionTitle:nth-of-type(1),
811+
.sectionTitle:nth-of-type(2) { display: none !important; } \n
806812

813+
/* Also hide SPACING row labels on the left */
814+
text.taskTextOutside[id^='p1padTop'] { display: none !important; } \n
807815
"
808816
themeVariables:
809817
sectionBkgColor: '#fff'
@@ -812,6 +820,7 @@ In the synchronous scenario, both the collators and validators draw context from
812820
barHeight: 70
813821
gridLineStartPadding: 100
814822
---
823+
%%{init: {"gantt": {"barHeight": 70 }}}%%
815824
gantt
816825
dateFormat YYYY
817826
axisFormat %y
@@ -826,7 +835,6 @@ gantt
826835
section F2
827836
SPACING : p1padTop, 1901, 1924
828837

829-
830838
section P1
831839
X : item1, 1900, 1901
832840
Backing : item2, 1901, 1906
@@ -836,12 +844,15 @@ gantt
836844
X : item1, 1912, 1913
837845
Backing : item2, 1913, 1918
838846
Inclusion : item3, 1918, 1924
847+
848+
839849
```
840-
</div>
841850

842-
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.
843851

844-
This results in one parablock being processed *every* relay block, and allows for `2` seconds of execution.
852+
853+
The modern protocol now uses asynchronous backing, where both 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.
854+
855+
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).
845856

846857
```mermaid
847858
---
@@ -918,103 +929,6 @@ gantt
918929
Backing : item2, 1920, 1930
919930
```
920931

921-
Notice how `P2` starts before the backing stage of `P1`.
922-
923-
In the multi-core scenario
924-
```mermaid
925-
---
926-
displayMode: compact
927-
config:
928-
themeCSS: "
929-
#item1 { fill: #450693; stroke: #450693; } \n
930-
#item2 { fill: #8C00FF; stroke: #8C00FF; } \n
931-
#item3 { fill: #FFC400; stroke: #FFC400; } \n
932-
#r { fill: #eb4172; stroke: none; } \n
933-
#p1padTop { display: none; } \n
934-
text.taskText[id^=p1padTop] { fill: none !important; color: #000 !important; } \n
935-
936-
937-
/* Default inside task text: white */ \n
938-
.taskText { fill: #fff !important; color: #fff !important; font-weight: 700; font-size: 18px; } \n
939-
940-
/* Hide text inside bars */
941-
.taskText { display: none !important; } \n
942-
943-
/* Outside labels and section titles: black */ \n
944-
.taskTextOutside, .sectionTitle { fill: #000 !important; color: #000 !important; font-weight: 700; font-size: 18px; } \n
945-
946-
/* Inside text for #r items: black */ \n
947-
text.taskText[id^=r] { fill: #fff !important; } \n
948-
"
949-
themeVariables:
950-
sectionBkgColor: '#fff'
951-
gantt:
952-
numberSectionStyles: 1
953-
barHeight: 70
954-
gridLineStartPadding: 100
955-
---
956-
%%{init: {"gantt": {"barHeight": 70 }}}%%
957-
gantt
958-
dateFormat YYYY
959-
axisFormat %y
960-
%% this next line doesn't recognise 'decade' or 'year', but will silently ignore
961-
tickInterval '10year'
962-
963-
section F1
964-
R1 : r, 1905, 1907
965-
R2 : r, 1911, 1913
966-
R3 : r, 1917, 1919
967-
R4 : r, 1923, 1925
968-
R5 : r, 1929, 1931
969-
970-
section F2
971-
SPACING : p1padTop, 1901, 1930
972-
973-
section P1
974-
X : item1, 1900, 1902
975-
Backing : item2, 1902, 1912
976-
Inclusion : item3, 1912, 1918
977-
978-
section P2
979-
X : item1, 1906, 1908
980-
Backing : item2, 1908, 1918
981-
Inclusion : item3, 1918, 1924
982-
983-
section P3
984-
X : item1, 1912, 1914
985-
Backing : item2, 1914, 1924
986-
Inclusion : item3, 1924, 1930
987-
988-
section F20
989-
SPACING : p1padTop, 1901, 1930
990-
991-
section F21
992-
R1 : r, 1905, 1907
993-
R2 : r, 1911, 1913
994-
R3 : r, 1917, 1919
995-
R4 : r, 1923, 1925
996-
R5 : r, 1929, 1931
997-
998-
section F22
999-
SPACING : p1padTop, 1901, 1930
1000-
1001-
1002-
section P4
1003-
X : item1, 1900, 1902
1004-
Backing : item2, 1902, 1912
1005-
Inclusion : item3, 1912, 1918
1006-
1007-
section P5
1008-
X : item1, 1906, 1908
1009-
Backing : item2, 1908, 1918
1010-
Inclusion : item3, 1918, 1924
1011-
1012-
section P6
1013-
X : item1, 1912, 1914
1014-
Backing : item2, 1914, 1924
1015-
Inclusion : item3, 1924, 1930
1016-
```
1017-
1018932

1019933
---
1020934

@@ -5373,7 +5287,7 @@ flowchart LR
53735287

53745288
**Generation**: Collators *execute* their blockchain's core functionality to generate a new block, producing a [proof-of-validity](https://paritytech.github.io/polkadot-sdk/book/types/availability.html?#proof-of-validity) (PoV), which is passed to validators selected for backing. The PoV is composed of:
53755289

5376-
- The block candidate (list of state transitions)
5290+
- A list of state transitions called the **block candidate**
53775291
- The values in the parachain's database that the block modifies
53785292
- The hashes of the unaffected points in the Merkle tree
53795293

‎.ai/pages/reference-parachains-consensus-async-backing.md‎

Lines changed: 24 additions & 110 deletions
Original file line numberDiff line numberDiff line change
@@ -17,11 +17,10 @@ The following configurations can be set by on-chain governance, dictating how ma
1717

1818
## Synchronous VS. Asynchronous Processing
1919

20-
*in progress*
2120

22-
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 block, and only `0.5` seconds are assigned for execution.
2321

24-
<div className="merm-16x9">
22+
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.
23+
2524
```mermaid
2625
---
2726
displayMode: compact
@@ -30,20 +29,29 @@ In the synchronous scenario, both the collators and validators draw context from
3029
#item1 { fill: #450693; stroke: #450693; } \n
3130
#item2 { fill: #8C00FF; stroke: #8C00FF; } \n
3231
#item3 { fill: #FFC400; stroke: #FFC400; } \n
33-
#r { fill: #eb4172; stroke: none; } \n
34-
#p1padTop { display: none; } \n
32+
#r { fill: #eb4172; stroke:none; font-size: 20px; } \n
33+
svg text { font-size: 20px !important; } \n
34+
svg .sectionTitle { font-size: 20px !important; } \n #p1padTop { display: none; } \n
3535
36-
/* Hide ALL task labels (inside or outside), across breakpoints */
36+
/* Hide ALL task labels by default */
3737
text.taskText,
3838
text.taskTextOutside,
3939
[class*='taskText'] tspan { display: none !important; } \n
4040
41-
/* Keep outside labels + section titles styled */
42-
.taskTextOutside, .sectionTitle { fill: #000 !important; color: #000 !important; font-weight: 700; } \n
41+
/* Show labels for the 'r' group (inside or outside, incl. tspans) */
42+
text.taskText[id^='r'],
43+
text.taskTextOutside[id^='r'],
44+
text[id^='r'] tspan { display: inline !important; font-size: 20px; color: #000 !important; } \n
4345
46+
/* Keep section titles styled */
47+
.sectionTitle { fill: #000 !important; font-weight: 700; font-size: 18px; } \n
4448
45-
svg { width: 100% !important; height: auto !important; aspect-ratio: 21 / 9; } \n
49+
/* Hide the first two section titles (F1, F2). Change indexes if needed. */
50+
.sectionTitle:nth-of-type(1),
51+
.sectionTitle:nth-of-type(2) { display: none !important; } \n
4652
53+
/* Also hide SPACING row labels on the left */
54+
text.taskTextOutside[id^='p1padTop'] { display: none !important; } \n
4755
"
4856
themeVariables:
4957
sectionBkgColor: '#fff'
@@ -52,6 +60,7 @@ In the synchronous scenario, both the collators and validators draw context from
5260
barHeight: 70
5361
gridLineStartPadding: 100
5462
---
63+
%%{init: {"gantt": {"barHeight": 70 }}}%%
5564
gantt
5665
dateFormat YYYY
5766
axisFormat %y
@@ -66,7 +75,6 @@ gantt
6675
section F2
6776
SPACING : p1padTop, 1901, 1924
6877
69-
7078
section P1
7179
X : item1, 1900, 1901
7280
Backing : item2, 1901, 1906
@@ -76,12 +84,15 @@ gantt
7684
X : item1, 1912, 1913
7785
Backing : item2, 1913, 1918
7886
Inclusion : item3, 1918, 1924
87+
88+
7989
```
80-
</div>
8190

82-
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.
8391

84-
This results in one parablock being processed *every* relay block, and allows for `2` seconds of execution.
92+
93+
The modern protocol now uses asynchronous backing, where both 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.
94+
95+
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).
8596

8697
```mermaid
8798
---
@@ -157,100 +168,3 @@ gantt
157168
X : item1, 1918, 1920
158169
Backing : item2, 1920, 1930
159170
```
160-
161-
Notice how `P2` starts before the backing stage of `P1`.
162-
163-
In the multi-core scenario
164-
```mermaid
165-
---
166-
displayMode: compact
167-
config:
168-
themeCSS: "
169-
#item1 { fill: #450693; stroke: #450693; } \n
170-
#item2 { fill: #8C00FF; stroke: #8C00FF; } \n
171-
#item3 { fill: #FFC400; stroke: #FFC400; } \n
172-
#r { fill: #eb4172; stroke: none; } \n
173-
#p1padTop { display: none; } \n
174-
text.taskText[id^=p1padTop] { fill: none !important; color: #000 !important; } \n
175-
176-
177-
/* Default inside task text: white */ \n
178-
.taskText { fill: #fff !important; color: #fff !important; font-weight: 700; font-size: 18px; } \n
179-
180-
/* Hide text inside bars */
181-
.taskText { display: none !important; } \n
182-
183-
/* Outside labels and section titles: black */ \n
184-
.taskTextOutside, .sectionTitle { fill: #000 !important; color: #000 !important; font-weight: 700; font-size: 18px; } \n
185-
186-
/* Inside text for #r items: black */ \n
187-
text.taskText[id^=r] { fill: #fff !important; } \n
188-
"
189-
themeVariables:
190-
sectionBkgColor: '#fff'
191-
gantt:
192-
numberSectionStyles: 1
193-
barHeight: 70
194-
gridLineStartPadding: 100
195-
---
196-
%%{init: {"gantt": {"barHeight": 70 }}}%%
197-
gantt
198-
dateFormat YYYY
199-
axisFormat %y
200-
%% this next line doesn't recognise 'decade' or 'year', but will silently ignore
201-
tickInterval '10year'
202-
203-
section F1
204-
R1 : r, 1905, 1907
205-
R2 : r, 1911, 1913
206-
R3 : r, 1917, 1919
207-
R4 : r, 1923, 1925
208-
R5 : r, 1929, 1931
209-
210-
section F2
211-
SPACING : p1padTop, 1901, 1930
212-
213-
section P1
214-
X : item1, 1900, 1902
215-
Backing : item2, 1902, 1912
216-
Inclusion : item3, 1912, 1918
217-
218-
section P2
219-
X : item1, 1906, 1908
220-
Backing : item2, 1908, 1918
221-
Inclusion : item3, 1918, 1924
222-
223-
section P3
224-
X : item1, 1912, 1914
225-
Backing : item2, 1914, 1924
226-
Inclusion : item3, 1924, 1930
227-
228-
section F20
229-
SPACING : p1padTop, 1901, 1930
230-
231-
section F21
232-
R1 : r, 1905, 1907
233-
R2 : r, 1911, 1913
234-
R3 : r, 1917, 1919
235-
R4 : r, 1923, 1925
236-
R5 : r, 1929, 1931
237-
238-
section F22
239-
SPACING : p1padTop, 1901, 1930
240-
241-
242-
section P4
243-
X : item1, 1900, 1902
244-
Backing : item2, 1902, 1912
245-
Inclusion : item3, 1912, 1918
246-
247-
section P5
248-
X : item1, 1906, 1908
249-
Backing : item2, 1908, 1918
250-
Inclusion : item3, 1918, 1924
251-
252-
section P6
253-
X : item1, 1912, 1914
254-
Backing : item2, 1914, 1924
255-
Inclusion : item3, 1924, 1930
256-
```

‎.ai/pages/reference-parachains-consensus-inclusion-pipeline.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -40,7 +40,7 @@ flowchart LR
4040

4141
**Generation**: Collators *execute* their blockchain's core functionality to generate a new block, producing a [proof-of-validity](https://paritytech.github.io/polkadot-sdk/book/types/availability.html?#proof-of-validity) (PoV), which is passed to validators selected for backing. The PoV is composed of:
4242

43-
- The block candidate (list of state transitions)
43+
- A list of state transitions called the **block candidate**
4444
- The values in the parachain's database that the block modifies
4545
- The hashes of the unaffected points in the Merkle tree
4646

0 commit comments

Comments
 (0)