Radix Engine：一个更好的“供奉”模型

在我的上一篇文章中，我介绍了 Radix Engine 如何避免 Sui 的 MoveVM 中的一些缺陷。总结如下：

• Sui 的 MoveVM 过于低级和通用，使得 DeFi 编程环境变得繁琐。
• Radix Engine 是高层、面向资产+业务逻辑的，让开发者可以专注于 DeFi 逻辑而不是低级细节。

Sui 的 MoveVM 遵循了原来的以太坊哲学一种“干净、简单、美观”的协议，它将一切委托给应用层。这使开发人员可以自由探索任何领域，包括当时未知的领域。

然而，过于简单、非结构化的协议会带来重大问题。例如，授权等常见系统功能在应用空间中需要复杂的实现，标准接口可能变得更加碎片化，性能优化也变得更加困难。

另一方面，Radix Engine 旨在执行非通用的系统范围逻辑作为核心技术目标，因为它允许我们执行以下操作：

• 执行全系统标准/实施。一个固定的标准可以让整个堆栈的开发/维护/工具变得更加容易，因为 API 不会支离破碎（例如，ERC-20 vs. ERC-721 vs. ERC-404），而且理解行为不需要字节码解释（不再需要 ERC-20 的干扰）。这为开发人员和最终用户提供了更安全、更一致的 DeFi 体验。
• 执行更接近硬件的逻辑。由于系统逻辑不需要由解释器运行以确保正确性，因此该逻辑的执行可以尽可能接近硬件。
• 并行执行。通过掌握某些对象的行为知识，可以更轻松地在执行之前做出静态分析决策，从而实现并行执行。

Vitalik 最近谈到了这个想法，他用“入选”或者说，为了获得协议强制逻辑的好处，有选择地脱离抽象。他偷用了他的一张图片，将这个问题描述为抽象与神圣之间的权衡：

在支持抽象（即未来/多样化的用户需求）和保持性能/安全性/可用性（即固定性）之间取得平衡实际上是一个非常古老的计算机科学问题。操作系统的设计在过去几十年中一直在试图解决类似的问题：我们如何在保持快速、安全、可用的系统的同时支持一系列抽象应用程序？

在本文中，我将介绍 Radix Engine 如何使用操作系统模型来创建一个能够实现所有类型“嵌入”的框架，而不会增加协议复杂性或丧失 Vitalik 所担心的灵活性。

让我们首先来看看当前的行业标准，以太坊虚拟机（“EVM”）。

EVM 作为虚拟机

EVM 非常基础，可以将其建模为具有以下操作码的虚拟机（“VM”）：

• 图灵完备操作码集
• 调用其他智能合约的操作码
• 用于读取/写入当前智能合约拥有的持久存储的操作码

编译成 EVM 字节码的智能合约随后可以在这样的 VM 上执行。

在这个模型中，任何形式的“嵌入”都需要对 EVM 或 VM 硬件进行更改。例如，嵌入 BLS 签名支持需要添加新的预编译。实现EIP-2938需要添加新的操作码。扩展已包含的内容不可避免地会导致更大、更复杂的虚拟机，并迫使协议设计者做出 Vitalik 描述的非此即彼的决定。

这种模型的普遍问题是抽象/嵌入二分法与软件/硬件二分法过于耦合。也就是说，将任何逻辑嵌入协议都会迫使其嵌入到虚拟机中。没有办法表达“嵌入的软件”或作为系统一部分的软件。

操作系统通过“系统软件”的概念解决了这种矛盾。让我们仔细看看。

操作系统模型

操作系统的主要目标之一是管理软件/硬件二分法 - 或者更具体地说，应用程序/硬件二分法。任何操作系统的核心部分都是内核，即管理用户空间应用程序及其对硬件的访问的软件。内核模块和驱动程序是系统软件的附加部分，用于扩展支持的硬件集或扩展内核功能。

\从“嵌入”的角度来看，内核及其模块是系统的嵌入部分，但具有软件的灵活性。内核模块、虚拟机（“VM”）和用户空间系统进程甚至更加“软”，因为它们是从内核本身抽象出来的。

