ambassador

senior_ambassador

head_ambassador

Thank you for the proposal!

I looked over it and found the following things:

- Ancestry proof is accounted for with 30h and elastic scaling only with 20h. I doubt that you will be able to handle elastic scaling faster. Not sure how familiar you are with the code, but I would assume it takes at least 2 weeks (which is still extremely optimistic)
- " it is highly useful to have it integrated with Omni-Node in some form." "in some form" sounds very unspecific. It should work. There is no middle ground.
- For the manual reward claiming, if you are running in `on-demand` mode, you could panic if someone did not provide the proof of buying a core.

General, what is the future of this project? Will you continue maintaining it, do you want to upstream it to the SDK repo?

For this proposal I would recommend that you don't tackle elastic scaling or maybe just in some very basic POC form. Show that it is possible and then you get some better idea on how long it will take. The output of this milestone should be some proper guide on how to use it. I know that you have [some](https://docs.regionx.tech/on-demand#pallet-on-demand-overview) tutorial on how to integrate it, but not how it can be used. It would also be nice if there is some zombienet prepared network in the repo that someone can launch and see this in action. 

[@bkchr](13fvj4bNfrTo8oW6U8525soRp6vhjAFLum6XBdtqq9yP22E7-collectives) 
Thanks for leaving comments!

> Ancestry proof is accounted for with 30h and elastic scaling only with 20h. I doubt that you will be able to handle elastic scaling faster. Not sure how familiar you are with the code, but I would assume it takes at least 2 weeks (which is still extremely optimistic)

I was actually on a call with Robert K. and Andrei, and at that moment, we didn’t see any major obstacles with this. The plan is to create a PoC, see how it works, and identify any potential issues that arise.

> " it is highly useful to have it integrated with Omni-Node in some form." "in some form" sounds very unspecific. It should work. There is no middle ground.

The first step here is to fork the Omni node and add the order placement service to it. The next step, which I briefly discussed with Kian, would be for the Omni node lib to support customizable consensus. Essentially, to make the on-demand logic work, collators need to run the order placement service. If consensus is modifiable, the simplest way to support on-demand would be to create OnDemandAura, which would essentially run the regular Aura service alongside the order placement service.

> For the manual reward claiming, if you are running in on-demand mode, you could panic if someone did not provide the proof of buying a core.

Manual reward claiming is needed because the order placer and block author will likely not be the same. This means the block author could simply omit the order placement proof, leaving the order placer without a reward.

With the current code, only the expected order placer can receive a reward for placing an order. If someone else creates an order and that proof is provided, the reward logic doesn’t execute. We could panic if an unexpected order placer submits an order, which would somewhat address the issue, but restricting order placement from others is not ideal.

> General, what is the future of this project? Will you continue maintaining it, do you want to upstream it to the SDK repo?

Upstreaming it to the SDK repo would be a good idea once it is in a production-ready state. However, in that case, it would be unclear who would be responsible for maintaining it. This would make Parity responsible for its maintenance as well, which I’m not sure would be desirable from Parity's side.

I plan to maintain this as a separate project, but if there is interest in moving it to the SDK repo, I would be open to it.

> I was actually on a call with Robert K. and Andrei, and at that moment, we didn’t see any major obstacles with this. The plan is to create a PoC, see how it works, and identify any potential issues that arise.

Your proposal doesn't mention that this is only a Poc. :) I mean I also don't see any big blockers, but the integration will take some time.

>The first step here is to fork the Omni node and add the order placement service to it. The next step, which I briefly discussed with Kian, would be for the Omni node lib to support customizable consensus. Essentially, to make the on-demand logic work, collators need to run the order placement service. If consensus is modifiable, the simplest way to support on-demand would be to create OnDemandAura, which would essentially run the regular Aura service alongside the order placement service.

None of that is really extending the omni node. It is about building a new node. Maybe already goes a little bit into the direction of upstreaming. Or we move the omni node out of the sdk repo.

> With the current code, only the expected order placer can receive a reward for placing an order. If someone else creates an order and that proof is provided, the reward logic doesn’t execute. We could panic if an unexpected order placer submits an order, which would somewhat address the issue, but restricting order placement from others is not ideal. 

For normal on demand they guy buying the core, should be the one building the block. For a given slot only one guy should be able to buy a core. Basically aura should be used to decide who is buying. We should the proof to the runtime that it was our turn to buy a core. Maybe requires changes to the buy coretime function to pass alongside some hash of a relay chain block that was used as context to buy. 


