Development of Polkadot parallel threads has already begun. Learn how it works.

Polkadot's parallel thread development has started. Learn about it.

Translation:

Compiled by: PolkaWorld

Development of on-demand parallel chains (also known as Blockingrathreads) has begun! Many people are waiting for the launch of parallel threads. This article will share what parallel threads are, how to obtain the right to produce blocks, and the process of collecting people’s validation.

On-demand parallel chains are the first variant of a more dynamic way to obtain block space. Existing parallel chains provide a very static way to obtain block space, namely by winning an auction and then being able to use guaranteed block space for a long time, such as a year. Currently, parallel chains produce a block every 12 seconds throughout the period. This periodic production of blocks is indeed a guarantee capability needed by some applications/chains and is one of the characteristics that makes parallel chains superior to smart contracts.

• Will the combination of the ZK and OP methods become the future of Ethereum Rollup?
• Has the PoW Narrative Renaissance become a dream as BCH tripled in two weeks?
• I have drawn over 100,000 robot images, and my Twitter avatar is full of these pictures. This AI painting competition is becoming very popular.

However, from a network perspective, this is too heavy for some applications, and they become parallel chains, leading to a waste of resources. From the perspective of users, winning an auction is a relatively high threshold, making it difficult for new projects and ideas to join the network. Through on-demand parallel chains, we not only reduce this threshold, but also open the network to applications that do not require a lot of resources in a more efficient way.

So how does this work? An on-demand parallel chain does not schedule block generation every 12 seconds, but when needed, a collector will order a core (a block generation opportunity) and send a special transaction (extrinsic) to Polkadot’s relay chain, indicating that they want a core for their BlockingraId and including the highest price they are willing to pay.

Order a Core

The relay chain runtime will calculate the best price for the current core. If the highest price of a new order is equal to or higher and the account’s funds are sufficient, the current best price will be charged, and block production authorization will be arranged for the block producer soon. The price is calculated by the relay chain based on the current demand. It is based on the same mechanism as the fee to slowly reflect demand and avoid drastic fluctuations in price.

Polkadot co-founder Robert added to this, explaining that in the fee payment mechanism in Blockingrathreads, regardless of how much the bidder is willing to pay, the fee paid is the same. When demand for on-demand parallel chains is high, the price of cores will slowly rise in an automatically adjustable manner.

There may be a “MEV” problem in this situation, which refers to the additional benefits that miners or validators can obtain by manipulating the order or included transactions of transactions. For example, validators may choose to delay processing orders with higher bids in order to collect or destroy more fees. However, Polkadot’s “mortal extrinsics” restricts this possibility. “Mortal extrinsics” are transactions with a lifecycle, which means that these transactions will not wait to be processed forever and will be automatically discarded after a period of time, thus limiting the operating space of validators.

In order for parallel threads to be able to use existing security mechanisms when requesting block production permissions, the transaction (extrinsic) that they send to request block production permissions must be signed. A “signed extrinsic” refers to a transaction that is sent by the account that uses its own private key to sign the transaction. This design is to prevent others from impersonating the account to send transactions, as no one other than the owner of the account can generate a signature that matches the public key of the account. Therefore, when the relay chain receives a signed transaction, it can confirm that the transaction was indeed sent by the claimed sender.

In addition, signed transactions can also include additional information, such as nonce (used to prevent replay attacks) and tip (used to give the block producer a tip). The relay chain already has a set of mechanisms to handle this information. Therefore, allowing demand-driven parallel chains to use signed transactions for block production requests can enable them to directly utilize these existing mechanisms without the need to develop new security mechanisms.

From the user’s perspective, this means that the total price to be paid includes three parts: the traditional transaction fee (this is the cost of paying for the computational resources required to process the transaction), an optional tip for the block producer (this is used to encourage block producers to prioritize processing their transactions), and the aforementioned core order price (i.e. the price of block production rights).

Integrating the order mechanism in the collection node

The actual block creation process is exactly the same for validation nodes (collection nodes) as it is for static parallel chains. Collection nodes (Collators) are nodes responsible for collecting and creating blocks. They regularly check the status of parallel chains, especially the parallel chains they are responsible for (identified by BlockingraId). If they find that the parallel chain corresponding to their BlockingraId is about to reach the time to create a block, they will start generating a new block. After generating the block, they need to produce a proof (Proof of Validity, referred to as PoV), which contains the content of the block and information proving that the block is valid. Then, they will send this PoV proof to the assigned backing group. The backing group is a group of nodes responsible for checking and confirming the validity of the block.

Although the process of block generation on an on-demand parachain is the same as that of a static parachain, we need to introduce a new mechanism in the collators to allow them to request block generation opportunities (“core bids”) when needed.

Currently, there are several possible strategies for designing this new mechanism (https://github.com/paritytech/cumulus/issues/2154). If you are interested in this issue, or if you have some familiarity with Cumulus, delving into this issue would be a great way to get involved in the project and help bring on-demand parachains to fruition more quickly.

Cumulus is a development framework for building parachains on the Polkadot and Kusama networks. It is developed by Blockingrity Technologies, one of the primary developers of Polkadot. Cumulus reduces the complexity of developers building parachains (Blockingrachains). When you use Cumulus to build a parachain, you can take advantage of some shared logic and functionality that has already been implemented in Cumulus, such as communication with the relay chain and handling block validation and finality. This allows developers to focus on their business logic without having to deal with these underlying issues.

Overall, Cumulus aims to make building parachains as simple as possible, thereby driving the development of the Polkadot and Kusama ecosystems.

Another important reminder is that if collators use a hot wallet (a wallet connected to the network) for their operations, there may be security risks. Therefore, we will provide a special type of proxy account that only has the permission to bid on the core of the on-demand parachain, thereby reducing security risks.

Integration of Asynchronous Support and More Details

For more interested technical audiences, all development of on-demand parachains is tracked here. https://github.com/orgs/paritytech/projects/67/views/1

Sub-tasks can be found here (https://github.com/paritytech/polkadot/issues/5492), and some thoughts on the integration of upcoming asynchronous support are summarized in this comment (https://github.com/paritytech/polkadot/issues/5492#issuecomment-1362941241).

In short, the existing core abstractions will no longer be 0-dimensional but will be 1-dimensional. This may mean that the way this system or pattern works will become more flexible or complex, allowing these “cores” or other parts of the system to know or predict in advance the tasks or events that will occur in the future. This may be an optimization or improvement that allows the entire system to better anticipate and handle future activities.

In Polkadot, “core” refers to a special node that is responsible for processing and validating transactions and other activities on parallel chains (Blockingrachains). “Core abstraction” usually refers to a design approach where some complex internal mechanisms or implementation details are hidden behind a simple interface or concept.

But now the details are sufficient. We are very excited about the new possibilities that on-demand parallel chains will bring and can’t wait to see them go live!

Reference link: https://forum.polkadot.network/t/on-demand-Blockingrachains/2208/3

We will continue to update Blocking; if you have any questions or suggestions, please contact us!