# Introduction to Coretime
- Monday 11th March, 2024 Bangkok
- 60 mins
Dónal Murray / [seadanda](https://github.com/seadanda)
----
## Workshop structure
- Top level slides give an overview, but each section has more depth.
- This is not a lecture, everybody get involved 😀
----
Choose your own adventure
---
## Overview
- Motivation
- Specification
- Status
- Broker architecture
- Coretime Chain and Relay integration
- Pricing and economics
---
## Agile Coretime is...
- a fundamental change in how the network functions
- a paradigm shift in the way projects secure cores for their tasks
- a new first-class market on Polkadot
- a catalyst for secondary markets
- not CoreJam (out of scope for this talk)
----
[FAQs](https://polkadot-public.notion.site/Agile-Coretime-FAQ-c930796e8c884011adb1fa24ef22f77c#4044ec0996054c48b3f8dde0eaca4584)
---
## Motivation
---
## Coretime aims to:
- lower the barrier to entry
- encourage maximal utilisation of blockspace
----
- Coretime lowers the barrier to entry vs auctions and leases
- No longer need to secure 10s of millions of DOT upfront from crowdloans
- Pay for a month at a time with bulk, or only pay for what you need with on-demand
----
- Coretime maximises utilisation of blockspace
- Median utilisation currently ~1.8% for both Kusama and Polkadot
- \> 10 million blocks per 2 year lease
- ... still ~10 million blocks of untapped potential
- [Polkadot Weigher](https://polkadot-weigher.com/history) by RegionX
---
## Secondary aims:
- Predictable pricing
- Market-driven pricing
- Flexibility in usage patterns
... And these aims are in tension. See later
---
## Specification
----
## RFC to define the revenue
----
## RFC-1 - Agile coretime
- Minimize the barriers to entry in the ecosystem.
- Allow projects to budget long term with price predictability.
- Scale well with a continuously changing number of cores, up to 1,000.
- Facilitate the optimal allocation of work to cores of the Polkadot UC.
- Don't add complexity to the relay chain through coretime-specific logic.
- [RFC-1](https://polkadot-fellows.github.io/RFCs/approved/0001-agile-coretime.html)
----
## RFC-5 - The interface
- Low-latency scheduling on a varying number of individual cores in various allocation patterns.
- Relay must notify coretime chain about relevant information.
- Coretime credits.
- [RFC-5](https://polkadot-fellows.github.io/RFCs/approved/0005-coretime-interface.html)
----
## RFC-010 - Burn it all
- Burn bulk coretime revenue
- to avoid disrupting the steady and predictable Treasury income
- to balance inflation
- to be a clear cost to projects and a benefit to all token holders.
- [RFC-0010](https://polkadot-fellows.github.io/RFCs/approved/0010-burn-coretime-revenue.html)
----
---
## Coretime chain implementation status
- Coretime chain runtimes tested on Rococo and Westend
- Deploying very soon on Kusama with implementation differences as part of `1.2` release
- Future improvements/additions
----
- Restrictive auction model
- Enshrined renewals present pricing difficulties
- Change the renewals mechanism? [RFC-017](https://github.com/polkadot-fellows/RFCs/pull/17)
---
## Relay chain implementation status
- Migrations and bulk fully implemented
- On-demand working but only when purchased directly with native token on relay
- On-demand not in final state - no coretime credits
- Cannot purchase with coretime chain
- Can't claim for contributed pool cores
- No coretime vouchers
----
## Deployment status
#### Rococo
- Deployed end of 2023
- Solved issues with migration and weights
- Configured and started sales in January 2024
- Double the cores, double the fun
- Lots of activity since!
- Learnt a lot from the process
----
#### Westend
- Deployed smoothly
- Configured and sales started
- System Parachains only
- No additional cores
----
#### Kusama
- Code being finalised in [`fellowship/runtimes#212`](https://github.com/polkadot-fellows/runtimes/pull/212)
- Pricing models proposed
- Auctions will be cancelled
- Leases yet to start will be refunded
- Runtime upgrade timed to land on LP boundary
- First sale includes cores to replace cancelled auctions
----
#### Polkadot
- Learn from Kusama deployment
- More in depth pricing and economic projections
- Attempt to correct pricing adaption models
- Final audits
- Generalise implementation?
- Always use market clearing price?
- Minimise volatility?
- RFCs incoming
---
## Broker pallet architecture
- Periodic Dutch auctions for bulk coretime regions
- [Price adaption](https://github.com/seadanda/runtimes/blob/71f8f15089f8d55a4a182b812987341751850384/system-parachains/coretime/coretime-kusama/src/coretime.rs#L246) between sales
- [Tick function](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/broker/src/tick_impls.rs#L38) which runs every block
- Coretime NFT which can be customised, transferred and assigned a task or to the on-demand pool.
----
[rustdocs](https://paritytech.github.io/polkadot-sdk/master/pallet_broker/index.html)
---
## On-demand nomenclature
- On-demand: small increment coretime bought immediately before usage, on the scale of a block
- Coretime credit: tokens set aside to purchase on-demand
- Coretime vouchers: A voucher for coretime credits which can be gifted
----
## Bulk nomenclature
Timeslice
: an 80-block-long period of time
Mask
: an 80bit binary string representing an allocation pattern
Bulk
: coretime bought in advance, on the scale of a region
Region
: an asset representing bulk coretime
----
## Regions can be:
Split
: to create a pair of regions around a pivot, with one region ending at the pivot and the new one beginning
Interlaced
: to create a pair of regions which have the same start and end, but with masks that XOR to give a complete mask.
Transferred
: to a new owner
----
## Region naming
- Confusing name?
- A region of the phase space of the Polkadot UC core allocation
- All possible allocations are uniquely defined by combinations of cores and timeslices, with an inner topology represented by the mask
- Mapping these combinations gives a three dimensional phase space
- The NFT represents a **region** of this phase space
- The region still needs the mask to constrain its span in the third dimension
---
## The sale
----
Play around with pricing
[Lastic simulator](https://lastic.streamlit.app/)
---
## Renewals
- Tasks assigned to regions can qualify for renewal
- Pay the smaller of the current market price or the task's capped renewal price
- Assignments must be [`Final`](file:///Users/donal/dev/polkadot-sdk/target/doc/pallet_broker/enum.Finality.html)
- Must not be split
---
## The migration
- Runtime upgrade migrates leases
- Parachains with legacy leases are assigned regions of coretime until their lease ends
- Pre-assigned means that no customisation or transfers can be done
- Their core is [renewable](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/broker/src/tick_impls.rs#L222) for the market price in the sale their lease expires
---
## Coretime Interface
This interface is defined in RFC-5
- Bidirectional communication via XCM `Transact`s
- Implementation [here]()
---
## Frontends/integrations?
Marketplaces
: [Lastic](https://test.lastic.xyz/)
: [RegionX CoreHub](https://regionx.tech/)
Frontend
: [PolkadotJS apps](https://github.com/polkadot-js/apps/issues/10285)
APIs
: [PolkadotJS API](https://github.com/polkadot-js/api)
: [PAPI](https://github.com/polkadot-api/polkadot-api)
---
## Pricing and economics
- Broker implementation very sensitive to initial configuration and price adaption mechanism
- If we still have time, let's go deeeep
----
Play around with pricing with the [Lastic streamlit app](https://lastic.streamlit.app/)
----
```rust
pub trait AdaptPrice {
fn leadin_factor_at(when: FixedU64) -> FixedU64;
fn adapt_price(
sold: CoreIndex,
target: CoreIndex,
limit: CoreIndex
) -> FixedU64;
}
```
----
[The pricing suggestion for Kusama](https://hackmd.io/LgD1J5OnSnKK5Rv4j2-lTg)
----
## A limitation
- Current model has a short memory (one sale)
- Overly sensitive to statistical fluctuations
- Especially in early conditions
- Lots of cores "used" by leases
- Small number of cores available
- (relatively) small percentage of active teams off leases
----
## An idea:
Expand price adaption to enable smoothing
- Some sort of moving average
- Reduce volatility
- Enable removal of renewal cap?
- Or renewal could have a lagged relationship with market price
----
## General pricing function:
$$ p_{n}(t) = p_{\textrm{last}_{n-1}} \cdot A(s_{n-1}) \cdot L(t) $$
Where:
$p_{n}(t)$ is the price in sale $n$ at a given point in time $t$
$p_{\textrm{last}_{n-1}$ is the price of the last core in the previous sale
$A(s_{n-1})$ is the price adapter
$s_{n-1}$ is the state of the last sale
$L(t)$ is a function yielding the lead-in factor at time $t$
----
Broker assumptions make this more specific
[more details](https://hackmd.io/2mhe_5p5SU2qEpAwvj1_xQ)
---
## Async Backing, elastic scaling and PoV reclaim
Maximal utilisation efficiency 💦
See Sebastian Kunert's talk on elastic scaling and PoV reclaim
{"title":"Polkadot Summit Coretime","contributors":"[{\"id\":\"3e13a20b-0537-4515-b38e-904c29597c7e\",\"add\":14979,\"del\":5287}]","description":"Monday 11th March, 2024 Bangkok"}