In my previous article, I went over how Radix Engine avoided some of the flaws in Sui’s MoveVM. To summarize:

Sui’s MoveVM follows the original Ethereum philosophy of a “clean, simple, beautiful” protocol, which delegates everything to the application layer. This allows developers the freedom to explore any domain, including unknown ones at the time.

A protocol that is too simple and unstructured, though, creates significant compromises. For example, common system features like authorization would require a complex implementation in the application space, standard interfaces may become more fragmented, and performance optimization becomes more difficult.

Radix Engine, on the other hand, is designed to execute non-generic, system-wide logic as a core technical goal, as it allows us to do the following:

Vitalik recently touched on this idea with the term “enshrinement”, or the idea of selectively breaking away from abstraction in order to gain the benefits of protocol-enforced logic. Stealing one of his images, he frames the problem as a tradeoff between abstraction vs. enshrinement:

This balance of supporting abstraction (i.e., future/diverse user needs) while maintaining performance/security/usability (i.e., enshrinement) is actually a very old computer science problem. The design of Operating Systems specifically has been trying to solve a similar problem for the past decades: How do we support a range of abstract applications while maintaining a fast, secure, usable system?

In this article, I will go over how Radix Engine uses the Operating System model to create a framework capable of all types of “enshrinement” without the load to protocol complexity or loss of flexibility that Vitalik fears.

Let’s start by looking at the current industry standard, the Ethereum Virtual Machine (“EVM”).

EVM as a VM

The EVM is basic enough that it can be modeled as a virtual machine (“VM”) with the following opcodes:

Smart contracts compiled into EVM bytecode can then be executed on top of such a VM.

In this model, any form of “enshrinement” requires changes to the EVM or the VM hardware. For example, enshrining BLS signature support would require adding a new precompile. Implementing EIP-2938 would require the addition of new opcodes. Expanding on what is enshrined inevitably results in a larger, more complicated VM and forces the protocol designer to make the one-or-the-other decision Vitalik describes.

The general problem with this model is that the Abstraction/Enshrinement dichotomy is too coupled with the Software/Hardware dichotomy. That is, enshrining any logic into the protocol forces it to be embedded into the VM. There is no way to express “enshrined software” or software that is part of the system.

Operating Systems solved this dichotomy with the notion of “system software.” Let’s take a closer look.

The Operating System Model

One of the main goals of an Operating System is to manage the software/hardware dichotomy – or, more specifically, the application/hardware dichotomy. The core part of any Operating System is the kernel, software that manages user space applications and their access to hardware. Kernel modules and drivers are additional pieces of system software that expand the set of supported hardware or extend kernel functionality.

\From an “enshrinement” perspective, the kernel and its modules are enshrined parts of the system but have the flexibility of software. Kernel modules, virtual machines (“VMs”), and user-space system processes are even more “soft” since these are abstracted from the kernel itself.

In this model, the layer of indirection between applications and hardware allows the software/hardware dichotomy to be decoupled from the abstraction/enshrinement dichotomy. “System software” allows for enshrinement without overburdening the hardware.

Radix Engine as an Operating System

Using this operating system model as inspiration, Radix Engine includes multiple layers, each with a specific responsibility and abstraction, allowing for system modularity and pluggability.

Such a modular design allows for system logic to be enforced while also allowing the following:

Let’s now go over each of these layers and see what their responsibilities are.

Application Layer

The application layer is responsible for defining high-level logic. Bytecode that describes this logic, along with other static information, is bundled up in an executable format called a Package. Packages are then stored on-ledger and available for execution.

Applications written in Scrypto, the Rust-based language we’ve built for DeFi development, live in this layer. Scrypto programs get compiled into WASM programs with access to a set of function exports that allow the program to access system/kernel services. This System Call API is similar to the Linux system calls, which provide access to shared I/O.

VM Layer

Moving to the next layer, the VM layer is responsible for providing the computing environment for the application layer. This includes a Turing-complete VM as well as the interface to access the system layer.

Radix Engine currently supports two VMs: a Scrypto WASM VM used to execute Scrypto applications and a native VM that executes native packages that are compiled to the host’s environment.

If we take a look at the Scrypto WASM VM specifically, it looks like this:

This may look essentially the same as the EVM model, but there are two crucial differences:

