# Next-Generation Scheduling

Next-generation Scheduling aims to enable parathreads and to unify parachains and parathreads by allowing chains to acquire 'burst' capacity in the form of additional temporary Cores. Conceptually, a parathread will be a parachain with zero 'reserved' Cores which acquires temporary Cores on-demand. Parachains can have one or more reserved cores and can also acquire additional Cores on-demand. This enables much more efficient blockspace and security markets for Polkadot and a simpler path to onboard into the ecosystem.

Motivation: The amount of time that validation of a parablock can take is determined by the amount of time we are willing for finality of the relay-chain to take. Due to the architecture of Polkadot, it is possible for sequential blocks to be validated in parallel. Furthermore, the amount of Cores managed by the system should always be scaled to the maximum amount of backing, availability, messaging, and approval work the network can support. The network may choose to allocate fixed amounts of cores to long-term slots via parachain auctions and leave behind the rest as 'burst' capacity. In the case that those cores allocated to long-term slots are not allocated via slot auctions, they should also be utilizable as 'burst' capacity. The aim is to make these resources, via the abstraction of Cores, accessible to all parachains through architectural changes that allow one or multiple Cores to be claimed by any parachain via slot auction (long-term) or 'burst' auction (short-term).

Requirements:
* Allow paras to occupy multiple availability cores at the same time, and allow dependencies between blocks to be expressed between cores. When a block times out due to lack of availability, its dependents should be erased from the cores they occupy.
* In the case that a dependent core occupant is vacated due to its dependency, the temporary core claim should be refunded. (This may introduce a DoS vector, bears further refinement)
* Temporary core claims should be possible to acquire either by user accounts or by parachain's account itself. This is a soft requirement, in the sense that it would also be acceptable for claims to only be acquirable by user accounts as long as they had a reasonable way of reliably being reimbursed by a parachain or smart contract.
* Parachains should be able to acquire temporary core claims in a way that fits with their collator selection strategy, like Aura or SASSAFRAS
* Core claims should have a flexible expiry date.
* Core claims should not necessarily be pinned to a specific collator.
* It must be predictable, based on the runtime state, which validators are acting as backers for which paras at any moment.
* The system should be able to support a large number of outstanding core claims
* Core claims should be spent lazily; that is, it shouldn't be possible to consume a core claim when there is reserved space available.
* The meaning of a validator being 'assigned' to a parachain for the purposes of backing may need to be re-defined with the intention of allowing multiple validator groups to be assigned to the same parachain at once, for subsequent blocks.
* (stretch goal) allow bidding on tranches of temporary cores to allow parachains to efficiently buy additional capacity for predictable time periods such as 1 minute, 1 hour, 1 day.
* (stretch goal) make temporary core claims transferable, enabling secondary markets for burst capacity.

### Parathreads

We suggest parathread collators expand/wrap their candidate recipet by a fixed fee payment. We'll charge more fee the further through the inclusion pipeline the parablock goes.

We expect tips exist and get unevenly split between backers and relaychain block producers. We'll adjust the fee up or down depending upon the fullness of the parablock availability cores.

As like parachains, we rotate existing parathreads among the parathread backing groups every minute or so, acording to `H(epoch_something ++ relay_parent ++ parachain_id) mod num_backing_groups`.

A priori, we envision collators connecting to backing validators, but they'd quickly justify their connection, likely by providing this payment wrapper first, perhaps also proving they recently held parablock authorship slot, via aura, sassafras, etc.

We've no core claims logic or refunds in this design, merely payments based upon candidate progresses.

We'll likely align backing groups with availability cores initially, but if needs arise then leeway exists for alternative schemes, like perhaps relay chain block producers could assign backed parablock candidate to availability cores.

### Short-term leases

We think the boost design makes sense. It needs constraints so that order is preserved at steps like backing and inclusion, but async backing already contains some related constraints.

We prefer short-term leases be auctioned, so that prices can rise when need rises. Any fixed price model risks poor allocation here.

We'll auction all k short-term leases simultaniously, with leases running maybe an hour or 10 minutes. We expect a kth or (k+1)th price action makes good sense here (Samuel?)

We've no need for reserve prices if the parachains already have a long-term parachain slot. We'd want some reserve price if parathreads could bid for short-term leases, but this remains unlikely so far.

We'd maybe add reserves for long-term parachain slots since those cores arguably compete with parathreads and short-term leases.

We've discussed if price information from short-term lease auctions winds up useful in pricing parathreads. It depends upon how resoruce usage clash, but likely irrelevant initially.