Hi all, please see below a write up from one of the Polkadot Summit sessions that was held in Bangkok in 2024.
You can use the polkadot-summit tag to see all the other posts, and navigate to the summary post for a recap of the event.
Session: An Introduction to Coretime
Host: Donal Murray - System Parachains @ Parity
Twitter: https://twitter.com/domuiri
Element: @donal:parity.io
Short summary of session:
The session was a deep dive into the specification and status of Agile Coretime, Donal covered off a detailed view of the broker architecture, how the coretime chain will work with the relay chain and there was discussion around the pricing and economics of what coretime could cost at launch.
For the Kusama launch developers will purchase coretime directly on the relay chain - this matches the current Rococo implementation but will differ for the launch on Polkadot.
Here is a talk that Donal gave re: Agile Coretime at Sub0 the next day, while being different to his talk at the summit, it covers similar concepts.
Main discussion points:
Agile Coretime lowers the barrier to entry for developers and teams wanting to build in Polkadot. Given blockspace is currently underutilized in Polkadot, Agile Coretime is the first step towards teams being able to share cores and encourage maximal utilisation of these cores on Polkadot.
Agile Coretime also is being introduced to help add predictability in pricing for building on Polkadot, along with better market driven pricing than the current auction model.
If you would like to dive deeper into Coretime, this is covered between RFC1, 5 & 10.
RFC1: sudo code & some rust
RFC5: the interaction between the Coretime chain and the Relay chain
RFC10: to define financial side of Agile Coretime
- Minimises the barriers to entry
- Allows projects to budget long term with better price predictability
- Introduces scaling with a continuously changing numbers of cores (up to 1k)
- Facilitates the optimal allocation of work to cores
- Low latency scheduling on a varing number of individual cores
- Coretime credits
- Burn bulk coretime revenue
- Avoid disrupting the steady and predictable treasury income
- Helps balance inflation
- Makes coretime a clear cost to holders
For the Kusama launch:
- Finalising code in runtimes#212
- Pricing models proposed
- Auctions will be cancelled
- Leases yet to start will be refunded
- Runtime upgrade times to land on lease period boundary
- First sale includes cores to replace cancelled auctions
Q&A
Q. Can we have time to test offboarding / onboarding for Coretime?
- Yes, testing has commenced already on Rococo and Kusama will match this implementation
Q. How will dynamic pricing work, especially when there is a spike in demand?
How do you combine all usecases (high value tx vs low value tx) in one system?
- This is less to do with the system forcing a price cap but rather combining on-demand cores with your bulk cores in the future. Currently cores are not saturated, so for launch we don’t perceive any issues in this regard.
Q. With coretime being a model to replace parachain auctions, but not crowdloans. With coretime, there is no way for the community to be involved in the purchasing process of helping the chain get running. Could there be other mechanisms for community participation of purchasing of coretime?
- Yes these could include: Transaction costs of using the chain - these TX costs can help the protocol pay for the coretime. Mechanisms on secondary markets for the community to participate. Or even using the crowdlown method (with modifications) to allow users to contribute DOT to the project to help cover coretime costs in exchange for tokens.
Q. Is there a transition period between long leases and coretime?
- With the runtime upgrade, all parachains w/ leases will be given coretime credits up until the end of their lease.