Polkadot Coretime
---
- Overview of coretime
- How to use coretime
Author: @ltfschoen
Team: BlockspaceDevRels
Disclaimer and Copyright Notice
---
This Disclaimer and Copyright Notice at this link, governs your access to and use of these presentation slides including any content, functionality and services offered on or through these presentation slides.
Please read the Disclaimer and Copyright Notice carefully before you read this presentation. By using this presentation or by continuing to listen to it without immediately objecting to the presenter when that option is made available to you, you accept and agree to be bound and abide by the Disclaimer and Copyright Notice. If you do not want to agree to the Disclaimer and Copyright Notice, you must not access or use this presentation.
Needs?
---
- On-chain gamified app using smart contracts
- Real-time multiplayer collaboration
- Complex logic
- Rapid prototyping
- Instantly scale to multiple cores
- Fast block time
- Low latency
- High frame rate
- Afford solutions as prototype scales
- Avoid being priced out of the market
Note:
- Example
- Metaverse
- AR/VR multiplayer gaming application
- Support concurrency by using Conflict-Free Replicated Data Types (CRDTs)
- Execute complex on-chain logic on-demand to test my prototype
Problems?
---
- Costly smart contract gas fees
Solutions?
---
Build on-demand parachain
- Generate template parachain using Pop! CLI
- Customize parachain using Polkadot SDK
- Write complex runtime or state transition function (STF) logic
- Remove gas metering from runtime config
- Use Substrate's weight system and performing benchmarks to mitigate infinite loops
- Test parachain on testnet (e.g. Rococo or Paseo)
- Deploy parachain to mainnet (e.g. Kusama Coretime)
Trade blockspace
---
- Find blockspace brokers
- Write algorithms to trade with blockspace brokers
- On-demand access to affordable blockspace
- Reserve bulk coretime blockspace in anticipating for scaling in future
- Trade blockspace to reduce costs
- Avoid being priced out of the market before finishing prototype.
- Choice of relay chain (e.g. Kusama Coretime)
Manipulate blockspace
---
- Write algorithms to manipulate blockspace using Coretime's Broker pallet from the Polkadot SDK (e.g. interlacing)
- Same tools and capabilities as a full parachain for on-demand parachains without cost drawback of purchasing bulk coretime
Polkadot?
----
Features
- Ecosystem with layer-0 relay chain blockchain protocol having multiple layer-1 parachains connections
Image Not Showing
Possible Reasons
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →
Source: Polkadot Wiki > Learn Parachains
XCM and Accords
----
"Polkadot is the only ecosystem where Accords can properly exist because it has a homogenous security layer that provides a specific STF for each logic component, allowing patterns of cooperation between multiple logic components (i.e. trans-applications) that would not be possible to achieve over bridges.", and are "implemented using SPREE technology"
XCM and Accords (Continued)
----
- Secure mode of transporting cross-chain XCM messages between different chains using XCMP transport layer format, interpretable across protocols
- Allows parachain cores to opt-in to Accords (bi-lateral agreements) for fully trustless collaboration between parachain cores (appchains)
- Receivers may faithfully interpret XCM messages securely sent via XCMP channels
- Treaty logic cannot be changed, misinterpreted or undermined.
Relay Chain Validators
----
Relay Chain Validators (Continued)
----
- Horizontal Scaling
- Polkadot is a sharded WebAssembly (Wasm) "meta-protocol" and model
- Shards (parachains) handle state changes (internally and exterally)
- Operate together using runtime abstract state transition function (STF)
- Validators execute within a Wasm environment.
- PolkaVM in future
Parachain Cores / Collators
----
- Parachains wishing to make a state transition submit a block (batch of state transitions) + state proof that Polkadot validators can independently verify.
- Blocks are finalized for the parachains after being finalized by the main Relay Chain of the system.
- All parachains share state with the entire system, meaning that a chain re-organization of a single parachain would require a re-organization of all parachains and the Relay Chain.
Coretime?
----
What is a Coretime "chain"?
----
- Coretime chains are system parachains within the Polkadot network responsible for management of coretime.
- Handle allocation of bulk coretime
- Track ownership of coretime as non-fungible assets (NFTs)
What is a Coretime?
----
- Coretime is time allocated for utilizating a core, that's measured in relay chain blocks.
- Coretime is "high quality" blockspace - see Gavs comment
Image Not Showing
Possible Reasons
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →
What is a "Region" of Coretime?
----
- Region is an NFT representing a single unit of bulk coretime.
What's the difference between "on-demand" coretime and "bulk" coretime?
----
- Bulk Coretime is a fixed duration in the future (currently set to 28 days) of continuous coretime represented by an NFT
- Bulk Coretime can be split prior to resale, with drawback of doing so voiding the fixed Renewal Price
- On-demand Coretime (prev. Instantaneous Coretime / parathreads) is coretime acquired through bidding for validation of a single parachain block on a cores reserved specifically for on-demand orders.
What is a "task"?
----
- It refers to a process utilizing Polkadot's compute. This could be a parachain or any other computational process, provided that it adheres to the Polkadot protocol
Why is coretime "agile"?
----
- The following composable options for the allocation and generalization of coretime usage enable Polkadot to be an agile decentralized global computing system that "maximizes network efficiency and blockspace usage" for applications
- Split or trade, stop and resume, at expense of higher latency
- Strided by taking turns on a core to share costs or decrease the block production rate
- Combined permanent and intermittent cores to send multiple blocks to multiple cores at the same time slot to reduce latency.
- Compressed cores where same relay chain core secures multiple blocks of same application simultaneously, with reduced latency but impacting bandwidth
- Shared cores, no latency reduction
What option would we want for this game prototype?
----
- ANS: Combined permanent and temporary cores?
What are coretime benefits?
----
- Avoid storage waste, since users can specify whether need to retain that block storage for historic purposes, or to prune it from storage.
- since with "pool",
finality
may have the value of either Final
or Provisional
. If Final
, then the operation is free and the region
record is removed entirely from storage. (see RFC 0001 Agile Coretime)
Note:
- question: is it free because if it was
Provisional
then the owner of the region would have to pay transaction fees to relay chain or something?
Parachains?
----
What's the difference between an on-demand parachain and a full parachain?
----
Blockspace Brokers?
----
What Polkadot blockspace brokers exist?
----
Scaling Prototypes?
----
How to "top-up" on-demand coretime?
----
-
Buy more on-demand coretime from a blockspace broker, or;
-
Buy bulk coretime from a blockspace broker for a future range of blocks (region), by either:
- Bid on new bulk coretime from a blockspace broker
- Bid on unrenewed bulk coretime that was not renewed in time
-
Refer to combined permanent and intermittent cores below
Buying Coretime?
----
How much does it cost to buy bulk coretime at the moment?
----
Recently there were three (3) coretime regions sold on Kusama Coretime, which is a parachain of Kusama, that cost approximately 25-30 KSM each.
They still have to pay a further ~40 KSM to reserve a Para ID as mentioned here https://wiki.polkadot.network/docs/learn-guides-coretime-parachains#reserve-paraid.
Then they also need to pay to register the parachain's genesis wasm and state code that costs a further Kusama: 0.000333 KSM per byte.
Then pay for server costs to run a parachain collator for those 28 days (cloud providers may cost for example ~US$60/month), and then assign that purchased core #53 to the registered ParaID.
Let's have a look at some metadata associated with the 3rd sale.
When did the 3rd sale of Kusama Coretime #53 occur?
----

