原标题:Glueandcoprocessorarchitectures
作者:Vitalik,Ethereum创始人;编译:邓通,金色财经
特别感谢JustinDrake、GeorgiosKonstantopoulos、AndrejKarpathy、MichaelGao、TarunChitra和各种Flashbots贡献者提供的反馈和评论。
如果你以中等程度的细节分析现代世界中正在进行的任何资源密集型计算,你会一次又一次发现的一个特点是,计算可以分为两个部分:
相对少量的复杂但计算量不大的“业务逻辑”;
大量密集但高度结构化的“昂贵工作”。
这两种计算形式最好用不同的方式处理:前者,其架构可能效率较低但需要具有非常高的通用性;后者,其架构可能具有较低的通用性,但需要具有非常高的效率。实践中这种不同方式的例子有哪些?
首先,让我们了解一下我最熟悉的环境:Ethereum虚拟机(EVM)。这是我最近进行的Ethereum交易的geth调试跟踪:在ENS上更新我的博客的IPFS哈希。该交易总共消耗了46924gas,可以按以下方式分类:
基本成本:21,000
调用数据:1,556
EVM执行:24,368
SLOAD操作码:6,400
SSTORE操作码:10,100
LOG操作码:2,149
其他:6,719
变压器模型的一个块的前向传递
我们在这里看到了什么?我们看到了用Python编写的相对少量的“业务逻辑”,它描述了正在执行的操作的结构。在实际应用中,还会有另一种类型的业务逻辑,它决定了诸如如何获取输入以及对输出执行的操作等细节。但是,如果我们深入研究每个单独的操作本身(self.norm、torch.cat、+、*、self.attn内部的各个步骤……),我们会看到矢量化计算:相同的操作并行计算大量值。与第一个示例类似,一小部分计算用于业务逻辑,大部分计算用于执行大型结构化矩阵和向量运算——事实上,大多数只是矩阵乘法。
就像在EVM示例中一样,这两种类型的工作以两种不同的方式处理。高级业务逻辑代码是用Python编写的,这是一种高度通用和灵活的语言,但也非常慢,我们只是接受低效率,因为它只涉及总计算成本的一小部分。同时,密集型操作是用高度优化的代码编写的,通常是在GPU上运行的CUDA代码。我们甚至越来越多地开始看到LLM推理在ASIC上进行。
现代可编程密码学,如SNARK,在两个层面上再次遵循类似的模式。首先,证明器可以用高级语言编写,其中繁重的工作是通过矢量化操作完成的,就像上面的AI示例一样。我在这里的圆形STARK代码展示了这一点。其次,在密码学内部执行的程序本身可以以一种在通用业务逻辑和高度结构化的昂贵工作之间进行划分的方式编写。
要了解其工作原理,我们可以看看STARK证明的最新趋势之一。为了通用且易于使用,团队越来越多地为广泛采用的最小虚拟机(如RISC-V)构建STARK证明器。任何需要证明执行情况的程序都可以编译成RISC-V,然后证明者可以证明该代码的RISC-V执行情况。
这是一种简化:在实践中,效率和通用性之间的权衡曲线几乎总是有两个以上的层次。GPU和其他在行业中通常被称为“协处理器”的芯片不如CPU通用,但比ASIC通用。专业化程度的权衡很复杂,这取决于对算法的哪些部分在五年后仍将保持不变,哪些部分在六个月后会发生变化的预测和直觉。在ZK证明架构中,我们经常看到类似的多层专业化。但对于广泛的思维模型,考虑两个层次就足够了。在许多计算领域都有类似的情况:
从上述例子来看,计算当然可以以这种方式分割,这似乎是一种自然法则。事实上,你可以找到几十年来计算专业化的例子。然而,我认为这种分离正在增加。我认为这是有原因的:
我们最近才达到CPU时钟速度提升的极限,因此只有通过并行化才能获得进一步的收益。但是,并行化很难推理,因此对于开发人员来说,继续按顺序推理并让并行化在后端发生往往更为实际,并包装在为特定操作构建的专用模块中。
计算速度最近才变得如此之快,以至于业务逻辑的计算成本已经变得真正可以忽略不计。在这个世界中,优化业务逻辑运行的VM以达到计算效率以外的目标也是有意义的:开发人员友好性、熟悉性、安全性和其他类似目标。同时,专用的“协处理器”模块可以继续为效率而设计,并从它们与粘合剂的相对简单的“接口”中获得其安全性和开发人员友好性。
最重要的昂贵操作是什么变得越来越清晰。这在密码学中最为明显,其中最有可能使用哪些类型的特定昂贵操作:模数运算、椭圆曲线线性组合(又称多标量乘法)、快速傅里叶变换等等。在人工智能中,这种情况也变得越来越明显,二十多年来,大部分计算都是“主要是矩阵乘法”(尽管精度水平不同)。其他领域也出现了类似的趋势。与20年前相比,(计算密集型)计算中的未知未知数要少得多。
一个关键点是,胶合器(Glue)应优化以成为好的胶合器(Glue),而协处理器(coprocessor)也应优化以成为好的协处理器(coprocessor)。我们可以在几个关键领域探索这一点的含义。EVM
Blockchain虚拟机(例如EVM)不需要高效,只需要熟悉即可。只需添加正确的协处理器(又称“预编译”),低效VM中的计算实际上可以与本机高效VM中的计算一样高效。例如,EVM的256位寄存器所产生的开销相对较小,而EVM的熟悉度和现有开发者生态系统带来的好处是巨大且持久的。优化EVM的开发团队甚至发现,缺乏并行化通常不是可扩展性的主要障碍。
改进EVM的最佳方法可能只是(i)添加更好的预编译或专用操作码,例如EVM-MAX和SIMD的某种组合可能是合理的,以及(ii)改进存储布局,例如,Verkle树的更改作为副作用,大大降低了访问彼此相邻的存储槽的成本。
运行Debian的RISC-V笔记本电脑
然而,效率仍然是一个问题。上述链接文章的作者写道:
RISC-V等较新的开源芯片设计不可能与已经存在并经过数十年改进的处理器技术相媲美。进步总有一个起点。
更偏执的想法,比如这种在FPGA上构建RISC-V计算机的设计,面临着更大的开销。但是,如果胶合和协处理器架构意味着这种开销实际上并不重要,那会怎样?如果我们接受开放和安全芯片将比专有芯片慢,如果需要甚至放弃推测执行和分支预测等常见优化,但试图通过添加(如果需要,专有)ASIC模块来弥补这一点,这些模块用于最密集的特定类型的计算,那会怎样?敏感计算可以在“主芯片”中完成,该芯片将针对安全性、开源设计和侧信道阻力进行优化。更密集的计算(例如ZK证明、AI)将在ASIC模块中完成,这将了解有关正在执行的计算的更少信息(可能,通过加密盲化,在某些情况下甚至可能为零信息)。密码学
另一个关键点是,这一切都对密码学,尤其是可编程密码学成为主流非常乐观。我们已经在SNARK、MPC和其他设置中看到了一些特定的高度结构化计算的超优化实现:某些哈希函数的开销仅比直接运行计算贵几百倍,而且人工智能(主要是矩阵乘法)的开销也非常低。GKR等进一步的改进可能会进一步降低这一水平。完全通用的VM执行,特别是在RISC-V解释器中执行时,可能会继续产生大约一万倍的开销,但出于本文中描述的原因,这并不重要:只要使用高效的专用技术分别处理计算中最密集的部分,总开销就是可控的。
矩阵乘法专用MPC的简化图,这是AI模型推理中最大的组件。请参阅本文了解更多详细信息,包括如何保持模型和输入的私密性。
“胶合层只需要熟悉,不需要高效”这一想法的一个例外是延迟,以及在较小程度上的数据带宽。如果计算涉及对同一数据进行数十次重复的繁重操作(就像密码学和人工智能一样),那么由低效胶合层导致的任何延迟都可能成为运行时间的主要瓶颈。因此,胶合层也有效率要求,尽管这些要求更为具体。结论
总体而言,我认为上述趋势从多个角度来看都是非常积极的发展。首先,这是在保持开发人员友好性的同时最大化计算效率的合理方法,能够同时获得更多两者对每个人都有好处。特别是,通过在客户端实现专业化以提高效率,它提高了我们在用户硬件本地运行敏感且性能要求高的计算(例如ZK证明、LLM推理)的能力。其次,它创造了一个巨大的机会之窗,以确保对效率的追求不会损害其他价值,最明显的是安全性、开放性和简单性:计算机硬件中的侧通道安全性和开放性、降低ZK-SNARK中的电路复杂性以及降低虚拟机中的复杂性。从历史上看,对效率的追求导致这些其他因素退居次要地位。有了胶合和协处理器架构,它不再需要。机器的一部分优化效率,另一部分优化通用性和其他价值,两者协同工作。
这一趋势对密码学也非常有利,因为密码学本身就是“昂贵的结构化计算”的一个主要例子,而这一趋势加速了这一趋势的发展。这为提高安全性又增加了一个机会。在Blockchain世界中,安全性的提高也成为可能:我们可以少担心虚拟机的优化,而更多地关注优化预编译和与虚拟机共存的其他功能。
第三,这一趋势为规模较小、较新的参与者提供了参与的机会。如果计算变得不那么单一,而更加模块化,这将大大降低进入门槛。即使使用一种类型的计算的ASIC,也有可能有所作为。在ZK证明领域和EVM优化中也是如此。编写具有近乎前沿水平效率的代码变得更加容易和易于访问。审计和形式化验证此类代码变得更加容易和易于访问。最后,由于这些非常不同的计算领域正在趋同于一些共同模式,因此它们之间有更多的协作和学习空间。
免责声明:Vitalik:提升效率和安全性的新构想——胶合和协处理器架构文章转发自互联网,版权归其所有。
文章内容不代表本站立场和任何投资暗示。加密货币市场极其波动,风险很高,可能不适合所有投资者。在投资加密货币之前,请确保自己充分了解市场和投资的风险,并考虑自己的财务状况和风险承受能力。此外,请遵循您所在国家的法律法规,以及遵守交易所和钱包提供商的规定。对于任何因使用加密货币所造成的投资损失或其他损失,本站不承担任何责任。
Copyright © 2021.Company 元宇宙YITB.COM All rights reserved.元宇宙YITB.COM