[@bkchr](13fvj4bNfrTo8oW6U8525soRp6vhjAFLum6XBdtqq9yP22E7-collectives) 

> Your proposal doesn't mention that this is only a Poc. :) I mean I also don't see any big blockers, but the integration will take some time.

I updated the proposal.

> None of that is really extending the omni node. It is about building a new node. Maybe already goes a little bit into the direction of upstreaming. Or we move the omni node out of the sdk repo.

I am referring to the omni-node lib here. I will talk with Sebastian from the omni-node team, but with a customizable consensus, integrating the order placement service will be straightforward.

> For normal on demand they guy buying the core, should be the one building the block. For a given slot only one guy should be able to buy a core. Basically aura should be used to decide who is buying. We should the proof to the runtime that it was our turn to buy a core. Maybe requires changes to the buy coretime function to pass alongside some hash of a relay chain block that was used as context to buy.

Order placement should not be tied to Aura. It could be, but it would require slowing down the block production rate so that the order placement also ends up being the block author. This solution was initially proposed here: https://github.com/paritytech/cumulus/issues/2154. However, this post (https://github.com/paritytech/polkadot-sdk/issues/1487) proposed a better solution, which my work is based on.

[@Szego](126X27SbhrV19mBFawys3ovkyBS87SGfYwtwa8J2FjHrtbmA-collectives) 
> Order placement should not be tied to Aura. It could be, but it would require slowing down the block production rate so that the order placement also ends up being the block author.

I don't get the argument? How is the block production slowed down by this? If you order a core every slot and then build on it, you get continuous block production. While actually "continous block production" is not the goal of on-demand, as you want to build "on demand" when you need to. So, the general argument of "slowing down the block production" is a little bit weird :) 

[@bkchr](13fvj4bNfrTo8oW6U8525soRp6vhjAFLum6XBdtqq9yP22E7-collectives) 

In general, the slot width for parachains is 12 seconds. For on-demand to work with the approach you mentioned, a collator would need to place an order and build a parachain block within these 12 seconds. However, this wouldn't be possible, as it takes some time for the order to be placed in an RC block and for the parachain to get a core assigned. This means we have to increase the slot width to allow enough time for a core to be assigned and a parachain block to be submitted.

On-demand chains would only produce blocks when certain requirements are met. For example, if there are x number of transactions. It is very possible for chains to experience spikes in activity during certain periods, and in such cases, when there is a lot of activity, continuous block production is important.

[@Szego](126X27SbhrV19mBFawys3ovkyBS87SGfYwtwa8J2FjHrtbmA-collectives) 

> In general, the slot width for parachains is 12 seconds.

Right now and not in general :) 

My point is that if you order a core at time point X, you will build the block when the core is ready. The next collator at time point Y, would do the same. You can continue this and you will see that you would end up with a stable block production. Block production would basically be an async step that follows after block ordering.  :) 

[@bkchr](13fvj4bNfrTo8oW6U8525soRp6vhjAFLum6XBdtqq9yP22E7-collectives) I see your point, but is ideal to have order placement done independently of consensus, as mentioned in https://github.com/paritytech/polkadot-sdk/issues/1487.

For example, what if a chain starts off as on-demand and wants to transition to bulk coretime? At the start, with your solution, the parachain would have increased slot width to make the order placer the same as the block producer. However, once transitioned to bulk, they would want 'regular' 6 or 12 second slot width. 

It’s best to keep the order placement service unattached to consensus. Once parachain transitions to bulk, the service can be turned off, and the parachain would simply rely on bulk, having a 'regular' block production rate.

[@Szego](126X27SbhrV19mBFawys3ovkyBS87SGfYwtwa8J2FjHrtbmA-collectives) 

> For example, what if a chain starts off as on-demand and wants to transition to bulk coretime? At the start, with your solution, the parachain would have increased slot width to make the order placer the same as the block producer. However, once transitioned to bulk, they would want 'regular' 6 or 12 second slot width. 

What I propose does not require to change the slot width. The only difference to "normal bulk coretime aura" is that the slots determine who has the right to order a core at the given slot. Whenever this core is ready to be used (can be the same slot or 10 slots later), the guy that bought the core will produce a block for the core. Block production is fully decoupled from slots.

Proposal: https://docs.google.com/document/d/119IGKlovqbvHi0os8G86oKc6i4Q7i5SDxjFYClQsGE0/edit?usp=sharing

Just like for the first milestone, there will be a remark proposal confirming that the payment will be made upon completion of the work.









On-Demand Integration Modules: Proposal 2