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
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.
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.
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:
Good categories to identify the stack
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
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:
Looks at all parachain blocks landing on cores
Checks each parachain block descends from its parent
Checks each parachain block behaves correctly in messaging, respects queue buffers, etc.
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
Resume presentation
Polkadot Kernel/Userland A new mental model for Polkadot's technology
{"showTags":"false","title":"Polkadot Kernel/Userland","description":"A possible vision of the future","contributors":"[{\"id\":\"5e8fb0c4-eedb-4242-a274-7d4baea002b3\",\"add\":6562,\"del\":1556}]"}