区块链 101：JAM (Join-Accumulate Machine)

这是关于区块链的系列文章的一部分。如果你是第一次看到这篇文章，我强烈建议从本系列文章的开头开始阅读。

前三篇文章（介绍、共识和 Coretime）已经足以让你在高层次上理解 Polkadot。当然，总有更多内容需要涵盖，而且仅仅通过三篇文章就期望成为专家是很难的。

这对于我们介绍的每一个区块链来说都基本如此：它们中的大多数都有活跃的生态系统，而且有太多的细节需要介绍。把所有这些都压缩到这个简短的系列文章中是不可能的！

不过，我们可以在这里停下来，而且可能一切都会很好。

然而，不久前，Polkadot 领域被一些有趣的消息所震撼。Gavin Wood（Polkadot 背后的那个人）继续向前，并在网络的未来投下了一颗重磅炸弹，并继续透露了他最新的智慧结晶：Join-Accumulate Machine（或简称 JAM）。

另外，它听起来像“音乐即兴演奏”——非常吸引人！

这是他本人对这件事的介绍：

我知道——这些孤立的解释可能会让人感到有点望而却步，或者至少有点让人费解。

因此，JAM 激发了同样多的兴趣和困惑。我记得一些同行对这条新闻超级兴奋，在群聊中谈论它——但当被问及这个话题时，他们只是……似乎不知道如何解释任何关于它的事情，只能说“是的，这是 Polkadot 的未来”。

你可以自己查找并阅读灰皮书，但说实话，它非常冗长，而且一点也不轻松。

说实话，这让人有点沮丧，我当时只是没有太努力去理解这些新想法。

现在我正在写关于 Polkadot 的文章，我意识到 JAM 真的感觉像是一个 自然演变。如果你还记得，我们在上一篇文章中质疑我们是否可以重新利用 Polkadot 的共识算法来验证 任何计算——而不仅仅是 Rollup 的状态转换函数。剧透一下：JAM 的确是对 通用去中心化计算 的一种尝试。

我今天的目标是尝试澄清这一切是什么，并专注于定义该技术的核心要素。在阅读本文后，我希望大家清楚地了解为什么这是 Polkadot 生命周期中一个非常有希望的发展。

不过，我不是第一个尝试这样做的人。我还推荐 Kian Paimani 的演讲，他是目前正在实施 JAM 的工程师之一。他也是我在学院时的老师之一！

好了，别闲聊了。系好安全带，让我们开始吧！

解剖 Polkadot

让我们简单回顾一下，好吗？

通过 ELVES，中继链分配验证者组来检查每个 Rollup 的状态转换函数。我们在上一篇文章中提到，每个验证者组本质上都像一个 核心 ——类似于 CPU，以 Rollup 状态转换函数的执行形式运行计算，并以区块作为输入。

是的，太长了——但它很好地总结了我们目前所看到的内容。

本质上，我们所拥有的是一种将中继链的所有验证者分成更小的集合的方法，这些集合可以 并行 地执行计算。这通常被称为 分片 ——这是区块链设计中一个非常受欢迎的功能。

Polkadot 本质上实现了一个 功能齐全的分片策略，这本身就非常了不起。但如果我们更仔细地观察，我们所拥有的只是一个 分布式计算机，它 仅仅 执行 Rollup 区块。

这就是 Polkadot 的连接方式。但是 ELVES 和 Agile Coretime 结合在一起，理论上可以运行 任何 代码——核心（记住，是验证者组）将收到 执行指令，以及可能的一些数据，然后它们就会完成自己的工作。

JAM 只是这个想法的实现。Rollup 只是一种可以在这个分布式计算机上运行的程序的 类型。这件事的重点是 通用化 网络当前提供的功能，从而开启超越我们习以为常的可能性（你知道，Rollup 之类的东西）。

这样说起来，听起来是不是不那么可怕了？

我想如果你这么说……

当然，这个简单的概述还不够。我们需要更精确一些才能真正实现这一点。

重新设计执行

好的。如果我们不再想将自己局限于 Rollup 和 Runtime，那么我们需要定义 什么构成了一个计算，以及它应该如何在新的设置中操作。

再次，查看标准 Rollup 区块的历程是有指导意义的。在之前的文章中，我们已经看到发生了三个关键的事情：

• 该区块由一个核心处理，
• 结果状态的信息以里德-所罗门码字（数据可用性）的形式分发，
• 并且某种形式的证明被永久地嵌入到中继链的状态中。

数据可用性保证了执行可以被 验证，而证明有点像某种计算已经执行的认可——只是碰巧这个计算是一个区块的处理！

