Post 1.0

• Identify generalizations of existing technology
• Use generalizations to open new attachment points for building on Polkadot

• Agile Coretime makes core procurement more flexible
• The focus here is on core utilization

What has been built?

The Relay Chain

Global validator set, BFT consensus, Governance, Cores, Parachain Consensus

Validators each bring (at least):

• 500Mbps bandwidth
• 16GB RAM
• 8 CPUs

1. Data Availability System

Ensure blobs of data remain available to fetch even under adversarial conditions

2. Code Execution Validity System

Ensure commitments to the outputs of Wasm code are accurate without all validators needing to check

Blobs from (1) are inputs to code

3. Cores

• Evenly dividing validators' bandwidth and CPU resources for usage in (1) and (2).
• Each core handles one work package per RC block

Cores on Polkadot

• ~1MBps data availability each
• 1500 sTPS in FRAME each
• Currently 50 cores, aiming for 200+ in 2024
• # of cores is a function of # of validators and network protocols

Work packages on Cores

• 1 per 6s per core
• 2s execution
• 5MB data

The Parachains Protocol

Uses cores to progress blockchains and message queues

• "This work package meant a new block was added"
• "This work package meant some messages were sent"

At the moment the only way to use cores.

Core-usage retrospective

1. Data and compute workloads should be maximally full for best system utilization

2. Most core users need far less than a single core at any time.

Typical core workload is ~250Kb and takes 100ms

3. Atomic composability between state machines by using a core together.

Kernel / Userland

Conceptual split.

Kernel: low-level, generalized provider of data and compute resources

Userland: mid-level, high-level, increasingly specialized users of data and compute.

As the ecosystem develops, we need:

1. Good categories to identify the stack
2. Pluggable interfaces for core utilization

Kernel

• Chief concerns: core utilization, performance, security.
• Use-case neutral
• Very low-level: networking, consensus, databases, VMs
• Provides data and compute resources
• Stable, pluggable interface to higher-level logic
• Coretime allocation primitives

Userland

• Chief concern: Applying cores to do useful things
• Permissionlessly deploy use-case-specific code

Userland Examples

• System parachains (permissioned but not enshrined)
• Shared builders (collators)
• Parachains Protocol
• Cumulus

Interfaces

Interface 1: Who buys coretime?

Builder Sets: A generalization over existing collator sets

Coretime is currently sold to Parachains.

This is the same as selling to a builder-set which only works on a single parachain.

Builder sets generalize over cryptography, consensus, authorization mechanisms.

Builders can

• Build work packages which advance multiple parachains simultaneously and compose atomically
• Submit an arbitrary amount of work packages for a single parachain at the same time

Interface 2: Pluggable side effects of work packages on the relay chain

Example: Parachains Protocol

The Relay chain runtime currently:

1. Looks at all parachain blocks landing on cores
2. Checks each parachain block descends from its parent
3. Checks each parachain block behaves correctly in messaging, respects queue buffers, etc.
4. Updates storage with the new parachain head, message queues

These are side effects of work done on cores. What about a generalization?

Allow anyone to register new logic on the relay chain which can update storage based on work packages submitted to cores.

Most current use-cases need far less than 1 core.

Core sharing within workloads is preferable to core sharing with full workloads and low frequencies.

Core supply is likely to outstrip demand - many opportunities for experimentation

Userland doesn't mean application-layer.

There is a lot of infrastructure to be built - an entire blockspace supply chain.

Most of this coordination will happen off-chain.

Built in the open

True open-source design, RFCs

Build Together