On-demand is supported on Polkadot; however, one key element is still missing. It would be beneficial to have easily customizable and well-documented on-demand integration modules. This is especially important because such integration is far from trivial, and mistakes are can be made if each team creates its own implementation.
I plan to work on this because I believe on-demand can be a valuable feature for projects deploying on Polkadot, especially those coming from other ecosystems where this model is more familiar than the bulk coretime model we also offer.
The implementation plan is greatly inspired by this GitHub ticket: https://github.com/paritytech/polkadot-sdk/issues/1487.
To keep this post succinct and non-redundant, I will outline some of the main points and suggest a few adjustments.
The coordination aspect of the solution is essentially the same as described in the GitHub ticket. The slot width (w) would be configurable through the parachain's on-chain governance. However, as noted in the issue, the main limitation of this solution is that the block rate is restricted to a single block per w.
This is something that could be improved in the future, but for an initial version, it should be sufficient.
As mentioned in the ticket, placing an on-demand order incurs cost. Anyone can place an order, however, only the block producer has the incentive to do so.
The code should be written so that the parachain can stop on-demand and switch to bulk Coretime if its governance system decides to do so. When this occurs, order placement would stop, and the collators would wait for bulk Coretime to be assigned before continuing block production.
Of course, we can't stop anyone from placing an order, but there would be an on-chain storage value, controllable by an origin, indicating that a decision has been made to switch to bulk Coretime.
Certain conditions would determine when a block should be produced, and this should be verifiable by the parachain runtime. These conditions should be defined by each parachain.
Since we aim to transition to using credits for on-demand orders, the code will be designed to utilize the credit system. A module would be created, which would be enabled whenver the node is running as a collator.
Such a module would check on-chain state to determine whether the node is in the active collator set. If so, it will periodically purchase credits to ensure it always has enough to make an on-demand order. The logic for when and how many credits to purchase should be customizable; however, a common implementation will be provided to fit most use cases.
Instead of directly controlling an account that holds funds, we will use the OnDemandPurchaser proxy type to purchase credits.
This proposal does not include the cost of an audit. Upon successful completion, a new proposal will be submitted to cover the cost of auditing the code.
This proposal would cover:
The tasks described here would take approximately 1.5 to 2 months to complete after the proposal is approved.
Based on all of this, the amount requested by the proposal would be 18,000 USDT.
w) configurable via on-chain governance; initial version limited to one block per w.
Szego has proven multiple times already that he can deliver (numerous contributions to polkadot-sdk + all of region-x). Providing out of the box, ready to use on-demand integration, including an example chain + documentation at that price tag is a steal! Honestly, I would consider asking for more funding, for ensuring to being able to deliver quality work, without paying out of your own pocket. Quick PoC is a fraction of the work of a polished product.