Vitalik：提升效率和安全性的新构想——胶合和协处理器架构

原标标题：《Glue and coprocessor architectures》

原文作者：Vitalik Buterin，以太坊创始人

原文编译：邓通，金色财经

特别感谢 Justin Drake、Georgios Konstantopoulos、Andrej Karpathy、Michael Gao、Tarun Chitra 和各种 Flashbots 贡献者提供的反馈和评论。

如果你以中等程度的细节分析现代世界中正在进行的任何资源密集型计算，你会一次又一次发现的一个特点是，计算可以分为两个部分：

• 相对少量的复杂但计算量不大的「业务逻辑」；
• 大量密集但高度结构化的「昂贵工作」。

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

实践中这种不同方式的例子有哪些？

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

• 基本成本：21,000
• 调用数据：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 代码。

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

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

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

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

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

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

总体来说，现象是怎样的？

现代计算越来越多地遵循我所说的粘合和协处理器架构：你有一些中央「粘合」组件，它具有高通用性但效率低，负责在一个或多个协处理器组件之间传送数据，这些协处理器组件具有低通用性但效率高。

这是一种简化：在实践中，效率和通用性之间的权衡曲线几乎总是有两个以上的层次。GPU 和其他在行业中通常被称为「协处理器」的芯片不如 CPU 通用，但比 ASIC 通用。专业化程度的权衡很复杂，这取决于对算法的哪些部分在五年后仍将保持不变，哪些部分在六个月后会发生变化的预测和直觉。在 ZK 证明架构中，我们经常看到类似的多层专业化。但对于广泛的思维模型，考虑两个层次就足够了。在许多计算领域都有类似的情况：

从上述例子来看，计算当然可以以这种方式分割，这似乎是一种自然法则。事实上，你可以找到几十年来计算专业化的例子。然而，我认为这种分离正在增加。我认为这是有原因的：

我们最近才达到 CPU 时钟速度提升的极限，因此只有通过并行化才能获得进一步的收益。但是，并行化很难推理，因此对于开发人员来说，继续按顺序推理并让并行化在后端发生往往更为实际，并包装在为特定操作构建的专用模块中。

计算速度最近才变得如此之快，以至于业务逻辑的计算成本已经变得真正可以忽略不计。在这个世界中，优化业务逻辑运行的 VM 以达到计算效率以外的目标也是有意义的：开发人员友好性、熟悉性、安全性和其他类似目标。同时，专用的「协处理器」模块可以继续为效率而设计，并从它们与粘合剂的相对简单的「接口」中获得其安全性和开发人员友好性。

最重要的昂贵操作是什么变得越来越清晰。这在密码学中最为明显，其中最有可能使用哪些类型的特定昂贵操作：模数运算、椭圆曲线线性组合（又称多标量乘法）、快速傅里叶变换等等。在人工智能中，这种情况也变得越来越明显，二十多年来，大部分计算都是「主要是矩阵乘法」（尽管精度水平不同）。其他领域也出现了类似的趋势。与 20 年前相比，（计算密集型）计算中的未知未知数要少得多。

这意味着什么？

一个关键点是，胶合器（Glue）应优化以成为好的胶合器（Glue），而协处理器（coprocessor）也应优化以成为好的协处理器（coprocessor）。我们可以在几个关键领域探索这一点的含义。

EVM

区块链虚拟机（例如 EVM）不需要高效，只需要熟悉即可。只需添加正确的协处理器（又称「预编译」），低效 VM 中的计算实际上可以与本机高效 VM 中的计算一样高效。例如，EVM 的 256 位寄存器所产生的开销相对较小，而 EVM 的熟悉度和现有开发者生态系统带来的好处是巨大且持久的。优化 EVM 的开发团队甚至发现，缺乏并行化通常不是可扩展性的主要障碍。

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

安全计算和开放硬件

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

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

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

RISC-V 等较新的开源芯片设计不可能与已经存在并经过数十年改进的处理器技术相媲美。进步总有一个起点。

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

密码学

另一个关键点是，这一切都对密码学，尤其是可编程密码学成为主流非常乐观。我们已经在 SNARK、MPC 和其他设置中看到了一些特定的高度结构化计算的超优化实现：某些哈希函数的开销仅比直接运行计算贵几百倍，而且人工智能（主要是矩阵乘法）的开销也非常低。GKR 等进一步的改进可能会进一步降低这一水平。完全通用的 VM 执行，特别是在 RISC-V 解释器中执行时，可能会继续产生大约一万倍的开销，但出于本文中描述的原因，这并不重要：只要使用高效的专用技术分别处理计算中最密集的部分，总开销就是可控的。

「胶合层只需要熟悉，不需要高效」这一想法的一个例外是延迟，以及在较小程度上的数据带宽。如果计算涉及对同一数据进行数十次重复的繁重操作（就像密码学和人工智能一样），那么由低效胶合层导致的任何延迟都可能成为运行时间的主要瓶颈。因此，胶合层也有效率要求，尽管这些要求更为具体。

结论

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

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

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