重磅！Gavin 宣布 JAM 服务路线图！明年开启 JAM 亚洲巡回演讲！

加入 PolkaWorld 社区，共建 Web 3.0！

Polkadot 在泰国曼谷举办的 sub0 reset 活动圆满结束！最令人期待的 Gavin Wood 的演讲在最后一天进行，他在现场分享了 Polkadot 发展出 JAM 的最初想法，出以及 JAM 当前的进展，此外还重磅推出未来 JAM 的路线图！该演讲内容较长，PolkaWorld 将分为两部分发布！

本文为第二部分，主要内容包含 JAM 服务的详细介绍、JAM 当前的开发进展以及 JAM 服务的路线图和预计上线时间！

在这里查看第一部分《Gavin Wood：JAM 就是一个无需信任的超级计算机，它构成了 Web3 云的基础！》

Gavin 每次的演讲内容都极具观点，本次也不例外！继续阅读，查看 PolkaWorld 的整理版本！

JAM 服务是独立且持续运行的工作负载，它在 JAM 计算机上的角色类似于传统计算机中的“进程”。虽然 JAM 服务和智能合约有一些相似之处，比如它们都是程序，都在去中心化的环境中执行，但这仅仅是表面上的相似，不是那种需要深究的类似。

JAM 提供的是一种我称之为“持久对象模型环境”，这与面向对象编程环境类似。如果你了解 JavaScript 或类似的环境，那么这个概念会比较熟悉。在这种环境中，你可以创建对象。这些对象拥有代码和数据，一般情况下，只有对象本身可以访问它们的数据。这是一种去信任的机制，和智能合约类似。但是，有一些非常重要的不同之处，意味着你不能简单地将你对智能合约的理解直接套用到 JAM 上。

首先，JAM 采用的是多核执行模型，这意味着服务（而非智能合约）可能会同时运行，也就是说，可能会有代码同时执行。所以这是第一个不同点。

其次，JAM 是异步的。当执行发生时，不一定会同步改变机器的状态。不同服务的执行可能会有意地同步进行，或在同一个核心上“共同调度”。共同调度一个或两个不同的服务可以在其主要工作负载中实现同步组合的可能性，这非常有用，而这也与异步执行的概念相对。

事实上，这是唯一真正可以实现同步组合的方式，除非你退而求其次，通过使用序列器来进行同步组合。而部分工作或任务包是可排序的，因此你可以指定任务的顺序，比如让某个任务先于另一个任务完成。

在计算资源的购买方面，购买 gas 是以固定大小的工作负载或捆绑的工作负载为单位进行的。可以为不同的服务准备多个独立的小型工作负载，但当它们捆绑在一起并投送到机器中执行时，便是一个固定大小的工作负载。因此，gas 量和数据 I/O 量都是固定的。

这类购买过程与 Polkadot 当前的敏捷核心时间（agile core time）相似，只不过这里不是将时间切片分配给平行链，而是分配给特定质量的工作负载。我稍后会解释“工作负载的质量”这一概念。它指的是限制在特定时间内某个核心可以执行的工作负载类型。

我们可以这样想象 JAM 核心的工作原理是这样的一张图。

首先，最重要的是 I/O。在过去的一个月内，JAM 核心可以每秒获取最多 2 MB 的数据，同时每秒将最多 2 MB 的数据推回存储系统，该数据可在未来一个月的任何时间访问。正如所提到的，这里有“核心亲和性”（core affinity），这意味着如果在同一个核心上访问数据，通常是即时的；如果在不同核心上，可能需要等待一个或两个区块。

核心本身的运行速度大约是本地速度的 25% 至 50%，具体取决于未来 2 到 4 年内的优化进展。目前预期的速度大概在这个范围。如果想与 EVM gas 进行对比，这并不简单，因为 EVM 上的不同操作在 x86 处理器上的执行时间各不相同。但大致估计，每个核心每秒能处理约 5 亿至 50 亿 EVM gas。而且这是每个核心的速度，我们共有 341 个核心。

每个核心每秒有大约 8 KB 的输出带宽连接到数据库。而数据库有自己的脚本处理器和脚本核心，每秒可以处理大约 100 万次对同步数据库的访问。此外，还有一个独立的预映像查询系统，它可以提供免费的数据查询，只需支付链上存储的押金。

如果我们查看 JAM 服务的处理流程，来看 JAM 服务实际执行的内容，基本上有四个计算步骤需要完成。

第一个是授权。授权的作用非常简单，就是确保即将执行的工作负载已支付费用。它是非常小的一段代码。在 JAM 中，你不需要将核心时间附加到平行链上，因为 JAM 不知道平行链是什么。相反，你将核心时间附加到某种工作负载上，并且可以编写代码来识别工作负载的类型。这是一个图灵完备的操作，你可以编写任何可以编译到 PVM 的代码，并在代码中判断工作负载是否有效。这段代码就是在授权阶段运行的。

接下来的阶段称为“精炼”（Refine）。精炼阶段基本上是主计算阶段，在这里你执行所有的计算，使用 CPU 和核心，读取和写入大存储，最终决定需要写入同步原子数据库的内容。

然后进入累积（Accumulate）阶段。累积阶段基本上是数据库阶段，而累积代码则是用于处理精炼阶段输出的脚本，通过 JAM 的其他同步组合功能对其进行处理。虽然它不是完全同步的，但比精炼阶段更具同步性。

最后，是转移（Transfers），这可以由累积代码触发。转移阶段本质上是用于处理任何跨服务信号的脚本，需要以完全一致的方式完成。因此，它是同步的，虽然不是绝对的同步，但确实是完全一致的。在累积和转移中完成的所有操作都是链上操作，因此能够反映绝对的有效世界状态。

累积和我称之为“集成”之间有一些区别。这是一个需要进一步探讨的点，但现在我先简要说明一下，供那些认真使用或开发 JAM 的人了解一下跨服务的互操作性是什么样的。

跨服务互操作性本质上是指两个不同的服务希望进行某种交互。这对于服务的组合非常重要，比如一个服务可能是平行链服务，一个是智能合约服务，它们需要互相操作。也可能是同一服务中的两个不同概念元素。虽然跨服务互操作性主要适用于不同的服务，但同一服务内的元素也可能有用。

在 JAM 中，累积是一个概念，指在一个完全一致的环境中进行的计算和 I/O 操作。这并不是同步的，也就是说，其他事情可能会同时发生。因此，累积对操作有一定限制，你基本上只能改变自己服务的数据库状态，但依然可以访问其他服务在 JAM 中的存储（虽然并非实时数据，而是最近的存储快照），并启动“转移”。转移基本上是带有代币或余额转账的小消息。

“集成”是与服务相关的特定操作。例如，在平行链服务中，集成可能意味着某一平行链区块成为该平行链的最终链头。累积和集成是不同的概念，累积可以立即触发表面影响的集成，但也可能将影响排队等待以后集成，可能取决于某些其他服务的集成情况，或该服务内的一些其他事件。例如，以平行链为例，某个平行链区块可能处于分叉上，还不能最终确定，因为需要等待看到哪个分叉会变长，或者需要等待父区块出现。因此，对于任何给定的累积，可能会有多个不同的结果，只有在稍后才能最终确定。因此，如果两个服务被共同调度，各自有不同的累积情况，那么你不希望一个服务集成了，而另一个未集成。如果是两个平行链之间的代币交换，你希望两者都完成集成并完成代币交换，或者两者都不进行集成。如果一个服务的累积立即集成，而另一个服务可能稍后才累积，就会出现问题。

因此，可能需要在 JAM 协议中增加对原子集成管理的支持，以便管理超出累积本身的原子性结果。这也可能仅仅是 SDK 的一部分，一种约定的使用方式。目前尚不确定，可能需要在 JAM 上对一些服务进行原型测试，以更好地了解这是否需要成为协议的一部分，还是可以通过 SDK 或其他方式来实现。

现在我来谈谈我们目前的进展和未来的方向。JAM 的灰皮书，也就是 JAM 规范，经历了四次较大的版本更迭。

0.1 是最初的草案，于四月在迪拜发布。

0.2 引入了我们称为“分段 DA”的内容，基本上就是我所说的所有与 4K 页和共享存储中的月度周期相关的内容。分段 DA 为这些内容提供了基础。

0.3 引入了协议中一些必要的最终元素，包括统计数据、争议和权限。

0.4 则不久前发布，引入了有序累积，这意味着 JAM 核心可以与某些存储元素建立亲和性。如果没有这种亲和性，JAM 核心的 L2 或 L1 缓存将无法在执行工作包时从存储中快速提取先前的输出。

