Asynchronous Backing (Shallow)

Shallow Dive, Asynchronous Backing

Notes:

Hello again everyone

Today I'll be speaking to you about asynchronous backing, the new feature which delivers shorter parachain block times and an order of magnitude increase in quantity of Polkadot blockspace.

Lets get to it

Overview

Synchronous Backing Simplified

Notes:

• The dividing line between the left and right is when a candidate is backed on chain
• Approvals, disputes, and finality don't immediately gate the production of farther candidates. So we don't need to represent those steps in this model.

Async Backing Simplified

Notes:

Our cache of parablock candidates allows us to pause just before that dividing line, on-chain backing

The Async Backing Optimistic Collator Assumptions

The Stakes Are Low

Notes:

Best is determined by a process similar to the BABE fork choice rule. Brief BABE fork choice rule review

Advantages of Asynchronous Backing

Notes:

1. Collators have more time to fill each block
2. Advance work ensures backable candidates for each parachain are present to be backed on the relay chain every 6 seconds
3. Self explanatory
4. Allow parachain blocks to be ‘reused’ when they don’t make it onto the relay chain in the first attempt

Parablock Validation Pipelining

Synchronous Backing, Another Look

Notes:

Image version 1:

• Now let's take a closer look at when each step of backing and inclusion takes place both with synchronous and asynchronous backing.

Image version 3:

• Whole process is a cycle of duration 12 seconds (2 relay blocks).
• No part of this cycle can be started for a second candidate of the same parachain until the first is included.

Async Backing, Another Look

Note:

Image version 1:

• Candidates stored in prospective parachains (detail on that later)

Image version 2:

• Now we see our relay block cycle.
• It is 6 seconds rather than 12.
• It completes on-chain backing for one candidate and inclusion for another each cycle.

Image version 3:

• Collation generation and off-chain backing are outside of the relay block cycle.
• Because of this, collators have the freedom to work several blocks in advance. In practice, even working 2-3 blocks in advance gives a collator ample time to fully fill blocks (PoV size 5MiB)
• Notice that a part of the collation generation context, the unincluded segment, comes from the collator itself.

The Unincluded Segment

Notes:

Limitation example, upward messages remaining before the relay chain would have to drop incoming messages from our parachain

Unincluded Segment

Notes:

• Segment added to as each new block is imported into the parachain runtime
• Segment shrinks when one of its ancestor blocks becomes included
• Maximum unincluded segment capacity is set both on the parachain and relay chain

Unincluded Segment

Notes:

UsedBandwidth:

• pub ump_msg_count: u32,
• pub ump_total_bytes: u32,
• pub hrmp_outgoing: BTreeMap<ParaId, HrmpChannelUpdate>,

Prospective Parachains

Prospective Parachains Snapshot

Notes:

• Fragment trees only built for active leaves
• Fragment trees built per scheduled parachain at each leaf
• Fragment trees may have 0 or more fragments representing potential parablocks making up possible futures for a parachain's state.
• Collation generation, passing, and seconding work has already been completed for each fragment.

Async Backing Simplified

Notes:

Returning to our most basic diagram

• Q: Which structure did I leave out the name of for simplicity, and where should that name go in our diagram?
• Q: Which did I omit entirely?

Async Backing and Exotic Core Scheduling

Notes:

• What is exotic core scheduling?
  • Multiple cores per parachain
  • Overlapping leases of many lengths
  • Lease + On-demand
• How does asynchronous backing help?
• The unincluded segment is necessary to build 2 or more parablocks in a single relay block

Resources