Vitalik: 胶水和协处理器架构

特别感谢 Justin Drake、Georgios Konstantopoulos、Andrej Karpathy、Michael Gao、Tarun Chitra 以及各位 Flashbots 贡献者的反馈和审查。

如果你对现代世界中任何资源密集型计算进行中等程度的详细分析，你会发现一个反复出现的特征是，计算可以分为两部分：

1. 相对较少的复杂但计算强度不大的“业务逻辑”
2. 大量密集但高度结构化的“昂贵工作”

这两种形式的计算最好以不同的方式处理：前者需要一种可能效率较低但需要具有高度通用性的架构，而后者需要一种可能通用性较低但需要具有高度效率的架构。

这种分离在实践中的一些例子是什么？

首先，让我们看看我最熟悉的环境：以太坊虚拟机 (EVM)。 这是我最近进行的一笔以太坊交易的 geth 调试跟踪 ：更新我在 ENS 上的博客的 IPFS 哈希。交易总共消耗了 46924 gas，可以这样分类：

• 基础费用：21,000
• Calldata：1,556
• EVM 执行：24,368
  • SLOAD 操作码：6,400
  • SSTORE 操作码：10,100
  • LOG 操作码：2,149
  • 其他：6,719

故事的寓意是：大部分执行（如果仅看 EVM，大约 73%，如果包括覆盖计算的基础费用部分，则约 85%）集中在非常少量的结构化昂贵操作中：存储读写、日志和加密（基础费用包括 3000 用于支付签名验证，EVM 还包括 272 用于支付哈希）。其余的执行是“业务逻辑”：处理 calldata 的位以提取我试图设置的记录 ID 和我设置的哈希等。在代币转移中，这将包括添加和减去余额，在更高级的应用程序中，这可能包括一个循环，等等。

在 EVM 中，这两种形式的执行以不同的方式处理。高级业务逻辑用高级语言编写，通常是 Solidity，编译成 EVM。昂贵的工作仍然由 EVM 操作码（SLOAD 等）触发，但实际计算的 99% 以上是在客户端代码（甚至库）中直接编写的专用模块中完成的。

为了加强我们对这种模式的理解，让我们在另一个上下文中探索它：使用 torch 用 python 编写的 AI 代码。

一个 transformer 模型块的 forward， 来源 。

我们在这里看到了什么？我们看到了一小部分用 python 编写的“业务逻辑”，描述了正在执行的操作的结构。在实际应用中，还会有另一种业务逻辑，决定如何获取输入以及对输出做什么。但是，如果我们窥视每个单独的操作（self.norm、torch.cat、+、*、self.attn 内的各种步骤...），我们会看到向量化计算：在大量值上并行计算相同的操作。与第一个例子类似，一小部分计算用于业务逻辑，而大部分计算用于执行大型结构化矩阵和向量操作——事实上，大多数只是矩阵乘法。

就像在 EVM 示例中一样，这两种工作以两种不同的方式处理。高级业务逻辑代码用 Python 编写，这是一种高度通用且灵活的语言，但也非常慢，我们只是接受这种低效，因为它只涉及总计算成本的一小部分。同时，密集操作用高度优化的代码编写，通常是运行在 GPU 上的 CUDA 代码。越来越多地，我们甚至开始看到 LLM 推理在 ASIC 上完成 。

现代可编程加密 ，如 SNARKs，再次遵循类似的模式，在两个层面上。首先，证明者可以用高级语言编写，其中繁重的工作通过向量化操作完成，就像上面的 AI 示例一样。我的circle STARK 代码展示了这一点。其次，正在加密内部执行的程序本身可以以一种在通用业务逻辑和高度结构化昂贵工作之间分割的方式编写。

要了解这是如何工作的，我们可以看看 STARK 证明的最新趋势之一。为了通用和易用，团队越来越多地为广泛采用的最小虚拟机（如 RISC-V）构建 STARK Prover(证明者)。任何需要证明其执行的程序都可以编译成 RISC-V，然后证明者可以证明该代码的 RISC-V 执行。

来自 RiscZero 文档的图表

这非常方便：这意味着我们只需要编写一次证明者逻辑，从那时起，任何需要证明的程序都可以用任何“常规”编程语言编写（例如 RiskZero 支持 Rust）。然而，有一个问题：这种方法会产生显著的开销。可编程加密已经非常昂贵；在 RISC-V 解释器中运行代码的开销太大。因此，开发人员想出了一个技巧：识别构成大部分计算的特定昂贵操作（通常是哈希和签名），并创建专用模块以极高效地证明这些操作。然后你只需将低效但通用的 RISC-V 证明系统和高效但专用的证明系统结合起来，你就能获得两全其美的效果。

除了 ZK-SNARKs 之外的可编程加密，如多方计算 (MPC) 和全同态加密 (FHE)可能会使用类似的方法进行优化。

一般模式是什么？

现代计算越来越遵循我称之为胶水和协处理器架构：你有一些中央“胶水”组件，具有高通用性但低效率，负责在一个或多个协处理器组件之间传输数据，这些组件具有低通用性但高效率。

这是一种简化：实际上，在效率和通用性之间的权衡曲线上几乎总是有超过两个层次。GPU 和其他在工业中通常被称为“协处理器”的芯片，比 CPU 更不通用，但比 ASIC 更通用。关于专门化到什么程度的权衡是复杂的，这些决定基于对算法哪些部分在五年内仍然相同，哪些部分在六个月内会改变的预测和直觉。在 ZK 证明架构中，我们通常也会看到多层次的专门化。但对于一个广泛的思维模型，考虑两个层次就足够了。在许多计算领域中都有类似的情况：

从上述例子中，可能会觉得计算当然可以以这种方式分割是一种自然法则。确实，你可以找到几十年来计算中专门化的例子。然而，我认为这种分离正在增加。我认为这有几个关键原因：

1. 我们直到最近才达到了提高 CPU 时钟速度的极限，因此进一步的增益只能来自并行化。然而，并行化很难推理，因此开发人员通常更实际的是继续顺序推理，并让并行化在后台发生，包装在为特定操作构建的专用模块中。
2. 计算直到最近才变得如此之快，以至于业务逻辑的计算成本变得真正可以忽略不计。在这个世界中，优化业务逻辑运行的 VM 以实现计算效率以外的目标是有意义的：开发者友好性、熟悉度、安全性和其他类似目标。同时，专用的“协处理器”模块可以继续为效率而设计，并从它们与粘合剂的相对简单的“接口”中获得安全性和开发者友好性属性。
3. 最重要的昂贵操作变得更加清晰。这在密码学中最为明显，因为很清楚哪种特定的昂贵操作最有可能被使用：模运算、椭圆曲线线性组合 （也称为多标量乘法）、快速傅里叶变换等。在 AI 中也变得更加清晰，过去二十多年中，大部分计算“主要是矩阵乘法”（尽管有不同的精度水平）。在其他领域也出现了类似的趋势。在（计算密集型）计算中，未知的未知数比 20 年前少得多。

这意味着什么？

一个关键的结论是粘合剂应该优化为好的粘合剂，协处理器应该优化为好的协处理器。我们可以在几个关键领域探索这一点的含义。

EVM

区块链虚拟机（例如 EVM）不需要高效，它们只需要熟悉。在低效 VM 中的计算可以通过添加合适的协处理器（即“预编译”）在实践中变得几乎与在本地高效 VM 中的计算一样高效。比如 EVM 的 256 位寄存器所带来的开销相对较小，而 EVM 的熟悉度和现有开发者生态系统所带来的好处则是巨大的和持久的。优化 EVM 的开发团队甚至发现缺乏并行化通常不是可扩展性的主要障碍。

改进 EVM 的最佳方法可能只是（i）添加更好的预编译或专用操作码，例如某种组合的 EVM-MAX 和SIMD可能是合理的，以及（ii）改进存储布局，例如 Verkle 树更改通过大大降低访问彼此相邻的存储槽的成本作为副作用来实现。

以太坊 Verkle 树提案中的存储优化，将相邻的存储键放在一起并调整 gas 成本以反映这一点。像这样的优化，加上更好的预编译，可能比调整 EVM 本身更重要。

安全计算和开放硬件

在硬件层面提高现代计算安全性的一个大挑战是其过于复杂和专有的性质：芯片被设计得高度高效，这需要专有的优化。后门很容易隐藏， 侧信道漏洞不断被发现。