在有序累积之前，我们总是将所有数据写入 RAM，等待它在所有 CPU 上保持一致，然后如果我们想读取先前写入的内容，就将其取回。如果我们读取的是最近没有写入的数据，不会有延迟。但如果我们处理的是一个较长的工作负载，反复写入中间数据再读回，那么就会遇到很多延迟。因此，我们需要一种亲和性，基本上是需要一个缓存。有序累积为协议提供了这种亲和性，也即通过这种缓存来减少延迟。

0.5 版本正在进行中，几乎完成了，并引入了一些在问题列表上存在了一段时间的重要元素。主要是一些基于协议实施经验的小调整。当你实际实施时，会发现某些操作顺序的调整会更方便，或者某些数据如果放在特定位置会节省很多工作量，而这正是我们所做的调整。

0.5 的另一重点是对 PolkaVM（PVM）的改动，主要变化是从 32 位寄存器架构转换为 64 位寄存器架构。这带来了一些新指令，并移除了少量旧指令。此外，灰皮书中引入了 PVM 的内存分页概念。所有内容都被分割成 4K 的页面，并且这些页面的可访问性（读、写或不可访问）基于页面而非字节，与之前的单字节访问模式不同。另外，还引入了一些新的主机调用和操作，主要用于优化，比如 memset 和 memcopy。

关于 1.0 版本的规划，0.6 版本计划主要是对灰皮书进行整理，完成一些格式化工作。0.7 版本预计是从 Jam toaster 上的实际测试中获取反馈后进行的调整。0.8 版本将基于实际开发的服务进行调整。0.9 版本则是冻结功能，仅做安全修复。

更详细地来看，0.6 的重点在于形成一份全面、完整的规范，包括将网络协议纳入规范中，可能会调整默克尔山脉的格式，以优化 JAM 协议的轻客户端和跨链实现。此外，将改进格式化，例如正确引用 Grandpa 和一些加密技术，消除重复内容，并尽量完成第一阶段的测试向量。这虽然不是灰皮书内容，但密切相关。

0.7 版本的重点是 JAM toaster 上的 JAM 协议试验后发现的优化，预计将包括网络优化、增加新的网络消息和更改现有消息格式以提升运行速度。可能会对消除编码的两种用法之一进行优化，特别是在网络数据传输方面。对于熟悉 JAM 的人，我们可能会对工作报告进行结构化的 Gossip，而不是在最终区块中分发工作报告，而是预先分发。同时，PVM 也可能会有一些调整。

在 0.8 之后，我们将着手开发初期的 JAM 服务，并测试其性能、开发的便捷性以及互操作性。如果发现需要进行累积和集成的协议功能，可能会在此阶段进行修改。PVM 可能也会为某些服务（如平行链服务）进行调整，分布式可用性系统也可能进行优化，具体情况将视服务原型测试结果而定。

0.9 版本的重点将是安全性，以及从实际应用于 Canary 网络中获得的反馈。

接下来聊一下在 JAM 上开发服务的情况。很快我们将发布第一个用于开发 JAM 服务的 SDK，非常简单。代码量不多，就几个文件，但这将让大家开始了解服务是如何构建的、代码结构如何。接下来 12 到 15 个月，我们将看到 Parity 计划开发的前几个服务。当然，任何人都可以开发服务，但这是我们安排中的计划。

今年四季度我们会启动一个初始的引导服务。这项服务已经发布，在测试网中我们可以将它放入创世区块。这允许我们在网络上创建和部署新服务。JAM 本身并没有服务部署的概念，只有创世区块中已有的内容和服务执行的操作。JAM 协议本身并不具备这个功能。此外，它还处理指定验证者组、分配核心时间、创建新的超级用户服务、引入特权服务（称为始终累积服务，即总是运行的服务）、余额转移以及与预映像系统的交互。这是 CoreBoot 服务，这个服务几乎已经完成编写。

接下来是 CoreVM 服务，这是一个有趣的测试服务，将成为展示 JAM 能力的第一个实际示例。CoreVM 设计为运行 PVM 二进制文件的服务，因此任何可以编译为 PVM 的可执行文件（例如 RISC-V 可执行文件）都可以部署在 CoreVM 上。实际上，任何使用 LLVM 的程序，比如用 Rust、C++ 或 C 编写的程序，都可以在 CoreVM 中运行。

