In the first article of this series, we highlighted the history, industries and major use cases involved in the NexOS evolution. This article will explore the crucial factors and fundamental intricacies of the technical foundation and frameworks bringing this innovation to fruition.
Instead of relying on generic technology ill-suited for blockchain’s specific characteristics, Nexus manages to interoperate with the current internet infrastructure while offering the seed of an alternative future.
The Nexus Operating System (NexOS) and Protocol (NP) each rely on several key components thoughtfully interwoven to work in harmony. The Lower Level Library (LLL) represents a major part of the puzzle. Referred to as a ‘template library’ written in C++, it consists of database, cryptographic, and protocol templates for use throughout the software stack (graphic below). These base templates are inherited in higher level programming languages, allowing accessibility through a HTTP JSON based API (layer five).
Another way of thinking about it follows: instead of an environment enabling any possible computation such as Turing complete blockchains, templates deep within the software enable the most important aspects of cryptographically-secured value transfer, and the higher layers build upon those templates. The register-based virtual machine of Nexus (accounts, tokens, NFTs, and names all come from registers) is built from the templates provided by Lower Level Database (LLD).
Split into three sections, the LLL provides base classes focusing on cryptographic, protocol and database functions. These are referred to as LLC, LLP and LLD (Lower Level….Crypto, Protocol, and Database). Each branch provides a foundation for different aspects of the protocol; they are not separate and often interrelate. For instance, all cryptographic functions originate from the LLC, but always are in demand for various databases and protocols which live in the LLD and LLP respectively.
This core functionality must be linked with the under-development NexOS, but other advantages such as the consensus mechanisms provide a decentralized and trustless computation on the registers. An OS enables Nexus to integrate this distributed, virtualized, and authenticated basis of truth closer to a machine's hardware resources, significantly enhancing integrity, confidentiality, and overall security in general. Simultaneously this design is aimed at fulfilling various IoT requirements including device interoperability, abstracted frameworks available as an API, authenticated user activity and energy efficiency.
Operating System Design - Microkernel Vs Monolithic Kernel
Kernels are the closest software to your computer’s hardware, often referred to as Ring 0. They allocate and regulate applications with the necessary physical resources while maintaining strong isolation characteristics between processes.Most applications run in a unprivileged “user mode” rather than the privileged “kernel mode” which gives access directly to the hardware(5). Kernel design and management represents a key feature distinguishing operating systems.
Monolithic Kernel
Many types of kernels exist, but most consumer OSs tend toward what's called monolithic kernels. Monolithics use the kernel for all system operations such as memory handling, file operations, drivers and thread scheduling. This monolithic structure keeps operations quick by not requiring IPC (Inter-Process Communication), however has limitations such as poor fault tolerance (if a driver crashes, your kernel and thus computer will crash too). The historic Windows Blue Screen of Death in early Windows computers highlights the sensitivity of monolithic kernels, as one minor mistake can cause full system failure.
Microkernel
Microkernels embody a modular design focusing on fault tolerance and footprint minimization. Since a primary goal of kernels is to shield the hardware space, microkernels avoid running unnecessary code in the privileged space when it could be offloaded to the user mode (unprivileged). The increased fault tolerance and modularity can come at the cost of latency, especially in interactions with non-kernel components, but the security and code simplicity helps make up for the loss. (1)
The Foundation: seL4
Nexus has finally settled upon the seL4 (secure L4) microkernel as a foundation for NexOS. The seL4 microkernel branches from the L4 family of microkernels. This family has enjoyed significant commercial success (including billions in mobile phone sales) and adoption in critical systems around the world (2).
Released in 2009 by the Trustworthy Systems group, seL4 focuses on critical systems such as military applications such as drones and satellites. Its core innovation comes from the guarantees in isolation properties between applications and unique approaches to kernel resource management. Specifically, seL4 led the world of operating systems by becoming the first formally verified general purpose microkernel (proofs are limited to only a few instruction sets such as ARM).
Formal verification involves transforming a code’s specification into mathematical abstractions, then constructing proofs to “prove” that the implementation follows the specification (3). Some describe formal verification as proving that bugs can’t occur, but this is imprecise, especially in complex systems where unknown inputs exist.
For consumer applications which may be designed for other operating systems, seL4 runs a hypervisor which allows the virtualization of another OS (windows linux, etc.), however a consumer level use implementation of the NexOS won't occur until IoT use cases exhibit success. Overall, SeL4 provides Nexus developers an extremely stable, proven and innovative microkernel to serve as the cornerstone for NexOS.
NexOS
This type of design can only be pursued because of the opportunities the distributed ledger provides. Listed below, three main innovations illustrate this novel security infrastructure. The first two relate to traditional components of operating systems, however the third, software defined routers, entails a much larger conversation about physical networks, which we will uncover in the final article.
Runtime memory and binary verification (e.g. buffer overflow, etc.)File integrity via merkle trees (e.g. malware, event log manipulation, etc.)Software-defined routers (e.g. spoofing, route poisoning, surveillance, etc.)
Runtime memory provides the temporary storage necessary for processing binary instructions. Operating systems create memory to process code and reclaims that memory once the process is finished. Binary verification refers to the ability to check that the binaries (0s and 1s comprising code) match a referential source.
With NexOS, all executable code must be authenticated either by the source developer or by the user running the application. To explain, let's look at installing a module on the existing Nexus desktop wallet. The hash of the binary you're installing has to match the hash listed on the github repo. The green check mark signifies that the hashes match:
To make sure it's understood, the image above just shows the pattern the team will extend to the operating system, not an image of its use.
In NexOS, instead of matching with github repo as shown above, the hash will have to match with the one stored in the developers Signature Chain. Every single runtime instruction will be authenticated with additional checksums.
The team decided to approach File System integrity by utilizing merkle trees. Instead of hashing the entire file and storing that for authentication, merkle trees allow hashing of subsets of files, so changes to one part won't require rehashing of the entire file. Creating a new file requires a user's confirmation, generating a new merkle root that can be stored in a special object register, on the blockchain, that points to the data itself.
NexOS significantly improves the root of trust with a distributed ledger, mitigating the inherent risk of Certificate Authorities (CA), 3rd-party back doors and similar vulnerabilities. This and the other authentication features remove the ability for many common attack vectors like trojans, injections and similar techniques. NexOS will not be impenetrable, social engineering and similar threats will continue to be a challenge. Although, the design aims to significantly diminish the developmental mistakes, backdoors and related issues that lead to most incidents involving security and privacy compromises.
We hope you enjoyed the article! The third and final installment of this series will be published next week.