removed comments from async backing docs

Author: charlesHetterich

.reference/parachains/consensus/async-backing.md

@@ -20,8 +20,6 @@ The following configurations can be set by on-chain governance, dictating how ma
 
 ## Synchronous VS. Asynchronous Processing
 
-<!-- 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. -->
-
 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.
 
 ```mermaid
@@ -91,10 +89,6 @@ gantt
 
 ```
 
-<!-- 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.
-
-This results in one parablock being processed *every* relay block, and allows for `2` seconds of execution. -->
-
 The modern protocol now uses asynchronous backing, where both collators and validators have access to [unincluded segments](/reference/parachains/consensus/inclusion-pipeline){target=\_blank} 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).
@@ -172,100 +166,4 @@ gantt
     section P4
     X         : item1, 1918, 1920
     Backing   : item2, 1920, 1930
-```
-
-<!-- In the multi-core scenario, by using elastic scaling we can further increase the the number of parablocks processed for each relay block. By using two cores, here we double the number of parablocks being processed in a 30 second period:
-
-```mermaid
----
-    displayMode: compact
-    config:
-        themeCSS: "
-            #item1 { fill: #450693; stroke: #450693; } \n
-            #item2 { fill: #8C00FF; stroke: #8C00FF; } \n
-            #item3 { fill: #FFC400; stroke: #FFC400; } \n
-            #r { fill: #eb4172; stroke: none; } \n
-            #p1padTop { display: none; } \n
-            text.taskText[id^=p1padTop] { fill: none !important; color: #000 !important; } \n
-
-
-            /* Default inside task text: white */ \n
-            .taskText { fill: #fff !important; color: #fff !important; font-weight: 700; font-size: 18px; } \n
-
-            /* Hide text inside bars */
-            .taskText { display: none !important; } \n
-
-            /* Outside labels and section titles: black */ \n
-            .taskTextOutside, .sectionTitle { fill: #000 !important; color: #000 !important; font-weight: 700; font-size: 18px; } \n
-
-            /* Inside text for #r items: black */ \n
-            text.taskText[id^=r] { fill: #fff !important; } \n
-        "
-        themeVariables:
-            sectionBkgColor: '#fff'
-        gantt:
-            numberSectionStyles: 1
-            barHeight: 70
-            gridLineStartPadding: 100
----
-%%{init: {"gantt": {"barHeight": 70 }}}%%
-gantt
-    dateFormat YYYY
-    axisFormat %y
-    %% this next line doesn't recognise 'decade' or 'year', but will silently ignore
-    tickInterval '10year'
-
-    section F1
-    R1 : r, 1905, 1907
-    R2 : r, 1911, 1913
-    R3 : r, 1917, 1919
-    R4 : r, 1923, 1925
-    R5 : r, 1929, 1931
-
-    section F2
-    SPACING : p1padTop, 1901, 1930
-
-    section P1
-    X   :            item1, 1900, 1902
-    Backing   :            item2, 1902, 1912
-    Inclusion   :            item3, 1912, 1918
-
-    section P2
-    X   :            item1, 1906, 1908
-    Backing   :            item2, 1908, 1918
-    Inclusion   :            item3, 1918, 1924
-    
-    section P3
-    X   :            item1, 1912, 1914
-    Backing   :            item2, 1914, 1924
-    Inclusion   :            item3, 1924, 1930
-
-    section F20
-    SPACING : p1padTop, 1901, 1930
-
-    section F21
-    R1 : r, 1905, 1907
-    R2 : r, 1911, 1913
-    R3 : r, 1917, 1919
-    R4 : r, 1923, 1925
-    R5 : r, 1929, 1931
-
-    section F22
-    SPACING : p1padTop, 1901, 1930
-
-
-    section P4
-    X   :            item1, 1900, 1902
-    Backing   :            item2, 1902, 1912
-    Inclusion   :            item3, 1912, 1918
-
-    section P5
-    X   :            item1, 1906, 1908
-    Backing   :            item2, 1908, 1918
-    Inclusion   :            item3, 1918, 1924
-    
-    section P6
-    X   :            item1, 1912, 1914
-    Backing   :            item2, 1914, 1924
-    Inclusion   :            item3, 1924, 1930
-``` -->
+```