Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wiki Reorg: Sharding and Asynchronous Backing #4782

Closed
wants to merge 3 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,7 @@ pids

# IDEs
.idea
.vscode/settings.json

# Directory for instrumented libs generated by jscoverage/JSCover
lib-cov
Expand Down
Binary file added docs/assets/asyncbacking.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
60 changes: 57 additions & 3 deletions docs/learn/learn-parachains-protocol.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,9 +31,8 @@ and the
The Parachains' Protocol aims to carry a parachain's block from authoring to inclusion through a
process that can be carried out repeatedly and in parallel for each parachain connected to the Relay
Chain. The protocol allows the network to be efficiently sharded among parachains while maintaining
strong security guarantees. The Availability and Validity (AnV) Protocol describes the
Parachain Protocol from the perspective of availability and validity.
on).
strong security guarantees. The Availability and Validity (AnV) Protocol describes the Parachain
Protocol from the perspective of availability and validity. on).

## Main Actors

Expand Down Expand Up @@ -191,6 +190,59 @@ status, and it can only be considered a part of the parachain once proven availa
this stage validators of the Relay Chain already received the
[erasure coding information](#erasure-codes) of that specific parablock.

### Asynchronous Backing

Asynchronous backing is a mechanism that introduces a _pipeline_ for parachain **<->** relay chain
communication. This pipeline will allow collators to include more data in parachain blocks while
reducing latency (from 12 to 6 seconds for parablock validation).

It has three overarching goals:

1. Decrease parablock validation time to **6 seconds** from **12 seconds**
2. Increase the amount of usable blockspace by a factor of 5-10, meaning more state changes allowed
per block.
3. Allow for parachain blocks (parablocks) to be re-proposed to the network in the event that they
aren't included initially on the first attempt.

Asynchronous backing works by providing a form of **contextual execution**, which allows for more
time for parachain collators to fit more transactions and ready block candidates for backing and
inclusion.

![async-backing](../assets/asyncbacking.png)

_Notice that blocks can be prepared for longer, meaning more transactions per block. Due to the
asynchrony, these blocks can be prepared in anticipation of being included later, rather than
keeping in sync with the relay chain's progress 1-1_

:::info How does this compare to Ethereum's Danksharding?

One can think of asynchronous backing as the Polkadot equivalent to Ethereum's Danksharding. Where
Ethereum merely increases the amount of space per block for rollup related solutions, asynchronous
backing provides a way for collators to build blocks with the intent of publishing asynchronously
them later on.

Where Ethereum is looking to increase the size of each block as a means for rollup solutions,
asynchronous backing builds on the existing parachains protocol to provide a way to further
parallelize the processing of parachain blocks, increasing scalability and throughput in a single
go.

:::

This combination of lower latency, higher storage per block, and logical pipeline spanning
Polkadot's networking, runtime, and collator aspects will allow for higher, more robust throughput.
The speed is doubled while block storage is significantly increased, allowing the network to become
increasingly more scalable and robust.

#### What was wrong with the previous architecture?

A current limitation to scaling throughput in terms of speed is that parablock validation is tightly
coupled to the relay chain's progression on a 1-1 basis. Parablocks are very much dependent on being
in sync with the relay chain, which reduces the amount of data that can be put into the block.
Essentially, it's rushing to be a part of the relay chain due to this synchrony.

By making this process of backing para blocks more asynchronous, they get the chance to not only
include more data, but also "retry" at a later time to be included in the relay chain.

### Availability and Unavailability Phase

During the availability and unavailability phases, the validators will participate to **Availability
Expand Down Expand Up @@ -521,3 +573,5 @@ coexist for some time as there will be validators aware of both chain heads.
order to progress the parachain.
- [Availability and Validity](https://github.com/w3f/research/tree/85cd4adfccb7d435f21cd9fd249cd1b7f5167537/docs/papers/AnV) -
Paper by the W3F Research Team that specifies the availability and validity protocol in detail.
- [Polkadot Roadmap Roundup](https://polkadot.network/blog/polkadot-roadmap-roundup) - Article by
Rob Habermeier, Polkadot founder that details the plans for Polkadot for 2023.