What is Asynchronous Backing?
Asynchronous Backing recently made it to the latest proposed runtime upgrade on Kusama and is set to launch on Polkadot soon. Asynchronous Backing brings a multitude of advantages to Polkadot, including less wastage of Parachain blocks, approximately 8x boost in the quantity of available blockspace, etc, and is also an important feature when it comes to implementing resource allocation methods like Exotic Core Scheduling (which is needed for flexible use of core time).
But what exactly is Asynchronous Backing, and how does it compare to the (soon-to-be legacy) Synchronous Backing? Read on to find out.
Note: throughout this article, P refers to a Parablock (eg, P10 = Parablock 10) and RC Block refers to a Relay Chain Block (eg, RC Block 20 = Relay Chain Block 20)
The Path of Parachain Blocks to the Relay Chain
As a reminder, collators of parachains bundle up transactions of parachains in parablocks. These parablocks are then validated, backed, and included (made available) on the Relay Chain.
To understand Asynchronous Backing, it’s important to have a general idea of the path of a parablock, from candidacy on the collator side to inclusion on the relay chain. a parablock has to take multiple steps (some of which include seconding, being backable, actual backing, pending availability, etc) before pre-finality inclusion in a Relay Chain block. Amidst all these steps, the most important things you need to know to understand Asynchronous Backing are that:
1. Parachains’ collators are in charge of creating parachain blocks (each parablock is a candidate that has a chance of being added to the relay chain). The more time the collators have to create a parachain block, the more transactions (extrinsics) they’re able to fill up the block with.
2. All parablocks are initially anchored to a block on the Relay Chain. This block is called the relay parent. The parachain collator will need to refer to the relay parent to be able to generate the next parablock. For example, if parablock 10 is anchored to RC block 20, RC block 20 becomes the relay parent. This means the parachain collator will need context from RC block 20 to be able to generate parablock 11.
3. An anchored parablock is backed in another Relay Chain block. But backing a block doesn’t mean the block is valid yet.
4. Backed parablocks are then sent to other validators, after which they’re included in the Relay Chain (in the form of candidate receipts that contain the change in parachain state in that block)
It’s important to understand the 4 steps above before moving on.
Synchronous Backing and its Limitation
In synchronous backing, it takes 12 seconds (2 relay block times) from parablock generation to the addition to the relay chain. 6 seconds for pre-inclusion tasks like parablock generation, backing, etc. and 6 seconds for inclusion. Also, collators can only anchor their parablocks to the last Relay Chain block. This will mean they have exactly 12 seconds from generation to inclusion of their blocks in the Relay Chain to remain in synchrony with the Relay Chain blocks. For example, if RC block 20 is the last RC Block, and has parablock 10 anchored to it, parablock 10 will have to be backed in RC Block 21 (in 6 seconds) and included in RC Block 22 (in another 6 seconds).
This synchronous backing process leads to a couple of limitations:
1. A lot of processes need to take place (eg actual creation of the parablocks, submission to Relay Chain validators, execution, backing, and gossiping) before inclusion, and all these have to take place in the latest Relay Chain block to be backed in the next block (i.e., within 6 seconds).
Because of this, the collators have very limited time (around 0.5 seconds) to create parablocks. This time is not enough to fill up the parablock with as many transactions (extrinsics) as possible. Consequently, there’s a wastage of blockspace since most parablocks end up being filled only up to a fraction of their capacity.
2. In synchronous backing a parablock has to be anchored to the last relay chain block for this block to be accepted as a relay parent. Also, information (context) needed to build a new parablock can only be drawn from the latest included parablock ancestor (in this case, the parablock in the latest relay chain block). This means you can only create a new parablock after including the previous one (ie, after every 12 sec).
For example, if parablock 10 is anchored to RC Block 20 (which is the latest RC Block), parablock 10 has to be backed in RC Block 21 and included in RC Block 22 (i.e. after 12 seconds in total) before the collators can use its context to create a new parablock.
This is the reason why parachain block times are twice that of the relay chain block time (12 seconds versus 6 seconds).
Parablocks not being filled up and long parachain block times collectively lead to significantly less efficient use of blockspace.
How Asynchronous Backing is Better?
The whole aim of Asynchronous Backing is to reduce blockspace and parablock wastage by:
- Optimizing the time needed to create and fill up parachain blocks.
- Optimizing the time needed to include parachain blocks in the Relay Chain.
- Allowing parablocks to be recycled if not included in the Relay Chain in the first attempt.
These are achieved by:
1. Allowing collators to start building/anchor parablocks 6 seconds in advance. Unlike in synchronous backing where parachain blocks can only be added to the last Relay Chain block, in Asynchronous Backing, parachain blocks can be anchored to the second last relay chain block too. This provides an extra 6-second window before the Relay Chain block is backed.
For example, let’s say RC Block 20 is the latest relay chain block, and P10 an unincluded parachain block. In this case, P10 will have to be backed in RC Block 21 and included in RC Block 22. But in Asynchronous Backing,P10 can be anchored to RC Block 19 (i.e., the second-last RC Block) instead of toRC Block 20 (the last RC Block).
This means P10 has a window of 2 Relay Chain block times (block time between RC Block 19 and RC Block 20 and block time between RC Block 20 and RC Block 21 i.e., 12 seconds) to generate a parablock, submit to validators, execute, back, and gossip. This is in contrast with only 1 relay chain block time window (block time between RC Block 20 and RC Block 21, i.e. 6 seconds) in the case of Synchronous Backing.
The result of this is that there is always a parablock available to be backed in all Relay Chain blocks, thereby reducing the block time of parachains to 6 seconds (ie, the same as that of the relay chain). Parachain blocks created by the collators that haven’t been included yet are stored on the parachain’s collator as unincluded segments.
Notice that the time it takes from backing to inclusion doesn’t change. All this does is allow the process to start 6 seconds earlier, hence increasing the allocated pre-inclusion time to 12 seconds.
2. Allowing a single relay chain block to both back and include parachain blocks.
What this essentially means is that a single RC block can both include a previously backed block, and back a previously anchored block at the same time.
For example, let’s say RC Block 19 is the second-latest RC block and RC Block 20 is the latest relay chain block. Also, P10, P11 and P12 are all unincluded segments stored by the parachain collator. Since collators are allowed to anchor blocks 6 seconds (1 block time) earlier, this will mean that anchoring can start from the second latest relay chain block, giving each parablock the span 2 block times (12 seconds) for backing. Taking these into consideration, this would mean that:
P10 is anchored in Rc block 19, backed in Rc block 21 (ie, after 2 block times, 12 sec) and included in Rc block 22P11 is anchored in Rc block 20, backed in Rc block 22 and included in Rc block 23P12 is anchored in Rc block 21, backed in Rc block 23 and included in Rc block 24
When expanded, this translates to:
Rc block 19: anchores P10, Backs P8 and includes P7Rc block 20: anchores P11, Backs P9 and includes P8Rc block 21: anchores P12, Backs P10 and includes P9Rc block 22: anchores P13, Backs P11 and includes P10Rc block 23: Anchores P14, Backs P12 and includes P11Rc block 24: Anchores P15, Backs P13 and includes P12- and so on…
Notice that each of the Relay Chain block above anchores a parablock, while at the same time backing and including other parablocks. This is called pipelining and ensures that parablocks are included in every relay chain block.
3. Unincluded blocks can be re-proposed if not included in the relay chain in the first attempt.
This ensures that already generated parablocks don’t go to waste, hence reducing wastage.
These changes bring about some significant adavantages for the relay chain and parachains:
1. More time is available for collators to fill up parablocks. Since collators will have 12 seconds to carry out all pre-inclusion tasks (versus 6 seconds in synchronous backing). Collators now have 2 seconds (versus 0.5 seconds in synchronous backing) to fill up blocks. This translates to approximately 4x more data (extinsics) being filled up in each parablock.
2. Less parachain block time. Because inclusion will occur in every Relay Chain block (i.e every 6 seconds) with Asynchronous Backing versus in every 2 Relay Chain blocks (i.e, every 12 seconds) with Asynchronous Backing, The time taken to include a parachain block in the Relay Chain is slashed by half, translating to an x2 throughput.
3. Less parablock wastage since unincluded blocks can be re-proposed if not included in Relay Chain in the first attempt.
4x more extrinsics per parablock and 2x more throughput mean that Asynchronous Backing brings about approximately x8 boost in blockspace. How awesome is that!
Asynchronous Backing and Exotic Core Scheduling
Asynchronous Backing is an important feature needed for Exotic Core Scheduling, an interesting implementation that allows a single parachain to use multiple cores for a single parachain at the same time and allows for a lot of flexibility regarding leasing/renting of cores of various quantities and lengths.
Expect an article on Exotic Core Scheduling… coming soon!