正如之前提到的，原则上我们可以对 任何计算 执行相同的过程。这引出了我们的第一个 JAM 概念：服务。

服务

服务 实际上只是一个程序——哎，一个具有特定结构和属性的程序。

这个程序需要定义的只是 两个函数 或入口点，这将允许我们使用所有这些 JAM 机制：refine（提炼） 和 accumulate（累积）。

就这么简单！

过去曾经有一个第三个函数，on transfer（在转移时），它会在累积之后执行——但在灰皮书的 0.7.1 版本中被移除（感谢我的好朋友 Francisco 提供的具体细节）。

此外，这些服务可以接收 工作项 或 工作包，它们本质上是对执行静态服务代码的请求，这些代码在上面提到的两个函数中定义。

也许一个好的类比是将服务等同于 智能合约，将工作项等同于 交易。另一个可能的比较是 Rollup 的 Runtime（服务）和它的 区块（工作包）。

你可能已经开始注意到相似之处，以及它给人的感觉是真正的通用化！

但是……这些函数名 到底是什么？提炼？累积？什么？

这些是什么鬼？

我不知道你怎么想，但如果没有上下文，它们对我来说并没有什么意义。当然，我们可以尝试在 JAM 的背景下理解它们——但我认为花点时间退一步，专注于我们试图实现的目标会更有启发意义：构建一个可以 并行处理工作 的 去中心化计算机。

多核计算机

你知道大多数现代计算机内部都有多个 CPU 核心吗？

是的。当你想在你的机器上执行任务时，你会想遵循某些实际规则。首先，独立的任务可以在不同的核心上运行，这样你就不必等到一个任务结束才开始下一个任务。当任务完全彼此不相交时，并行化是很自然的。

其次，如果你有一些繁重的任务，在单个核心上执行它可能无法最好地利用资源，所以你可能想 拆分任务，并在多个核心上执行它。你将 并行 地执行原始任务的这些部分。

不过，没有免费的午餐——分离是有代价的。也就是说，因为新的进程很可能不是完全独立的，你需要在最后增加一个步骤来 聚合 或 整合 结果，将它们组合起来以获得并行计算的最终结果。

提示，提示！

如果你会产生一个额外的步骤来聚合结果，那么尝试最好地利用每个核心计算是有意义的。为此，你会想给核心 它需要执行任何任务的所有信息。这样，我们避免将资源浪费在写入永久内存上，允许核心专注于执行实际的计算。无论我们得到什么输出，我们都只是将它推送到一些共享内存位置。

换句话说，我们希望核心是 无状态的。

最后，如果整合步骤需要完成任何更多的工作才能完成任务，它将简单地把接下来要进行的任何计算排队——直到没有更多的工作要做，并且整个过程完成。

非常简单，对吧？当然，这确实会带来一些复杂性，例如如何分离要并行运行的任务。但除此之外，这一切并没有什么神秘之处。

JAM 复制了这个模型，但以分布式的方式。这个类比非常直接：

• 核心是以周期为单位并行处理工作项的验证者组。原始输入数据被 提炼 成有用的输出！
• 共享内存被 数据可用性层 取代，该层充当所有核心都可以从中读取的共享存储。
• 结果的整合是在 累积 步骤中执行的：当各个核心的计算结果可用时，它们会被收集起来。

就是这样！非常优雅，对吧？

哇哦！

现在让我们看看这一切在实践中是如何在 JAM 周期中进行的。

JAM 步步为营

共识算法 ELVES 以周期运行。这一点我们已经知道了。因此，我们即将描述的是一个单周期！

当一个核心收到一个服务的 工作包 时，它首先要做的是运行一个被称为 授权器 的东西。它只不过是核心在问：这项工作是否可以执行？这里需要检查的条件可能会有所不同——例如，我们可能想检查相应的 Coretime 是否已经支付。

一旦一个工作包被授权，周期接下来会做的事情是调用 提炼 函数——记住，这里是原始数据被处理的地方。工作包是工作项的捆绑包，而后者才是真正被执行的东西。

可以把它想象成一个总体的程序，以及它的各个步骤。

正如我们之前提到的，这种提炼活动是 无状态的。数据进入，执行一些计算，数据被吐出，仅此而已。

接下来，来自提炼的输出需要提供给网络的其余部分。数据被编码成 里德-所罗门码字，并分发给验证者以实现数据可用性。

我已经在之前的文章中讨论过 纠删码。它本身就非常有趣，所以我建议你阅读一下，如果你还没有读过的话！

最后，并行处理的工作项会在 累积 阶段被整合，在这个阶段，验证者会从这个共享数据层读取结果，并验证已经完成了哪些工作。