在这个模型中，应用程序和硬件之间的间接层可以将软件/硬件二分法与抽象/嵌入二分法分离。“系统软件”允许嵌入而不会给硬件带来过重负担。

Radix Engine 作为操作系统

受该操作系统模型的启发，Radix Engine 包含多个层，每个层都有特定的职责和抽象，从而实现系统模块化和可插入性。

这种模块化设计允许强制执行系统逻辑，同时还允许执行以下操作：

• 继承所在层的隔离属性。例如，虽然已嵌入，但嵌入的软件包无法访问任意状态，而必须遵循应用层界限。这与用户空间驱动程序或微内核设计中的安全性类似。也就是说，通过隔离系统的每个部分来降低风险，这样系统中的任何更新（嵌入）都不会使整个系统面临风险。
• 访问其所在层的功能。例如，被奉为神圣的包可以继承系统提供的身份验证和/或可升级性功能。
• 解耦治理。这种模块化设计允许每个模块中的创新并行且以不同的速度进行。

现在让我们逐一介绍各个层，看看它们的职责是什么。

应用层

应用层负责定义高级逻辑。描述此逻辑的字节码以及其他静态信息被打包成可执行格式，称为“包”。然后，包存储在账本上并可供执行。

使用 Scrypto（一种基于 Rust 的语言，我们为 DeFi 开发而构建）编写的应用程序位于此层。Scrypto 程序被编译成 WASM 程序，可以访问一组函数导出，这些函数导出允许程序访问系统/内核服务。这系统调用API类似于Linux系统调用，提供对共享 I/O 的访问。

虚拟机层

进入下一层，VM 层负责为应用层提供计算环境。这包括图灵完备的 VM 以及访问系统层的接口。

Radix Engine 当前支持两个 VM：用于执行 Scrypto 应用程序的 Scrypto WASM VM 和执行编译到主机环境的本机包的本机 VM。

如果我们具体看一下 Scrypto WASM VM，它看起来像这样：

这看起来与 EVM 模型基本相同，但有两个关键的区别：

• 删除对存储的直接访问。每个智能合约不再只能访问其拥有的存储，而是通过系统调用来读取/写入任何状态。这一间接层允许在系统中实现许多有趣的事情，例如跨应用程序的状态共享、状态虚拟化等。这一间接层类似于虚拟内存或 Linux 的文件描述符。

  
  

• 增加系统调用。系统调用是应用层访问系统层服务的机制，例如调用其他应用程序或将数据写入对象。这些系统调用类似于真实 CPU 中的软件中断指令（例如智力x86 中的指令）。

系统层

系统层负责维护一组系统模块或可插入软件，以扩展系统的功能。这些类似于 Linux 的内核模块。

每次系统调用时，系统层都会在将控制权移交给内核层之前调用每个系统模块。调用时，每个系统模块可能会更新某些特定状态（例如，更新已花费的费用）或恐慌以结束交易（例如，如果类型检查器失败）。

该模式允许系统实现授权、版税或类型检查等功能，同时与应用程序层和内核层分离。

内核层

内核层负责 Radix Engine 的两个核心功能：存储访问和应用程序之间的通信。这有点类似于传统操作系统对磁盘和网络访问的职责。

对于 Radix Engine，这包括以下低级管理：

• 检查是否在任何调用或数据写入时维护了移动/借用语义。单一所有者规则和借用规则由内核强制执行。如果任何这些规则失败，事务将崩溃。
• 管理瞬时对象与持久对象。对象可能在任何时间点位于全局空间中，也可能由调用框架拥有。在运行时，内核会在传递对这些对象的引用时维护指向这些对象的正确指针。
• 管理事务状态更新。内核跟踪事务期间发生的状态更新，这些更新随后将在事务结束时提交给数据库。

神圣的软件

这些层与 DLT 协议中的“奉为圭臬”有何关系？与操作系统中的内核层类似，Radix Engine 的这些中间层提供了将抽象/奉为圭臬的二分法与软件/硬件的二分法分离所需的间接性，并创建了“奉为圭臬的软件”的概念。

