Recently discovered that polkadot has had slot auctions native to the chain and a new set of proposals and RFCs for a newer, sleeker construction. Some notes:
The present system of allocating the limited resources of the Polkadot Ubiquitous Computer is through a process known as parachain slot auctions. This is a parachain-centric paradigm whereby a single core is long-term allocated to a single parachain which itself implies a Substrate/Cumulus-based chain secured and connected via the Relay-chain. Slot auctions are on-chain candle auctions which proceed for several days and result in the core being assigned to the parachain for six months at a time up to 24 months in advance. Practically speaking, we only see two year periods being bid upon and leased. -
Source
Polkadot’s new approach is more akin to a CPU scheduler. RFC-1 titled “Agile Coretime” introduces a new method for allocating Polkadot Coretime, which is analogous to “block space” in the Polkadot Network. This method is based on periodic sales and is designed to cater to the long-term capital planning needs of teams building on Polkadot. It aims to capture long-term value for Polkadot while also supporting the development of secondary markets for resource optimization. The current system, which uses “parachain slot auctions”, is criticized for its rigidity and inability to efficiently utilize the Polkadot Ubiquitous Computer.
This new proposal offers a more dynamic approach, selling Coretime in two formats: Bulk Coretime and Instantaneous Coretime. The Coretime is dedicated to a “Task” rather than a “parachain”, allowing for more flexibility. The proposal also introduces the Coretime-chain, a specialized system chain for managing Coretime sales and allocations. The Coretime system introduces two sale formats: Bulk Coretime and Instantaneous Coretime, with Coretime dedicated to a “Task” instead of a fixed “parachain”. This allows for greater adaptability in resource allocation. Central to this design is the Coretime-chain, a specialized system chain responsible for overseeing Coretime sales and allocations. This chain manages various functionalities, from transferring and partitioning Coretime to setting prices and facilitating renewals. The proposal also delves into the intricacies of price setting, renewal mechanisms, and the economic implications of the new system.
- Parameter Values: The proposal defines several parameters, some of which are specified and others suggested. For instance, BULK_PERIOD is set to 28 * DAYS, and TIMESLICE is defined as 8 * MINUTES. These parameters are crucial for the functioning and timing of the system.
- Instantaneous Price Progression: The proposal outlines a dynamic price-setting mechanism for the Instantaneous Coretime Market. The price changes based on factors like the last price, the size of the Instantaneous Coretime Pool, and the amount of Instantaneous Coretime waiting for processing. An example formula for the NEW_PRICE is provided, which adjusts the price based on the queue size relative to the pool size.
- Regions: Coretime can be traded, partitioned, and managed. Coretime Regions can be exposed as NFTs, exchanged, and contributed to the Instantaneous Coretime Pool. The provided Rust code snippets showcase the data structures and their potential interactions.
Sources: