On-demand Tutorial

[eskimor]

We have this forum post: https://forum.polkadot.network/t/parachain-consensus-updates-coretime-asynchronous-backing-scalability/4396/8?u=eskimor

but first of all, people seem to be having problems: https://substrate.stackexchange.com/questions/11031/parathread-not-producing-block-on-rococo-registered-using-coretime/11279#11279 , second this should be in a better place.

So this issue is about:

1. Extending the existing tutorial to cover more details and potential pitfalls (improve success rate).
2. Update, e.g. a section on what to change for Kusama/differences there.
3. Find a better more permanent place.

Related work (might already close this ticket): w3f/polkadot-wiki#5733
Should be integrated in some form here

[DrW3RK]

I was able to follow the tutorial successfully and have documented the steps in detail here w3f/polkadot-wiki#5733 After the PR is reviewed, we can link to this Wiki doc for this tutorial instead of the forum post.

After coretime is live on Kusama, we can update this page with snapshots on Kusama network. Although, we might need some assistance with the "what to change for Kusama/differences" part.

[shawntabrizi]

I want to propagate a scenario which is not currently covered by on-demand coretime afaik.

Imagine you want to create a highly permissionless chain where anyone is allowed to produce a block. (Think something adjacent to proof-of-work block author selection or polkadot-dropit/node#2)

Right now there seems to be no association between the person who fronts the money to purchase an on-demand slot, and the person who is allowed to build the block.

It seems in this case, there is reliance on the consensus system of the parachain to make this association. For example with Aura, you are assigned a slot, and then you will need to purchase the on-demand slot and submit the block.

However, for a fully open system, we want that someone can go buy a slot, and then they are the one who is prioritized to be the accepted block producer. For this, we need an API to get who the person who purchased the slot is, or better yet, who the block purchaser expects the block author to be.

You might imagine something like:

buy_on_demand(prioritized_block_producers: Option<Vec<AccountId>>)

Let me know if this scenario makes sense.

[kianenigma]

I think the above scenario is valid and should be supported by the relay chain, but based on my understanding it is not possible now.

I would look at it differently: When buying the core, one should be able to specify:

1. Only I can produce the block associated with this purchase
2. Anyone can produce the block associated with this purchase