The sale of core #53 occurred on Kusama Coretime parachain of the Kusama relay chain in block number 139726.
How do we find out more about that sale?
----
Interacting with the Broker Pallet of the Kusama Coretime parachain with a state call broker.saleinfo
returned the following information:
Alternatively view the purchasers transaction history in a block explorer.
How do we calculate the date/block number corresponding to the start/end of that region?
----
5,040 timeslices (e.g. regionEnd - regionBegin
= region timeslices) in its region length spanning 28 days.
Bulk coretime region they purchased begins at regionBegin
of 290,808
, and ends at regionEnd
of 295,848
.
Kusama relay chain block number corresponding with when that region starts its utilization: 290808 * 80 = block 23,264,640.
Subtract current Kusama relay chain (blocktime 6 sec) block number (e.g. 22,979,866) from that, then:
- Discover their
regionBegin
starts in approx. (23,264,640-22,979,866) * 6 = 1,708,644 seconds = 19.5 days
from now on ~21 May 2024, and last for 28 days until approx. 18th June 2024
- On 18th June 2024 when region expires the renewal period starts.
How long do they have to renew their region of bulk coretime?
----
leadin_length
and the interlude_length
corresponds to the renewal period (50,400 timeslices), where we know each 5,400 timeslices is 28 days.
So renewal period is (50,400 / 5,400) * 28 = 10 * 28 = 280 days = ~10 months
So they're the only account with exclusive access to choose to renew that core during that ~10 month period with a price-cap applied (unless partitioned or interlaced) that would be ~24 KSM (initial purchase price).
Cost reduction strategies?
----
Price comparison
----
- Compare:
- floor price of new bulk coretime;
- unrenewed bulk coretime, and;
- on-demand coretime across multiple blockspace brokers and;
- from direct contacts
Renew coretime for fixed Renewal Price
----
- Capitalize on the fixed rate if you renew bulk coretime that you purchased (assuming the cost of buying coretime has since increased or is forecast to) rather than letting it lapse and having to bid on the open market, similar to the benefits of running a full parachain.
Find new blockspace brokers and traders
----
- Search for new blockspace brokers frequently that may offer more competitive pricing
- Network at blockspace-related events and online communities
Establish relationships
----
-
Establish relationships with blockspace brokers and with others that are interested in deals like trading blockspace
- Investigate whether OTC deals exist for buying substantial amounts of on-demand coretime or bulk coretime that may be more cost effective than placing a large bid when there is a large spread
-
Contribute to their open-source repositories, thinking about your future self and others
-
Contribute to the Polkadot Strategy
-
Join relevant Polkadot collectives
Business structuring, legal, and tax
----
-
Join relevant Polkadot collectives to find suitably qualified and experienced advisors (e.g. legal, accounting, international tax) to:
- establish implications of each action (e.g. development, licensing, trade) and;
- investigate whether to register a decentralized autonomous organisation (DAO).
-
Investigate whether tax-deducations are possible when using businesses real-estate property to replicate and navigate the AR/VR metaverse as a digital twin
Dollar-cost average (DCA) in and out
----
- Watch the price of the token that you need to purchase the core with
- Watch the price of cores and buy backups
Pool (rent out) your region (core) to try to offset inflation
----
-
Pool (rent out) your region (core) or just your backup region when you don't need them to receive benefits (possibly considered income tax, where a tax liability on receipt), and use the after-tax portion of that income to DCA into buying more regions. This assigns the region to the On-Demand Coretime Pool where it may be consumed by others who need coretime, where a beneficiary is nominated who will receive a pro rata portion of the On-Demand Coretime Sales Revenue (from its period and regularity, at the time of the Region, relative to any other providers in the Pool)
- Set aside a proportion of profits for income tax, DCA, and for purchasing On-Demand Coretime credits to increase the balance of it for a given beneficiary account on the relay chain (possibly to consume use of the task scheduling system on the relay chain)
-
Note that the design of coretime must incentivise the provision of bulk-purchased cores into the On-Demand Coretime Pool of cores available for purchase (e.g. inflation, so if you buy bulk coretime and don't add it to the pool / rent it out, then you get disincentivised)
Efficient market pursuit
----
Watch the efficiency of market pursuits and whether they have an impact on offsetting inflation
On-Demand coretime "shelf-life"
----
Watch the "shelf-life" of On-Demand Coretime and see whether changing it to a shorter shelf-life has an impact on offsetting inflation.
- Note: The design must ensure that purchased On-Demand Coretime has a short "shelf-life" of usability and cannot be held indefinitely prior to eventual use
- incentivise collators to only purchase coretime if they expect to imminently utilize it, since that helps create an efficient market-feedback mechanism whereby a higher price will actually result in material revenues for private Coretime providers who contribute to the pool of Cores available to service On-Demand Coretime purchases)
- to prevent nefarious collator purchasing Coretime when cheap but not using it (just paying for renewals, but not using it, so no tx fee payments are being made to fund the revenue of other coretime providers during that time), and instead reserving it for a rainy day, and so only utilizing it in future when coretime is expensive (so other private coretime providers have more competition then that reduces their revenue)
Trade based economic patterns due to coretime design incentivisation requirements
----
- Watch purchases of new bulk coretime, and renewals, and consider DCAing in future depending on the behaviour based on its predicted impact on future price, since:
- bulk price progression
- expect bulk coretime price to:
- increase where a higher the proportion of cores were sold out of those that were available
- decrease if a lower proportion were sold than were available
- remain same if sales and renewals were as predicted
- remain if no new cores were purchased yet more cores were sold (through renewals) than the target
Example
----
How to "build" a parachain to use with on-demand coretime?
----
How to "deploy" the parachain to use on-demand coretime?
----
- Reserving a
ParaId
, for uploading runtime and genesis state.
- Compiling runtime (written in Rust) using Polkadot SDK to a WebAssembly blob, defining your state transitions.
- Configure viable chain spec ready to be deployed as a live, working parachain.
- Generating your genesis state and wasm.
- Obtaining core, likely through a Coretime marketplace.
- Assigning that core to your
ParaId
.
- Run at least one honest, synced collator for your task
Credits and Further Reading
----
Credits
----
Further Reading
----
Note:
- Slide features details
- Run - slides by choosing Slide Mode in sthe top right sharing menu and hit "Preview" to see your slide.
- Speaker notes
- Open hidden speaker notes window (hit
s
on your keyboard).
- Slides Timer enable with
slideOptions.allottedMinutes = {? minutes}
in YAML frontmatter
- Slide options allotted speaking time
- Font
- Spotlight
slideOptions.spotlight.enabled: true
in YAML frontmatter
URL query
or slideOptions
of the YAML metadata to customize your slides.
- Move - through slides Press Space key to navigate
- Teleport link between slides internally, like this.
- Pause - Press B or .
- Slide overview - Press ESC to enter.
- Step through fragments
- Animation shrink
- Other animations: grow, shrink, fade-out, fade-up (also down, left and right!), current-visible
- Colour blue
- Transition background postfix with
-in
or -out
- Other transitions none/fade/slide/convex/concave/zoom
- Transition speed
- Other transition speeds default/fast/slow
- Backgrounds
- reveal.js themes built-in
Black (default) - White - League - Sky - Beige - Simplem, Serif - Blood - Night - Moon - Solarized
set in YAML slideOptions
- Background colour
- Image background
-
<!-- .slide: data-background="image.png"-->
-
- Tiled background
-
<!-- .slide: data-background="image.png" data-background-repeat="repeat" data-background-size="100px" -->
- Video background
-
-
<!-- .slide: data-background-video="video.mp4,video.webm" -->
-
- Pretty code with code syntax highlighting courtesy of highlight.js
- Lists unordered
- Ordered List
- One is smaller than…
- Two is smaller than…
- Tables
Item |
Value |
Quantity |
Apples |
$1 |
7 |
- Quotes
“For years there has been a theory that millions of monkeys typing at random on millions of typewriters would reproduce the entire works of Shakespeare. The Internet has proven this theory to be untrue.”
- Charts - https://hackmd.io/@note-about-cv-bot/BkEn0pr0n#/6