In October, I wrote a post (Blockspace Products and Mechanisms in Polkadot) proposing a few different mechanisms looking forward.
UPDATE: This is now an RFC at Blockspace Regions by rphmeier · Pull Request #3 · polkadot-fellows/RFCs · GitHub
Summing up a few key desiderata:
- Bulk blockspace markets (parachain slot auctions)
- Mid-term (1hr - 7wk) purchases
- On-demand purchases (design writeup here: On-demand parachains)
- Secondary blockspace markets (re-selling of blockspace, blockspace futures markets, etc.)
- Sharing bulk blockspace purchases across several chains
- Elastic scaling for parachains by purchasing parallel blockspace with some combination of the above (Parachain Scaling by Parablock splitting)
In particular, I see mid-term blockspace markets as a key mechanism for practical elastic scaling. Periods of peak demand are often short, so it’s the right mechanism for adapting to predictable-yet-short-lived load.
It’s not clear to me that bulk and mid-term blockspace actually require different mechanisms. Blockspace can enter the system in a bulk format, and markets living elsewhere can handle most of the work of assigning the bulk blockspace onto different chains.
Consider this post an early-stage proposal for new mechanisms to unite both bulk and mid-term blockspace while looking forward to elastic scaling and secondary blockspace markets.
Let’s imagine a mechanism that works like this:
The Relay Chain auctions off a bulk piece of blockspace, i.e. a dedicated execution core for 6 months. This creates a contiguous blockspace region
Every region is a
[start, end, stride, offset]data structure. For a region with full access to a core, the stride is 0. For a region that has intermittent access to a core, the stride is nonzero.
The owner of a region can split it into pieces down to some minimum granularity in size and maximum stride. Every split comes with a corresponding deposit for the on-chain bookkeeping overhead.
Regions can be split in two ways: contiguously or strided. A contiguous split only affects the
end, while a strided split alters the
Regions can be transferred by the owner.
Regions have a single
ParaIdassigned to them, which can be changed by the owner.
Regions can be recombined when they correspond to the same core and together form a well-formed region
The Relay Chain’s scheduler looks at the next upcoming regions for each core to determine the upcoming
ClaimQueuethat collators and validators watch.
A parachain looking to re-sell blockspace can simply split off a region and sell it (in its own runtime, or on a dedicated parachain for this purpose). This sale can be made atomic, and can be performed using XCM, and would allow parachains to monetize unneeded blockspace.
Strided regions would allow multiple chains to share a bulk slot in even or uneven proportions.
This depends on other mechanisms for supporting chains to occupy multiple cores at the same time, but once that is completed, a parachain looking to scale in the near future would be able to purchase regions corresponding to one or multiple cores
One clear issue with this approach is that regions can become heavily fragmented and even though they can be combined, this could carry high overheads.
What makes most sense is to defer the splitting of regions to the latest point possible (i.e. delivery) by having a dedicated market on a parachain to trade potential regions which then finally resolve shortly before they are relevant, by issuing the appropriate parachain assignment and region splitting calls on the relay chain via XCM.
This is a notable project for R&D that should only rely on the right interfaces being set at the relay chain level.
The main issue with scheduling on execution cores is that cores are occupied from the time a parablock is backed to the time that parablock’s data is available. Availability is dependent on the entire validator set, which means that blocks can occupy an availability core for a fairly long time, although the size of the data is bounded.
If we interpret strides as “turns” on an execution core, then we may need mechanisms for either truncating or extending regions as some turns may take longer than expected due to availability delays. Truncating regions has the effect that regions may not actually be as long as initially expected in the face of availability delays, whereas extending regions means that the point in time when the region is concluded is not as predictable. This is worth discussing further.