Work on on-demand parachains (also known as Parathreads) has begun! Some of you are already waiting for this, but for everyone else: What is that and why are we doing this?
On-demand parachains are the first variant of a more dynamic block space acquisition method. Parachains, how they exist now, offer a very static way of acquiring block space: You win an auction and have block space secured over a long period of time, e.g. a year. Currently you would be allowed (and expected) to author a block every 12 seconds for that entire duration.
This guaranteed ability to author blocks at regular intervals is indeed a requirement for some applications/chains and is one of the features making Parachains superior compared to smart contracts.
But on the flip side there are also applications for which this is overkill, making them a Parachain would result in lots of wasted resources from the perspective of the network. From a user perspective, winning an auction is quite some barrier to entry, making it harder for new projects and ideas to join the network. With on-demand Parachains we both lower that barrier and open up the network to less demanding applications in a network efficient way.
So how does this work? An on-demand Parachain is not scheduled for block authorship every twelve seconds, but instead a collator orders a core (a block authorship opportunity) when there is a need. For this, collators will send an extrinsic saying that they want a core for their
ParaId containing a maximum price they are willing to pay.
Ordering a Core
The relay chain runtime will calculate a current optimal price for cores, if an incoming order’s maximum price is equal or higher and the account sufficiently funded, that current optimal price will be charged and the collator will soon be scheduled for block authorship.
The price is calculated by the relay chain in a way reflecting current demand. It is based on the same mechanism that is used for fees, reacting slowly to demand in order to avoid spikes in price.
The extrinsic being used will be a signed extrinsic to piggy back on all the security mechanism that already exist for signed extrinsics. From a user perspective, this means the total price to be paid is the traditional fee (covering the weight) for an extrinsic, an optional tip for the block author and the price for the actual core on top.
Integration with Collators
The actual block authorship for collators will be exactly the same as for static Parachains. Collators check the core status and if they see their
ParaId coming up, they will author a block and transmit the PoV to their assigned backing group.
While the actual block authorship stays unchanged, we will need to integrate order mechanisms into collators, enabling collators to send out core orders when there is need for it. Different possible strategies come to mind. In fact, if you are interested and maybe even know Cumulus a bit, looking into this issue would be a great way to join the project and help on-demand Parachains come to life faster!
The other important part is having a fully enabled hot account key on collators is not a great idea. We therefore will be providing a dedicated proxy account type which is restricted to bidding on on-demand Parachain cores.
Integration with Async Backing and more Details
For the more technical interested audience, the full development of on-demand
Parachains is tracked here.
The tracking meta ticket can be found here and in particular some thoughts on integration with the upcoming asynchronous backing are summarized in this comment.
In a nutshell, the existing core abstraction will be upgraded to no longer be of
dimension 0, but will now be of dimension 1. Allowing a look-ahead of upcoming
But that’s enough details for now. We are very exited on the new possibilities on-demand Parachains will bring and can’t wait to see them go live!