On-demand parachains

Tech Talk
1

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
assignments.

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!

4 Likes
2

But you can outbid someone on a core?

3

The fee paid is the same regardless of whether the maximum price willing to be paid was higher. When demand is high, the spot price moves slowly upwards in an automatically adjusting manner.

There are maybe some vectors for MEV here, like validators deferring higher-max orders in favor of lower ones in order to charge/burn more, but mortal extrinsics limit the possibility here.

4

Also block producers don’t get a cut on the order price, so there is no MEV risk at all. If we ever wanted the block producer to have a cut on the order price for any reason, it would be fixed and independent of current spot price.

5

Ahh I thought all the time that we just have some kind of bidding for the slots and the highest bid wins. So here it means the first order that makes it into the block will get a core for sure?

6

Pretty much. If your order is valid it will be enqueued, then the will be served in order. So pretty much first come first serve. Given that we do build on signed extrinsic you can prioritize via tipping though.

The queue will be economically bounded: If the queue grows too large, cores will become expensive.

7

This is rarely accurate :slight_smile: but there don’t seem to be any absolutely trivial MEV approaches here.