当《毁灭战士》的音乐响起

返回

是的，你可以在 ZK 中运行 DOOM：

唯一重要的基准

自计算机科学诞生以来，该领域一直在寻找更好地理解计算机系统能力的工具。从 Ada Lovelace 的早期工作到 Alanzo Church 和 Alan Turing 的数学框架，早期的先驱们都在寻找方法来描述这些令人兴奋的新机器。

几十年来，这个问题一直悬而未决，让理论家和实践者都感到沮丧。幸运的是，随着 id Software 在 1993 年发布 DOS 版的 DOOM，所有这些都发生了改变，这不仅开启了视频游戏的“第一人称射击”类型，而且还提供了第一个相关的、实用的和可理解的计算机性能衡量标准。

因此，现代专家通常将计算机系统分为两类：可以运行 DOOM 的系统，以及不能运行的系统，这不足为奇。

‍

高斯比例的突破

今天，我们很高兴地宣布，RISC Zero 的 zkVM 已经加入了可以运行 DOOM 的系统行列。你可以在此处查看源代码。

以下是它的工作原理：用户在 zkVM 中运行我们的 DOOM 端口，并提供一个“demo”文件（他们的游戏输入的记录）作为输入。然后，DOOM 重放 demo 文件，并在这样做时，将游戏中的图形渲染到 zkVM 的 journal（一个经过加密签名和可验证的输出日志），然后可以将其显示在屏幕上。上面显示的 GIF 是通过捕获这些帧生成的。

因为 DOOM 运行在 zkVM 中，所以我们获得了一个 ZK 证明，证明 journal 中包含的帧确实来自 DOOM。而且因为它是一个 零知识 证明，所以关于 demo 文件的任何信息都不会被泄露（除了可以在屏幕上看到的信息之外）。

‍

一个有趣、简单的项目

最初的 DOOM 是为 DOS 编写的，这是一个用于 IBM PC 兼容系统的古老操作系统。那么我们是如何让它在 zkVM 中运行的呢？

• DOOM* 是开源的，因此可以首先获取代码并将其编译为 RISC-V（zkVM 使用的处理器核心）。不幸的是，这种方法并不奏效：源代码编译得很好，但在运行时，事情就崩溃了。那么问题出在哪里呢？

问题在于 DOOM 被编写成在运行传统操作系统的传统计算机上运行。虽然可以在 ZK 中启动传统操作系统，但我们认为这样做对于这个项目来说有点矫枉过正。毕竟，没有人真正关心 DOOM 作为在操作系统中运行的进程的行为；人们真正关心的是游戏逻辑本身。

幸运的是，the PureDOOM project 项目 正好提供了这一点。PureDOOM 可以被认为是 DOOM 没有操作系统集成。它的工作原理是用一个小的、易于支持的抽象层替换 libc 依赖项。要在 zkVM 中运行，我们所要做的就是提供这些抽象的实现。

因为 PureDOOM 是用 C 语言编写的，所以我们首先使用 Bindgen（一个生成 Rust FFI 绑定的工具）用 Rust 绑定包装 C 接口。在编译时，我们使用 clang 构建 C 代码，因为它可以交叉编译到 riscv32im（zkVM 使用的 CPU 核心）。这涉及到对 PureDOOM 进行一些修补，使其与 RISC-V 兼容。这些补丁是次要的，并且涉及 C 语言的特性，例如 char 默认是有符号还是无符号；有关更多详细信息，请参见 zkDOOM 源代码 中的 puredoom-rs/build.rs。

一旦我们能够构建我们的代码，我们就开始为 PureDOOM 实现系统接口。该接口的大部分内容都很容易用 Rust 实现，只需连接到 zkVM 的相应接口（例如 print、exit 等），但有两个例外：文件系统和时间。

对于文件系统，我们实现了一个基本的 HashMap 支持的内存模拟。这允许我们将 WAD 文件包含在 guest 镜像本身中，这为我们带来了两个不错的功能：

1. 我们不必通过输入来读取它，这节省了我们一些执行周期。

2. 嵌入 WAD 意味着 guest 的 ImageId 直接与特定的 WAD 相关联，这对于竞技游戏很有用。

最终的挑战是 gettime() 接口。在 zkVM 中，默认情况下没有时间概念（一般来说，没有办法以加密方式 证明 现在是什么时间）。为了解决这个问题，我们选择模拟一个计时器，这将允许游戏逻辑按预期工作。我们采用的方法是每次 doom_update() 调用运行时，都会递增一个全局计数器，并且为了获得视觉上清晰的帧输出以进行可视化，我们为每次更新选择了 100000 微秒。这个简单的技巧似乎奏效了。

总而言之，这个项目花了一天左右的时间，包括和狗玩耍的休息时间。

‍

性能

当然，如果没有一些令人兴奋的性能，一个令人兴奋的 ZK 项目就不会完整。我们首先查看玩 DOOM 所需的计算量（以时钟周期衡量）：

• 初始化周期：50,560,806

• 每个游戏 tick 的周期（不渲染）：37,519

• 每个游戏 tick 的周期（渲染）：2,438,613

• 包含的演示的总周期（不渲染）：119,537,664

• 包含的演示的总周期（渲染）：7,809,794,048

不出所料，DOOM 不需要太多的计算。有趣的是，当启用渲染时，工作负载似乎与构建一个以太坊区块所需的计算量相当，而我们已经在 zkVM 中做了很长时间了！

现在我们对规模有了一定的了解，让我们来看看生成证明所需的工作。为此，我们利用了 Bonsai，它使我们能够访问在 AWS 中运行的 250 个 g4dn.xlarge 实例。

‍

我们进行了两个测试：一个启用了渲染，一个没有启用渲染。

基于这些数据，我们可以得出一些观察结果：

• 当禁用渲染时，可以相当快地完成证明。即使 zkVM 的有效运行速度为 1 MHz，游戏引擎仍然能够执行每秒 30 个游戏 ticks，几乎与 DOOM 最初的每秒 35 个 ticks 一样快。

• 当启用渲染时，工作负载增加了 65 倍，但证明时间仅增加了 19 倍。这是一个 并行证明 强大功能的优雅示例：渲染需要更多的工作来证明，但这项工作可以并行完成，这意味着完成工作所需的时间可以很好地扩展。这反映在 有效时钟速度 上，渲染测试的有效时钟速度远高于非渲染测试。

‍

使用 ZK 进行速通

在 ZK 中运行流行游戏的能力为 速通 创造了新的机会：使用 secret 的工具辅助速通，或简称 TASS*。*

与其他 工具辅助 类别一样，允许玩家使用工具来制作他们的 demo 文件；但与其他类别不同，玩家 无需 披露这些 demo 文件的内容。相反，通过提交 ZK 证明来验证记录，证明确实获得了该记录。由于使用 ZK 证明来验证记录，因此排行榜可以由智能合约管理，从而无需人工裁判委员会。

我们的工作到此为止，但也许一些有进取心的黑客会认为让它成为现实是合适的……

‍

这对世界意味著什么

在 zkVM 中运行 DOOM 的能力是 一个广为人知的问题，具有巨大的意义。当我们开始 RISC Zero 时，我们敢于梦想有一天会成为可能。回顾过去，这个目标需要几年的 ZK 研发和大约 1 天的 DOOM 编码。

我们在 Zeth 中看到了它，我们在 DOOM 中再次看到了它：如果你有远大的 ZK 目标，请查看 RISC Zero zkVM，看看它能为你做什么。

• 原文链接： risczero.com/blog/when-t...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～