|
| 1 | +--- |
| 2 | +publication_date: 2025-05-12T13:17:22Z |
| 3 | +slug: kernel and realm |
| 4 | +tags: [kernel, process, realm] |
| 5 | +authors: [mvertes] |
| 6 | +--- |
| 7 | + |
| 8 | +# Gno realms vs system kernels |
| 9 | + |
| 10 | +Let's explore the analogy between Gno and existing operating systems. |
| 11 | + |
| 12 | +In computers, the role of the operating system is to isolate each process from |
| 13 | +the others, for memory integrity and security, and to control access to system |
| 14 | +resources, including time sharing access to the CPU. It also lets processes |
| 15 | +communicate with others, or externally through the network. |
| 16 | + |
| 17 | +The operating system provides those capabilities through the kernel, which |
| 18 | +executes system calls. When invoked by a user process, the kernel switches |
| 19 | +the CPU into a privileged mode, to perform the services outside user reach. |
| 20 | +Each resource located outside of the process means the private user memory must |
| 21 | +be manipulated through system calls. This is done under the strict supervision |
| 22 | +of the kernel, which acts as a neutral trusted facilitator between untrusted |
| 23 | +processes. On bare metal systems, this is enforced by the hardware itself. |
| 24 | + |
| 25 | +Gno is a distributed multi-user virtual computer implemented on top of the |
| 26 | +blockchain, ensuring all operations execute deterministically. The distributed |
| 27 | +storage layer of the blockchain provides Merkle trees and consensus-based |
| 28 | +verification that makes program code and memory tamper-proof. |
| 29 | + |
| 30 | +In Gno, the equivalent of computer processes are *realms*. Each realm is like |
| 31 | +an always-active process, running forever, similar to a web server. In a |
| 32 | +regular system, a live process is defined by its Process Identifier (PID, a |
| 33 | +number set by the system for the life of the process), its memory, and the set |
| 34 | +of system resources it uses at a given time (files, connections, etc). |
| 35 | +Similarly in Gno, a realm is defined by its identity (a unique package path), |
| 36 | +its global memory state (the content of memory when the realm is at rest), |
| 37 | +which may contain for example the amount of coins it retains. |
| 38 | + |
| 39 | +A realm may provide services to other realms through the exported |
| 40 | +functions it declares, and it may use services provided by other realms by |
| 41 | +importing the realm using an `import` statement, and directly calling its |
| 42 | +functions in code. The way of declaring exported functions and importing them |
| 43 | +is exactly identical to how packages are defined in the Go language. A realm is |
| 44 | +a Gno process, but is also a package (in the Go sense). |
| 45 | + |
| 46 | +Functions in packages can be pure (in the functional programming sense: the |
| 47 | +function has no side effects and operates only on temporary local variables |
| 48 | +which are discarded at return), or not: some variable outside of the function |
| 49 | +scope is modified. In that case, the modified variable must be defined in the |
| 50 | +same package as the function. Functions can only write to global variables |
| 51 | +declared within their own package space (assuming variables are unexported), |
| 52 | +and static code analysis, as in Go, enforces this rule. |
| 53 | + |
| 54 | +However, since realms are also stateful processes with their own identity and |
| 55 | +protected space, and because a process can write only in its own space, calling |
| 56 | +a non-pure function imported from another realm means that the caller realm |
| 57 | +would attempt to write in the callee realm space, which is forbidden! |
| 58 | + |
| 59 | +To resolve this, the current realm identity is switched from the caller to the |
| 60 | +callee until the function returns, like when crossing the user-kernel boundary |
| 61 | +in a regular system call. From the system's point of view, the current realm is |
| 62 | +set to the callee, the previous realm to the caller. At function return, the |
| 63 | +current realm and previous realm are restored to their original value. |
| 64 | + |
| 65 | +So non-pure exported functions act exactly like a system call: they provide the |
| 66 | +ability to write outside the calling realm space, by crossing the realm |
| 67 | +boundary. A realm doesn't need to trust the calling realm: only itself can |
| 68 | +write in its own space. A realm doesn't need to trust an external kernel: it is |
| 69 | +its own kernel, it decides exactly how its data can be accessed and/or modified |
| 70 | +by caller realms. |
| 71 | + |
| 72 | +Gno unifies the concepts of Go packages and Unix processes in a single, simple |
| 73 | +concept: the realm. The kernel is decentralized and put back in control of |
| 74 | +package developers. The operating system itself becomes transparent: realm |
| 75 | +processes are both resource users and providers, with full control and |
| 76 | +accountability. |
| 77 | + |
| 78 | +In Gno, programs are processes are packages are realms. Gno rethinks the |
| 79 | +traditional boundaries between processes, packages, and system calls. By making |
| 80 | +each realm self-contained and in control of its own state, it replaces the need |
| 81 | +for a central kernel with a decentralized model where programs define their own |
| 82 | +access rules. It’s a practical and minimal approach to building secure, |
| 83 | +composable software on-chain. |
0 commit comments