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!

8 Likes
2

But you can outbid someone on a core?

1 Like
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.

1 Like
8

How would interchain communication work under this paradigm? Would the messages from other chains have to be queued until a parachain finalizes its state/sends a response?

9

Yes, exactly. The messages to a chain can’t be processed until that chain commits a block.

10

Thanks for the response. What would the process look like for exchanging messages under this model? How often would a chain have to commit a block depending upon its use case? How would you price this security relative to that received by holding a full parachain slot?

11

The process for exchanging messages would be the same as current: chains opening channels between each other by sending messages up to the relay chain and then populating/draining the channels.

I’d expect that most use-cases would commit blocks only when there are large amounts of outstanding messages or transactions that need to be committed. That depends on the amount of usage services are getting, but it could be as infrequent as one block every day.

The level of security that each block gets is the same vs. a full parachain block, i.e. the change is in quantity, not quality. It’ll be priced by the market via supply and demand, so there’s no price we can point to but worth considering are:

  • amortized price-per-block of bulk (slots)
  • constant overheads in on-demand scheduling being higher
  • expected differences in demand for bulk vs on-demand
12

I’m a bit puzzled by this. Shouldn’t the interaction between different payg chains be almost instant, e.g. during a cross-chain transfer / swap? Sure there might be use cases where you can wait a day, but I wouldn’t expect that to be the norm.

13

I think the missing piece here is related to the not yet defined logic on how / when blocks will be produced by an On-Demand Parachain.

This was in a presentation from a while back, with the old parathread model in mind, but I think it still applies:

image
image2868Ă—1561 383 KB

I would hope that the runtime for On-Demand Parachains may allow for anyone to be a block producer if they are willing to pay for the fees to submit a block. Polkadot itself can check that the block is valid.

In this case, the Parachain logic should include some reward, which will offset the costs of submitting the block. This could be as simple as collecting all the block fees. This means that an XCM between two On-Demand Parachains, with the right amount of fees / rewards, would happen “instantly” because someone out there would be incentivized to publish both blocks and collect all the fees in the middle.

The diagram above has another model where the On-Demand Parachain itself generates a block reward, which increases exponentially as the time between the last block published to Polkadot increases. This would ensure that even blocks with relatively small number of transactions and fees get published.

The On-Demand Parachain model could be a lot like going back to some kind of proof-of-work system, without the wasted hashing computation.

Hope this is accurate, but happy to be corrected :slight_smile:

4 Likes
14

:wave: Hello I am student at the PBA and I have some questions. I find this new on demand blockspace stuff super exciting!

  • I thought that collators where parachain specific. Will general purpose collators be created to handle blocks different on on-demand parachains?

  • It’s so awesome that this will greatly lower the barrier to entry for blockspace. If the number of on demand parachains increases rapidly could there be a scalability issue as the relay runtime is calculating the current optimal price?

15

I think you are mixing here up stuff. Generally you can still have collators that are just assigned to one on-demand parachain. However, there can also be collators that handle multiple on-demand parachains. The relay chain doesn’t care how this is done. All of this are “implementation details” of the parachains.

The total number of cores is fixed. This means, yes there would be a scalability issue as on-demand parachains would need longer to get a slot. However, the network will not be affected.

2 Likes
16

Yep. If there are fees that cover the costs I would expect collators to order a core and produce blocks. So how fast things go depends on how many users and on what they want to pay essentially.

17

The on-demand code has just been merged to master. With the next Polkadot release it will be possible to order on-demand cores on Rococo and have a parachain author blocks on those.

Many thanks to @antonva who did most of the work to make this happen!

More details will follow soon! Work continues on more security hardening and cumulus integration, for automatic placing of core orders.

4 Likes