不过，这些程序不能依赖操作系统的高级服务，只能是无操作系统依赖的简化版程序。但任何 PVM 程序都可以链上运行。关键在于，它可以无限期执行，不受 gas 或 I/O 限制。它没有特殊的存储设施，只有内存——32 位可寻址内存，这些内存被巧妙地分割，存储在 DA 和 JAM 的 1.6 PB 存储中，并根据需要分页调入。同时，它会像在常规操作系统上一样调度执行、暂停并恢复运行。我认为通过 CoreVM，我们可以展示 JAM 的运行更接近真实的硬件机器，而不仅仅是区块链。

最终的展示方式当然是尝试运行 Doom 游戏，这是我们要尝试的。我们计划在 Jam 的核心上，也就是链上运行 Doom 游戏。我不确定是否会输出图像，但我们希望 Doom 本身能在 JAM 上运行。

在核心 VM 之后，优先级最高的下一个项目是核心链（CoreChains）。它本质上是一个与中继链大部分兼容的版本，但并非完全兼容，因为数据格式等方面存在差异。不过其核心思想是兼容性足够高，以便 Cumulus 可以升级，提供一个兼容的 API 给现有的平行链，使它们能够使用 JAM 作为安全托管的基础设施，替代现有的中继链功能。

实际上，明年我们可能会看到 Polkadot 术语上有很多变化，部分讨论已经在 Polkadot 论坛上进行。总体上，这些调整是有意义的，尤其是在“平行链”这个概念上。我们未来可能会不再称之为“平行链”，而是直接称之为“区块链”，即 L1 区块链。JAM 提供的是一种为 L1 区块链提供安全性、消息中继和最终确定性（finality）的托管服务。这种表述更清晰，揭示了 JAM 的作用。

因此，我们可以将 JAM 看作一个服务平台，其中一个服务是区块链的安全保障，但还可以有其他服务。因为 JAM 并不是一个“区块链的区块链”，而是一个多核超级计算机。这种架构带来了一些结果，其中之一是“协定”（accords）的概念，这类似于智能合约形式的区块链互联，这是 JAM 应该能够提供的功能。

紧随其后的核心项目是 CorePlay，这是我们在 JAM 上想要开发的最具野心的项目。它建立在CoreVM 之上，允许不同的 VM 实例互相发送消息，彼此依赖，甚至能够进行同步组合。可以将其视为一种“角色框架”，这些角色可以是不同的范式，比如 PVM 角色、EVM 风格的智能合约角色、无限期执行的程序（如 Doom 游戏），基本上可以是任何所需的形式，因为它是一个通用的虚拟机。

理论上，用户可以在同步组合（即共同调度）和异步组合之间进行选择。异步组合不需要共同调度，更类似于 XCM，或是一种暂停-恢复机制，拥有良好的异步编程原语，就像在常规语言中可以看到的那样，包括 futures 和 promises 等机制。

灰皮书奖进展非常顺利，实际上让我感到惊喜。目前已有 32 个注册的团队宣布参与，数量比我预期的要多得多。我原本认为如果能有 10 个团队参与就已经不错了，但现在的结果非常令人欣慰。

在这些团队中，我们看到一些已经进入了 M1 阶段，基本上具备了同步区块链的能力。M2 阶段要求能够作为验证节点运行，而现在有一些团队甚至已经达到 M2 的一半左右，这非常鼓舞人心。为这 32 支团队点赞！

此外，我将在明年继续进行灰皮书巡回演讲。基本上，一旦我对灰皮书的内容感到满意，即达到较为最终的状态时，我们会公布日期。预计会有相当多的亚洲场次。目前我只覆盖了灰皮书的链上部分，即前面大概 14 个章节左右。下一系列的巡回讲座将更专注于灰皮书的链下部分和附录部分，虽然我也会简要回顾链上的内容，但主要会着重讲解自上次讲座以来的更新部分。

感谢大家的聆听，希望你们喜欢这次的分享，谢谢！

• PolkaWorld Telegram 群：

  https://t.me/+z7BUktDraU1mNWE1

• PolkaWorld Youtube 频道：
  

  https://www.youtube.com/c/PolkaWorld

• PolkaWorld Twitter：

  @polkaworld_org