为了加深这个概念，我们需要注意的是，每个核心都会有一个它需要执行的任务列表。假设我们要并行执行两个任务；没有什么能保证两个核心会 同时 处理它。

蓝色任务不会被同时处理——这完全没问题！

每个核心只是在准备好时从它的队列中 选取下一个工作包。允许这种情况发生意味着累积步骤在它能认定蓝色任务已经完成之前必须 等待。

所以是的，它允许在数据可用性层中发生对部分结果的累积！

这种简单的设计保持了系统的灵活性和效率，使其既能 扩展，又能比其他传统的区块链系统 更通用。

案例

为了展示 JAM 可以做什么，我想展示一些你可以利用去中心化并行计算能力的想法。

让我们疯狂起来！

• 去中心化预言机网络：想象一个服务，它处理并聚合已经提交给网络的价格数据。工作项将包含预言机提供商提交的价格数据，不同的核心将处理并验证这些提交。例如，累积会计算加权平均价格，可能会过滤掉无效的提交或异常值。
• 欺诈检测系统：我们可以分析交易模式来检测可疑活动。工作项将包含最近交易的批次，核心将并行运行不同的检测算法——一个检查异常支出模式，另一个分析交易时间，还有一个评估某些钱包是否在某些已知的黑名单上。累积会将所有分析结果结合起来，为每笔交易生成一个全面的风险评分。如果超过了某些阈值，我们可以触发警报或额外的验证过程。
• 繁重的计算：我们想运行一个蛋白质折叠模拟，这需要大量的并行处理。每个工作项可能会模拟蛋白质结构的一小部分，数百个核心可以同时处理不同的部分。然后在累积期间将部分结果组合起来以构建完整的折叠结构。如果需要更多的迭代，它们可以被轻松触发。

我们甚至可以想到更极端的例子，比如在 JAM 上运行一个大型语言模型！

我并不是说这些例子中的任何一个都一定是 实用的——只是说它们是可能的！

有了这些，我们已经涵盖了 JAM 最重要的两个方面：它是什么（去中心化计算的通用模型），以及它是如何工作的（通过其并行处理模型）。

但是，如果你一直密切关注，你可能已经注意到缺少了一些 关键的 东西：我们应该编写的 代码 到底是什么？核心又是如何执行它的呢？

PVM

到目前为止，我们知道不要对这个问题感到惊讶。区块链会求助于 虚拟机 的概念来解决这个问题：以太坊有 EVM，Solana 有 SVM，而 Polkadot 最初有 WebAssembly（WASM）。

这个想法很简单：我们希望所有验证者在相同的条件下运行相同的代码，所以他们的特定硬件 不能 在这一切中 发挥作用，因为否则我们会损害 确定性。

确定性对于共识至关重要：如果节点对于相同的计算可能会得到不同的结果，他们又怎么可能达成一致呢？

JAM 规范 也 引入了 Polkadot 虚拟机（PVM）作为其执行环境。它几乎是核心在执行提炼和累积时实际运行服务代码的引擎。

你可能会问，为什么要放弃 WebAssembly 呢？嗯，原因有很多。具体来说，WASM 有一些 内在的问题，从它被选为 Polkadot 逻辑的骨干开始就需要解决。

让我们提几个——在这样做的时候，我们会说一些关于 PVM 的事情。

确定性

又来？

是的——我们几段前才提到过确定性。事实证明，它在 WASM 中有点问题：它的规范中内置了一些非确定性代码。比如默认的浮点数表示。

这不一定是一个糟糕的特性——只是在处理区块链时，它 可能会非常有害。我们可以使用一些技巧来避免这些潜在的陷阱，但它们增加了复杂性，以及许多不需要的额外计算。

相比之下，PVM 是一个基于 RISC-V 的虚拟机。

我在 最近的一篇文章 中简要地谈到了 RISC-V！请注意，它是基于 RISC-V 的，但 不完全是 RISC-V。

这意味着 指令集架构 （可以理解为操作码）是为你在 专门为区块链设计的 环境中想要运行的操作量身定制的。或者换句话说，你完全不允许所有不需要的行为（比如浮点运算）。因此，你可以更严格地控制执行行为，同时保持精简和高性能。

计量

WASM 的另一个大问题与估计执行不同指令的成本有关。

因为我们想为网络使用 收费，所以拥有精确的机制来 测量 使用情况非常重要。反过来，这赋予了网络 可预测的 属性——你可以估计完成某个任务所需的计算量，并由此估计成本。

像 EVM 这样的模型显然是计量的——计量体现在 gas 的形式中。