System Layer

The System Layer is responsible for maintaining a set of System Modules or pluggable software that can extend the functionality of the system. These are similar to Linux’s kernel modules.

On every system call, each system module gets called before the system layer passes control to the kernel layer. When called, each system module may update some particular state (e.g., update fees spent) or panic to end the transaction (e.g., if the type checker fails).

This pattern allows the system to implement functionality such as authorization, royalties, or type checking while being decoupled from both the application and kernel layers.

Kernel Layer

The kernel layer is responsible for the two core functionalities of Radix Engine: storage access and communication between applications. This is somewhat similar to the traditional Operating System’s responsibility for disk and network access.

For Radix Engine, this includes the following low-level management:

Enshrined Software

How do these layers relate to enshrinement in a DLT protocol? Similar to the kernel layer in Operating Systems, these middle layers of Radix Engine provide the indirection required to decouple the abstraction/enshrinement dichotomy from the software/hardware dichotomy and create the notion of “enshrined software”.

Enshrined software has the flexibility and security properties of software while maintaining the ability to enforce system-wide logic.

Let’s go over a few enshrinement examples that are currently running on the Radix network and see how they are implemented.

Enshrined Resources

The core differentiator of the Radix DeFi/Web3 platform is the idea that a resource (i.e., asset) is a fundamental primitive that should be understood separately from business logic. Enshrining this concept allows all dApps, wallets, and tooling to have a common understanding of what an asset’s interface and behavior look like, making composability much easier.

Though resources are one of the most ingrained parts of the system, implementing its enshrinement only requires two modular pieces of software:

The fact that Radix Engine could express the deep concept of a standardized, movable resource while being abstracted from the system/kernel shows the power of a modular system software framework.

Enshrined Authorization and Royalties

Radix Engine standardizes authorization and royalties by decoupling this logic from business logic and implementing these as system features. This allows users and developers to have a built-in common way of understanding the requirements to access any function on-ledger.

The modularity of decoupling business logic from system logic also allows for convenient development/debugging options like the ability to preview a transaction without the normal auth checks (want to simulate the result of sending 10 million USDC somewhere? With authorization disabled, your preview transaction can do the minting!).

Enshrining auth, and royalties require four pieces of modular software:

Enshrined Transaction

The correct interface between the user and the system is paramount for any system to be usable. To be usable, the interface must find the right balance between ease of use and power/flexibility.

In the Operating System world, the most common interface is the terminal, a user space process that gives a user a command line tool to call and compose various system calls.

In the DLT world, this interface is the transaction. The industry standard for a transaction is to use a single low-level, generic invocation call. Unfortunately, this is too simple in that it makes it hard to understand what one is actually doing when interacting with the system.

Radix Engine, on the other hand, uses the traditional OS pattern and enshrines an application language (similar to a terminal scripting language such as bash) to call and compose system calls in a single transaction.

Because the entry point of a transaction operates in the application layer, the language interpreter is implemented by adding a Transaction Processor native package.

Enshrined BLS

BLS signatures are an important crypto primitive as they allow for the possibility of threshold signatures. Unfortunately, running such logic in WASM quickly uses up the maximum cost unit. In the recent “Anemone” update, we enshrined BLS by executing it natively and found a 500x gain in performance when compared to WASM.

Because BLS logic is stateless, it can easily be added as an additional precompile to the Scrypto WASM VM.

Conclusion

What to enshrine and what not to enshrine is important for any DLT protocol. Unfortunately, the industry’s existing VM model makes every enshrinement decision a high-stakes decision.

With the Operating System model as inspiration, Radix Engine solves this problem by adding a layer of indirection between “software” and “hardware.” This allows Radix Engine to express the notion of “enshrined software” and makes it easy for the protocol to add, modify, and express new enshrined systems without making high-stakes compromise decisions.

Originally, the operating system was meant to be a small piece of software designed to manage shared resources for multiple applications. As user demands for a better, faster, more secure platform grew, it has taken on more and more responsibility with a larger and larger suite of software.

DeFi will be no different.  As demand for a faster, more secure, and more usable DeFi platform grows, increased enshrinement will follow. Radix Engine was designed with this in mind and provides the scalable and secure framework needed for expanding enshrinement into the future.