Let’s Learn About Polkadot’s Brain: The Runtime
Hey everyone, today I want to break down one of the most important parts of Polkadot: its Runtime. It can seem complicated, but once you get the hang of it, it’s actually a really clever idea.
Before we dive in, let’s get a few basic definitions out of the way. These will help everything else make more sense.
Some Key Concepts Before We Start
- Discrete State Machine (DSM): This is just a fancy way of saying a system has a limited number of states (like “On” or “Off”) and can only switch between them based on specific inputs. Think of a simple vending machine—it’s either idle, waiting for money, or dispensing a drink. It can’t be in between states.
- Path Graph: Imagine a line of dots where each dot is connected only to the one before it and the one after it (except for the start and end dots). That’s a path graph.
- Blockchain as a Path Graph: A blockchain is basically a path graph where each dot is a block. The first block is the “genesis block,” and the last one is the “head” of the chain.
- Replicated State Machine: This is the core idea of a blockchain. It’s a state machine (like our vending machine) that is copied (replicated) across many computers. They all process the same commands to make sure they all have the exact same state, which keeps the network secure and consistent.
Okay, Let’s Get Started: What Is Polkadot?
At its core, Polkadot is designed to be a system of many blockchains working together. To make this possible, its architecture is split into two main parts:
- The Host: Think of this as the computer’s hardware and operating system. It’s the stable, underlying part that handles basic tasks like networking, consensus (how nodes agree), and storing data.
- The Runtime: This is the software running on the “hardware.” It’s the “brain” that contains all the rules and logic of the blockchain. It defines what a transaction is, how governance works—everything that makes the chain unique.
The coolest part? The Runtime can be upgraded without stopping the network. Because it’s a separate piece of software, the community can vote to swap it out for a new version, kind of like updating an app on your phone. This is what people mean when they say “forkless upgrades.”
The Different Jobs: Types of Nodes
Not every computer on the network does the same thing. Depending on their role, they are different types of nodes running the Host software:
- Light Client: A lightweight node for devices like phones. It doesn’t store the whole blockchain. Instead, it just asks full nodes for the specific information it needs and verifies it’s correct.
- Full Client: A passive observer that downloads and checks every single block to make sure all the rules are followed. It holds a full copy of the blockchain’s history.
- Authoring Client: An active participant. It does everything a full client does, but it can also create new blocks and vote on which blocks should be made permanent.
- Relaying Node: The super-node. It does everything an authoring node does, plus helps validate and secure all the parachains connected to the network.
Now, let’s get a visual of how all this fits together.
A Look at the Architecture
This diagram shows how different parts of the Runtime—like pallets and system modules—are organized. It gives you a good idea of the layered structure.
And to build all this, developers use a specific set of tools.
The Polkadot Tech Stack
This image breaks down the main components developers use to build on Polkadot. Substrate is the foundation, FRAME is the toolkit for building the blockchain’s logic, and things like Cumulus and XCM help parachains connect and communicate.
A Closer Look at the Runtime
With that context, let’s dive deeper into the Runtime itself. This is where all the “rules of the game” for a blockchain are written.
How History is Recorded: Blocks
The blockchain’s history is stored in blocks. Each block is a package of information with two parts: a header and a body.
The Block Header
The header is like the block’s summary card. It contains:
parent_hash: A cryptographic fingerprint of the previous block, which links the blocks together into a chain.number: The block’s number in the sequence (e.g., block #1,234,567).state_root: A single hash that represents the entire state of the blockchain after this block’s changes. If even one tiny thing was different, this hash would be completely different.digest: A spot for extra data, like the signature of the block’s author.
The Block Body and “Extrinsics”
The body of a block contains extrinsics. This is Polkadot’s term for any information coming from outside the blockchain that can cause a change inside it.
There are two main types of extrinsics:
- Transaction Extrinsics: These are what we normally think of as transactions. A user signs a message with their private key to do something like send tokens. These are broadcast across the network for a block author to include.
- Inherent Extrinsics: These are special, unsigned pieces of data that a block author adds themselves. They aren’t sent around the network by users. A common example is a timestamp—the block author just adds the current time to the block so everyone can agree on it.
Storing Everything: The State Trie
Every time a new block is added, the state of the network changes (balances go up or down, etc.). A node needs to keep track of the state at many different points in time, especially for blocks that aren’t finalized yet.
Doing this by saving a full copy of the database for every block would be impossible. Instead, Polkadot uses a State Trie.
A trie is a special tree-like data structure. When the state changes, it doesn’t copy all the unchanged data. It just creates new branches for the updated information and re-uses all the old parts. This is super efficient and makes it easy to look up the state at any point in history.
Polkadot also has Child Storage. You can think of this as creating separate, smaller state tries inside the main one. This is really useful for things like smart contracts, so that two different contracts can’t accidentally interfere with each other’s storage.
Building a Runtime: FRAME and Pallets
So, how does a developer actually build a runtime? They don’t have to write everything from scratch. They use a toolkit called FRAME (Framework for Runtime Aggregation of Modularized Entities).
Think of FRAME as a big box of Lego bricks for building blockchains. The bricks themselves are called Pallets.
A Pallet is a module of code that handles one specific feature. There are pallets for:
- Managing account balances (the Balances pallet).
- Handling staking and validators (the Staking pallet).
- Enabling on-chain governance (the Governance pallet).
To build a custom blockchain, a developer just picks the pallets they need, configures them, and puts them together. They can also create their own custom pallets for unique features.
When writing a pallet, developers use simple tags to define how it works, like:
#[pallet::storage]: Defines a piece of data to be stored on the blockchain.#[pallet::event]: Defines an event that can be emitted (e.g., “Tokens Transferred”).#[pallet::call]: Defines a function that users can call (an extrinsic).
And that’s the gist of it! The Runtime is the flexible, upgradeable “brain” of Polkadot, built from modular pallets using the FRAME framework. It’s what allows Polkadot and its parachains to be so powerful and adaptable.
In the next post, we’ll look at the “body”—the Host—and explore how things like block production, finality, and networking actually work. Thanks for reading!
References and Further Reading
For those who want to go even deeper, these are some great resources to check out:
Polkadot Runtime Specification: This is the official, highly technical specification for the Polkadot Runtime. It’s very detailed and perfect if you want to understand the exact mechanics of how everything works under the hood.
Introduction to the Polkadot SDK: A fantastic starting point for developers. This document explains the tools and frameworks (like Substrate and FRAME) that are used to build runtimes and parachains on Polkadot[1].