WASM 在这方面表现不佳。它的设计考虑了 通用性：有点像“一次编译，到处运行”的理念。因此，代码可能会被映射到不同机器上的一组非常不同的指令。这意味着事情实际上是如何执行的取决于 硬件。我们知道这 不好。

同样，有一些技巧可以尝试获得一些费用的可预测性，但它们感觉像是 补丁，试图修复一个存在于架构级别的问题。

如果你还没有在 Polkadot SDK 中进行过基准测试……你不知道你有多幸运。天啊，那真是痛苦。

你只是适应了黑暗。我生于其中。

PVM 允许 通过设计 进行轻松计量。当然，像任何虚拟机一样，类似于 RISC-V 的指令必须在某个时候编译成机器代码，但我们可以根据 PVM 本身的指令来衡量执行工作量。

非常像 EVM！

PVM 从头开始设计，其架构是为了规避这些缺点。从开发人员的角度来看，你不会注意到太大的差异——你仍然可以用 Rust 或 C 编写服务，并且它们会编译成类似于 RISC-V 的指令，而不是 WASM 字节码。

重要的是，在底层，JAM 获得了其并行处理模型所需的确定性、高效的执行。

虽然我不想深入研究 PVM 的完整规范，但有一个特别新颖的特性，非常值得强调：暂停计算 的能力。

暂停 & 恢复

接着我们早些时候与计算机的类比，我们可以检查程序是如何执行的。

在其核心（不是双关语），程序只是 一组指令，它们一次运行一条。当它们被执行时，这些指令会提示系统将信息存储在内存中，构建一个 执行上下文。程序本身是静态的指令组，但特定的上下文（或计算的特定 状态）会有所不同。

实际上，有几种计算模型可以帮助我们理解为什么暂停和恢复首先是可能的。特别是，PVM 被建模为 寄存器机器，这可能会让你感到熟悉，因为它更接近于我们日常使用的计算机。

实际上，有一个称为计算复杂性理论的整个研究领域，它研究不同的抽象机器及其能力（以及其他事情）。

所以，如果我们停止任何进程，我们会得到什么？让我们看看：

• 当前正在执行的指令。
• 内存中的一堆信息（寄存器和 RAM）。

不多也不少！

如果我们暂停执行，获取上面提到的这个 状态，并将它与要执行的完整代码一起提供给另一个核心，那么它应该能够 继续执行程序，就像什么也没发生过一样。

这听起来很傻，但实际上，大多数区块链 VM 根本 无法 做到这一点。计算会执行直到你 耗尽 gas，并且根本没有本地方法可以在下一个区块中继续计算。

没有什么是不经意设计的：不仅区块有固定数量的空间，而且系统还使用交易，这些交易旨在包含在区块中以保持整体状态的连贯性。

PVM 完全忽略 这种限制。如果你想将计算限制为单个区块，没问题！不要让任何事情阻止你，冠军。但是如果有一些永远 无法 适应单个区块的长时间运行的任务呢？你只需累积并继续！

这与计算如何收费的机制搭配得非常好：你不需要支付 gas，你需要支付 Coretime！

深入研究 PVM 设计的内部结构是可以的——但我相信我们已经在一篇文章中介绍了足够多的内容。

所以这将是另一个故事了！

总结

有了这些，我们已经到达了 Polkadot 设计的最前沿。我们已经足够深入地开始熟悉基本概念，但也没有太过肤浅而错过了 JAM 实际所包含的内容。

如果你仔细想想，这是对前三篇文章的完美整合：事情是如何以通用性为目标开始的，共识是如何在考虑分片的情况下设计的，如何设计一个完全不同的模型来支付计算，最后，这个：一切如何结合在一起成为一个 真正的去中心化计算机，而不仅仅是一个去中心化的账本技术。

作为一个必然的结果：

JAM 不仅仅是一个增量升级——它是对区块链可能是什么的根本性重新设计。

这当然是一个超级雄心勃勃的想法。

然而，人们不禁想知道 采用 的问题。毫无疑问，JAM 是一项伟大的工程壮举——但它会被使用吗？它会不辜负其宣传吗？它会成为下一个杀手级区块链吗，还是没有人会关心去中心化的并行计算？

只有时间会告诉我们。世界各地的团队都在竞相创建 JAM 的功能实现，所以我们必须等待一段时间才能看到整个故事的展开。

说实话，这非常令人兴奋！

有了 Polkadot，人们会认为没有太多内容可以涵盖了——而且事实上，我们正在逐渐接近本系列的结尾。

但是我们还没有讨论过一些怪癖，其中之一是现代流行语：ZK 证明。它们正在慢慢地进入区块链领域，在下一篇文章中，我想探索它们可能如何影响这项技术的未来。

我们很快再见！

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