---
title: Polkadot Kernel/Userland
tags: Polkadot
description: Robert Habermeier's presentation at Sub0 2023
type: slide
---

## Polkadot Kernel/Userland

A new mental model for Polkadot's technology

---

## 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