diff --git a/.gitignore b/.gitignore index 290b8ddf0080..daba94c81c92 100644 --- a/.gitignore +++ b/.gitignore @@ -13,6 +13,7 @@ pids # IDEs .idea +.vscode/settings.json # Directory for instrumented libs generated by jscoverage/JSCover lib-cov diff --git a/docs/assets/asyncbacking.png b/docs/assets/asyncbacking.png new file mode 100644 index 000000000000..6e6a87820945 Binary files /dev/null and b/docs/assets/asyncbacking.png differ diff --git a/docs/learn/learn-parachains-protocol.md b/docs/learn/learn-parachains-protocol.md index 044798488022..0a8eeeabc06e 100644 --- a/docs/learn/learn-parachains-protocol.md +++ b/docs/learn/learn-parachains-protocol.md @@ -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 @@ -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 @@ -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.