神圣的软件具有软件的灵活性和安全性，同时保持了执行系统范围逻辑的能力。

让我们看一下目前在 Radix 网络上运行的几个入驻示例，看看它们是如何实现的。

珍藏资源

Radix DeFi/Web3 平台的核心差异化在于，资源（即资产）是一种基本原语，应与业务逻辑分开理解。秉承这一概念可让所有 dApp、钱包和工具对资产的界面和行为有共同的理解，从而使可组合性变得更加容易。

虽然资源是系统中最根深蒂固的部分之一，但实现它的实现只需要两个模块化软件：

• 处理 Buckets、Vaults 和 Proofs 等资源对象逻辑的原生包

• 强制这些对象的生命周期不变量（例如资源的可移动性和可燃性）的系统模块

  
  

Radix Engine 能够从系统/内核中抽象出标准化、可移动资源的深层概念，体现了模块化系统软件框架的强大功能。

授权和特许权使用费

Radix Engine 通过将授权和版税逻辑与业务逻辑分离并将其作为系统功能实现，实现了授权和版税的标准化。这样一来，用户和开发人员就能够通过内置的通用方法来了解访问账本上任何功能的要求。

将业务逻辑与系统逻辑分离的模块化还允许方便的开发/调试选项，例如无需正常的身份验证检查即可预览交易（想要模拟向某个地方发送 1000 万 USDC 的结果？禁用授权后，您的预览交易就可以进行铸造！）。

确保授权和版税需要四个模块化软件：

• Auth 和 Royalties 本机包允许应用层访问任何对象的 auth/royalties（例如，检索 auth 规则以访问方法或索取版税）。

• 在对象方法调用之前，将调用 Auth 和 Royalties 系统模块来验证调用者是否有足够的授权进行调用并收取版税。

  
  

  
  

已确认的交易

用户和系统之间的正确界面对于任何系统的可用性来说都是至关重要的。为了可用性，界面必须在易用性和功能/灵活性之间找到适当的平衡。

在操作系统世界中，最常见的界面是终端，它是一个用户空间进程，为用户提供命令行工具来调用和组成各种系统调用。

在 DLT 世界中，这个接口就是交易。交易的行业标准是使用单个低级通用调用。不幸的是，这太简单了，以至于很难理解与系统交互时实际在做什么。

另一方面，Radix Engine 使用传统的操作系统模式，并包含一种应用程序语言（类似于 bash 等终端脚本语言）来在单个事务中调用和组成系统调用。

由于事务的入口点在应用层运行，因此语言解释器是通过添加事务处理器本机包来实现的。

神圣的 BLS

BLS 签名是一种重要的加密原语，因为它们允许阈值签名的可能性。不幸的是，在 WASM 中运行这种逻辑很快就会用尽最大成本单位。在最近的“Anemone”更新中，我们通过本地执行 BLS 来将其纳入其中，与 WASM 相比，性能提高了 500 倍。

由于 BLS 逻辑是无状态的，因此可以轻松地将其作为附加预编译添加到 Scrypto WASM VM 中。

结论

对于任何 DLT 协议来说，什么该保留、什么不该保留都很重要。不幸的是，行业现有的 VM 模型让每个保留决定都成为高风险的决定。

受操作系统模型的启发，Radix Engine 通过在“软件”和“硬件”之间添加一个间接层来解决此问题。这使得 Radix Engine 能够表达“固有软件”的概念，并使协议能够轻松添加、修改和表达新的固有系统，而无需做出高风险的妥协决策。

最初，操作系统只是一小段软件，用于管理多个应用程序的共享资源。随着用户对更好、更快、更安全的平台的需求不断增长，操作系统也承担了越来越多的责任，其软件套件也越来越庞大。

DeFi 也不例外。随着对更快、更安全、更易用的 DeFi 平台的需求不断增长，入驻数量也将随之增加。Radix Engine 的设计考虑到了这一点，并提供了未来扩展入驻所需的可扩展且安全的框架。