从多个角度继续努力推动更开放和更安全的替代方案。一些计算越来越多地在可信执行环境中进行，包括在用户的手机上，这已经提高了用户的安全性。推动更开放源码的消费硬件继续进行，最近的胜利如运行 Ubuntu 的 RISC-V 笔记本电脑 。

运行 Debian 的 RISC-V 笔记本， 来源 _

然而，效率仍然是一个问题。上述文章的作者写道：

对于像 RISC-V 这样较新的开源芯片设计来说，与已经存在并经过几十年优化的处理器技术正面交锋是不现实的。 好在有一个起点。

更偏执的想法，如这个在 FPGA 上构建 RISC-V 计算机的设计 ，面临更大的开销。但如果粘合剂和协处理器架构意味着这种开销实际上并不重要呢？如果我们接受开放和安全的芯片将比专有芯片更慢，如果需要甚至放弃常见的优化如推测执行和分支预测，但试图通过添加（如果需要，专有的）ASIC 模块来补偿这种情况，用于最密集的计算类型呢？敏感的计算可以在“主芯片”中进行，该芯片将优化为安全、开源设计和侧信道抗性。更密集的计算（例如 ZK 证明、AI）将在 ASIC 模块中进行，这些模块将了解更少的信息（可能通过密码盲化，在某些情况下甚至是零信息）关于正在执行的计算。

密码学

另一个关键的结论是，这对密码学，特别是可编程密码学走向主流非常乐观。我们已经在 SNARK、MPC 和其他设置中看到了某些特定高度结构化计算的超优化实现：对于某些哈希函数的开销仅比直接运行计算贵几百倍，而对于 AI（主要是矩阵乘法）的极低开销也是可能的 。进一步的改进如 GKR 可能会进一步减少这种开销。完全通用的 VM 执行，特别是如果在 RISC-V 解释器中执行，可能会继续有类似万倍的开销，但由于本文中描述的原因，这并不重要：只要计算中最密集的部分使用高效的专用技术单独处理，总的开销将是可控的。

一个专用 MPC 用于矩阵乘法的简化图，这是 AI 模型推理中的最大组件。有关更多详细信息，包括如何保持模型和输入的私密性，请参阅这篇论文 。

“胶水只需要熟悉，不需要高效”这一观点的一个例外是延迟，以及在较小程度上的数据带宽。如果一个计算涉及对相同数据进行数十次重复的重操作（如加密和 AI 都需要），任何由于低效的胶水层导致的延迟都可能成为运行时间的主要瓶颈。因此，胶水也有效率要求，尽管它们是更具体的。

结论

总体而言，我认为上述趋势从多个角度来看都是非常积极的发展。首先，这是在保持开发者友好性的同时最大化计算效率的逻辑方式，能够同时获得两者的更多好处对每个人都有利。特别是，通过在客户端上实现更多的专业化效率提升，它提高了我们在用户硬件上本地运行既敏感又对性能要求高的计算（例如 ZK 证明、LLM 推理）的能力。其次，它创造了一个巨大的机会窗口，以确保对效率的追求不会损害其他价值，尤其是安全性、开放性和简洁性：计算机硬件中的侧信道安全性和开放性，减少 ZK-SNARKs 中的电路复杂性，以及减少虚拟机中的复杂性。从历史上看，对效率的追求往往使这些其他因素退居次要地位。通过胶水和协处理器架构，不再需要这样。机器的一部分优化效率，另一部分优化通用性和其他价值，两者协同工作。

这一趋势对加密学也非常有利，因为加密学本身就是“昂贵的结构化计算”的一个主要例子，这一趋势加速了它的发展。这进一步增加了提高安全性的机会。在区块链的世界中，安全性的提高也变得可能：我们可以减少对优化虚拟机的担忧，而更多地关注优化预编译和其他与虚拟机共存的特性。

第三，这一趋势为较小和较新的参与者提供了机会。如果计算变得不那么单一，而更加模块化，这将大大降低进入门槛。即使是针对一种计算类型的 ASIC，也有可能产生影响。这在 ZK 证明领域和 EVM 优化中同样适用。编写具有接近前沿效率的代码变得更加容易和可访问。审计和形式验证这样的代码也变得更加容易和可访问。最后，由于这些非常不同的计算领域正在趋同于一些共同的模式，它们之间有更多的合作和学习空间。