You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -17275,6 +17276,105 @@ Key features of Chopsticks include:
17275
17276
Chopsticks provides a controlled environment for developers to safely explore the effects of runtime changes. It ensures that network behavior is tested and verified before upgrades are deployed to live networks.
description: Learn how Polkadot SDK-based nodes function, how the client and runtime are separated, and how they communicate using SCALE-encoded data.
17284
+
---
17285
+
17286
+
# Node and Runtime
17287
+
17288
+
## Introduction
17289
+
17290
+
Every blockchain platform relies on a decentralized network of computers, called nodes, that communicate with each other about transactions and blocks. In this context, a node refers to the software running on the connected devices rather than the physical or virtual machines in the network.
17291
+
17292
+
Polkadot SDK-based nodes consist of two main components, each with distinct responsibilities: the client (also called node) and the runtime.
17293
+
17294
+
If the system were a monolithic protocol, any modification would require updating the entire system. Instead, Polkadot achieves true upgradeability by defining an immutable meta-protocol (the client) and a protocol (the runtime) that can be upgraded independently.
17295
+
17296
+
This separation gives the [Polkadot Relay Chain](/polkadot-protocol/architecture/polkadot-chain){target=\_blank} and all connected [parachains](/polkadot-protocol/architecture/parachains){target=\_blank} an evolutionary advantage over other blockchain platforms.
17297
+
17298
+
## Architectural Principles
17299
+
17300
+
The Polkadot SDK-based blockchain architecture is fundamentally built on two distinct yet interconnected components:
17301
+
17302
+
- **Client (Meta-protocol)**
17303
+
- Handles the foundational infrastructure of the blockchain
17304
+
- Manages runtime execution, networking, consensus, and other off-chain components
17305
+
- Provides an immutable base layer that ensures network stability
17306
+
- Upgradable only through hard forks
17307
+
17308
+
- **Runtime (Protocol)**
17309
+
- Defines the blockchain's state transition logic
17310
+
- Determines the specific rules and behaviors of the blockchain
17311
+
- Compiled to WebAssembly (Wasm) for platform-independent execution
17312
+
- Capable of being upgraded without network-wide forking
17313
+
17314
+
### Advantages of this Architecture
17315
+
17316
+
- **Forkless upgrades** - runtime can be updated without disrupting the entire network
17317
+
- **Modularity** - clear separation allows independent development of client and runtime
17318
+
- **Flexibility** - enables rapid iteration and evolution of blockchain logic
The node, also known as the client, is the core component responsible for executing the Wasm runtime and orchestrating various essential blockchain components. It ensures the correct execution of the state transition function and manages multiple critical subsystems, including:
17324
+
17325
+
- **Wasm execution** - runs the blockchain runtime, which defines the state transition rules
17326
+
- **Database management** - stores blockchain data
- **Transaction pool (Mempool)** - manages pending transactions before they are included in a block
17329
+
- **Consensus mechanism** - ensures agreement on the blockchain state across nodes
17330
+
- **RPC services** - provides external interfaces for applications and users to interact with the node
17331
+
17332
+
## Runtime
17333
+
17334
+
The runtime is more than just a set of rules. It's the fundamental logic engine that defines a blockchain's entire behavior. In Polkadot SDK-based blockchains, the runtime represents a complete, self-contained description of the blockchain's state transition function.
17335
+
17336
+
### Characteristics
17337
+
17338
+
The runtime is distinguished by three key characteristics:
17339
+
17340
+
- **Business logic** - defines the complete application-specific blockchain behavior
- **On-chain storage** - stored within the blockchain's state, allowing dynamic updates
17343
+
17344
+
### Key Functions
17345
+
17346
+
The runtime performs several critical functions, such as:
17347
+
17348
+
- Define state transition rules
17349
+
- Implement blockchain-specific logic
17350
+
- Manage account interactions
17351
+
- Control transaction processing
17352
+
- Define governance mechanisms
17353
+
- Handle custom pallets and modules
17354
+
17355
+
## Communication Between Node and Runtime
17356
+
17357
+
The client and runtime communicate exclusively using [SCALE-encoded](/polkadot-protocol/basics/data-encoding){target=\_blank} communication. This ensures efficient and compact data exchange between the two components.
17358
+
17359
+
### Runtime APIs
17360
+
17361
+
The Runtime API consists of well-defined functions and constants a client assumes are implemented in the Runtime Wasm blob. These APIs enable the client to interact with the runtime to execute blockchain operations and retrieve information. The client invokes these APIs to:
17362
+
17363
+
- Build, execute, and finalize blocks
17364
+
- Access metadata
17365
+
- Access consensus related information
17366
+
- Handle transaction execution
17367
+
17368
+
### Host Functions
17369
+
17370
+
During execution, the runtime can access certain external client functionalities via host functions. The specific functions the client exposes allow the runtime to perform operations outside the WebAssembly domain. Host functions enable the runtime to:
description: Learn how Polkadot SDK-based nodes function, how the client and runtime are separated, and how they communicate using SCALE-encoded data.
4
+
---
5
+
6
+
# Node and Runtime
7
+
8
+
## Introduction
9
+
10
+
Every blockchain platform relies on a decentralized network of computers, called nodes, that communicate with each other about transactions and blocks. In this context, a node refers to the software running on the connected devices rather than the physical or virtual machines in the network.
11
+
12
+
Polkadot SDK-based nodes consist of two main components, each with distinct responsibilities: the client (also called node) and the runtime.
13
+
14
+
If the system were a monolithic protocol, any modification would require updating the entire system. Instead, Polkadot achieves true upgradeability by defining an immutable meta-protocol (the client) and a protocol (the runtime) that can be upgraded independently.
15
+
16
+
This separation gives the [Polkadot Relay Chain](/polkadot-protocol/architecture/polkadot-chain){target=\_blank} and all connected [parachains](/polkadot-protocol/architecture/parachains){target=\_blank} an evolutionary advantage over other blockchain platforms.
17
+
18
+
## Architectural Principles
19
+
20
+
The Polkadot SDK-based blockchain architecture is fundamentally built on two distinct yet interconnected components:
21
+
22
+
-**Client (Meta-protocol)**
23
+
- Handles the foundational infrastructure of the blockchain
24
+
- Manages runtime execution, networking, consensus, and other off-chain components
25
+
- Provides an immutable base layer that ensures network stability
26
+
- Upgradable only through hard forks
27
+
28
+
-**Runtime (Protocol)**
29
+
- Defines the blockchain's state transition logic
30
+
- Determines the specific rules and behaviors of the blockchain
31
+
- Compiled to WebAssembly (Wasm) for platform-independent execution
32
+
- Capable of being upgraded without network-wide forking
33
+
34
+
### Advantages of this Architecture
35
+
36
+
-**Forkless upgrades** - runtime can be updated without disrupting the entire network
37
+
-**Modularity** - clear separation allows independent development of client and runtime
38
+
-**Flexibility** - enables rapid iteration and evolution of blockchain logic
The node, also known as the client, is the core component responsible for executing the Wasm runtime and orchestrating various essential blockchain components. It ensures the correct execution of the state transition function and manages multiple critical subsystems, including:
44
+
45
+
-**Wasm execution** - runs the blockchain runtime, which defines the state transition rules
46
+
-**Database management** - stores blockchain data
47
+
-**Networking** - facilitates peer-to-peer communication, block propagation, and transaction gossiping
48
+
-**Transaction pool (Mempool)** - manages pending transactions before they are included in a block
49
+
-**Consensus mechanism** - ensures agreement on the blockchain state across nodes
50
+
-**RPC services** - provides external interfaces for applications and users to interact with the node
51
+
52
+
## Runtime
53
+
54
+
The runtime is more than just a set of rules. It's the fundamental logic engine that defines a blockchain's entire behavior. In Polkadot SDK-based blockchains, the runtime represents a complete, self-contained description of the blockchain's state transition function.
55
+
56
+
### Characteristics
57
+
58
+
The runtime is distinguished by three key characteristics:
59
+
60
+
-**Business logic** - defines the complete application-specific blockchain behavior
-**On-chain storage** - stored within the blockchain's state, allowing dynamic updates
63
+
64
+
### Key Functions
65
+
66
+
The runtime performs several critical functions, such as:
67
+
68
+
- Define state transition rules
69
+
- Implement blockchain-specific logic
70
+
- Manage account interactions
71
+
- Control transaction processing
72
+
- Define governance mechanisms
73
+
- Handle custom pallets and modules
74
+
75
+
## Communication Between Node and Runtime
76
+
77
+
The client and runtime communicate exclusively using [SCALE-encoded](/polkadot-protocol/basics/data-encoding){target=\_blank} communication. This ensures efficient and compact data exchange between the two components.
78
+
79
+
### Runtime APIs
80
+
81
+
The Runtime API consists of well-defined functions and constants a client assumes are implemented in the Runtime Wasm blob. These APIs enable the client to interact with the runtime to execute blockchain operations and retrieve information. The client invokes these APIs to:
82
+
83
+
- Build, execute, and finalize blocks
84
+
- Access metadata
85
+
- Access consensus related information
86
+
- Handle transaction execution
87
+
88
+
### Host Functions
89
+
90
+
During execution, the runtime can access certain external client functionalities via host functions. The specific functions the client exposes allow the runtime to perform operations outside the WebAssembly domain. Host functions enable the runtime to:
0 commit comments