Web3 的发展源于十年前应对斯诺登事件的网络反思，逐渐形成了一系列核心准则，其中“韧性”最为重要，体现了网络的持续性与可靠性，例如比特币自成立以来从未中断或关闭，展现了技术稳定性和不可阻挡性。同时，“通用性”强调网络适应多任务和应用场景的能力，以太坊通过智能合约扩展了这一特性，而“性能”方面则在效率与一致性优化上仍有提升空间。“可访问性”则涵盖了开发与使用的便捷性，从 API 设计到用户友好性，再到地理和法律限制的考量，而“一致性”通过确保网络状态统一，为去中心化系统构建了信任基础。这些准则 —— 韧性、通用性、性能、一致性和可访问性，共同定义了 Web3 的框架，为去中心化、高效的下一代互联网奠定了基础。

在这一背景下，JAM 的设计基于 Web3 核心准则，是一台无需信任的超级计算机，体现了去中心化与高效性。它是一种虚拟机，用于运行计算机代码，集成了高性能处理和大规模存储功能。作为无需信任的设施，JAM 不依赖传统服务器，也无中心化公司提供服务，构建了真正去中心化的 Web3 云计算基础。

• 数据存储与托管：支持 1.6 PB 数据存储，速率达每秒 2/3 GB。

• 计算能力：相当于 341 个 AMD Threadripper 的四分之一到二分之一速度，每秒计算力约等于消耗一万亿 Gas。

这一设计使 JAM 成为 Web3 云的关键支柱，推动去中心化网络发展。

为解决状态持久分割问题，常用方法是通过桥接链连接区块链，依赖轻客户端实现互验证。然而，这面临因果污染风险：不安全链的事件可能影响更安全的链。此外，桥接链虽能连接区块链，但状态分割问题仍存。一链的数据无法被另一链无缝访问，高成本预言机也难以解决共享问题。

另一方法是提升服务器性能，如增强验证节点，使网络更集中。但这依赖高性能硬件和高速连接，降低新验证者加入可能，同时忽视历史数据访问问题。桥接链和性能优化各有优劣，区块链生态需在性能、去中心化和数据共享间持续探索平衡。

JAM 采用多核计算模型，通过 “几乎一致” 的共享状态避免分片数据隔离，实现数据与计算自由流动。在保持去中心化的同时，优化了韧性与高性能的平衡。多核特性支持高强度计算，尽管异步编程复杂，但系统仍具高韧性。JAM 集韧性、通用性与可访问性于一体，兼顾性能、去中心化和可靠性。

在许多领域，如生物学和物理学，规模与一致性之间的矛盾普遍存在。单细胞生物无法无限扩大，必须演化为多细胞生物；光速限制了规模与一致性。类似地，一致性问题在多核 CPU 设计中也十分明显。简单的分割方法虽可减少一致性问题，但可能削弱系统的组合性。更复杂的解决方案则通过有效的信号系统和缓存管理，确保在需要时能够维持一致性。JAM 努力在大多数情况下管理不一致性，尽管完全一致性在现阶段难以实现，但通过细致管理，它能够在保持旧有用例正常工作的前提下有效应对这些不一致性。

面对一致性存在的矛盾，JAM 采用现代多核和多 CPU 设计理念，具备类似共享存储的内存特性。在任何时刻，每个核心（相当于 CPU 核心）对存储的视角可能略有不同，但最终会达成一致。只要特定存储点一致，系统就能继续处理相关任务。这种机制类似于 CPU 的工作方式，结合了完全一致性和原子性的数据库特性。

因此，当对特定数据进行大量操作时，只要在同一核心上执行，处理便不会中断；若需移至不同核心，则需后台进行数据传输，以保持其他核心的处理效率，这与 CPU 的处理方式相似。

JAM 服务是独立且持续运行的工作负载，类似传统计算机的“进程”。虽与智能合约在去中心化环境中执行程序相似，但本质不同。JAM 提供“持久对象模型环境”，允许用户创建包含代码和数据的对象，通常仅对象自身可访问数据。这种机制虽与智能合约的去信任设计相似，但存在关键差异。

首先，JAM 采用多核执行模型，允许服务同时运行，实现代码的并行执行，这与智能合约的单一执行模式显著不同。其次，JAM 是异步的，执行过程中不一定会同步改变机器的状态，不同服务可以有意地同步进行或在同一核心上共同调度，从而实现高效的同步组合。

在计算资源使用上，JAM 通过固定大小的工作负载或捆绑的工作负载进行 gas 的购买。可以为不同服务准备多个独立的小型工作负载，捆绑执行时形成固定大小的工作负载，确保 gas 量和数据 I/O 量的稳定。这一过程与 Polkadot 的敏捷核心时间类似，但将时间分配给特定质量的工作负载，而非平行链。“工作负载的质量”指在特定时间内某个核心能够执行的工作负载类型。

JAM 核心是高效的数据处理系统，I/O 是关键。在过去一个月，核心每秒处理 2 MB 的数据输入输出，未来一个月数据仍可访问。核心亲和性使同一核心上的数据访问即时，而不同核心访问需等待 1-2 个区块。运行速度为本地的 25%-50%，具体取决于未来 2-4 年的优化。粗估每核心每秒处理 5-50 亿 EVM gas，总 341 核处理能力强大。每核心每秒有 8 KB 输出带宽连接数据库，数据库自带脚本处理器，每秒处理约 100 万次同步访问。此外，预映像查询系统提供免费数据查询，仅需支付链上存储押金。

JAM 服务的处理流程包括四个步骤：

1. 授权：确认即将执行的工作负载已支付费用，使用简单代码判断工作负载的有效性。

2. 精炼（Refine）：执行主要计算，利用 CPU 和核心进行数据的读取与写入，确定写入同步原子数据库的内容。

3. 累积（Accumulate）：处理精炼阶段的输出，通过同步组合功能进行处理，较精炼阶段更具同步性。

4. 转移（Transfers）：处理跨服务信号，确保操作一致性。所有在累积和转移阶段完成的操作为链上操作，准确反映有效状态。

累积与 “集成” 之间存在一些区别，理解跨服务互操作性对于认真使用或开发 JAM 的人来说非常重要。跨服务互操作性指的是两个不同服务之间的交互，这对于服务组合至关重要。例如，一个服务可能是平行链服务，另一个是智能合约服务，它们需要互相操作。此外，同一服务中的不同概念元素也可能需要交互。

在 JAM 中，累积是指在完全一致的环境中进行的计算和 I/O 操作，虽然它不是同步的，其他事情可能会同时发生。因此，累积对操作有一定限制，主要只能改变自身服务的数据库状态，但仍可访问其他服务在 JAM 中的存储（最近的存储快照）并启动“转移”，后者主要是代币或余额转账的小消息。

“集成”是指与服务相关的特定操作，例如在平行链服务中，集成指某平行链区块成为最终链头。累积与集成不同，累积可立即触发集成，也可能排队等待后续集成，具体取决于其他服务或事件的状态。例如，平行链区块可能因分叉状态未确定，需等待分叉延伸或父区块确认。每次累积可能产生多个结果，最终结果需稍后确定。因此，当两个服务被共同调度且累积情况不同时，需确保两者集成同时完成或同时不完成，例如在代币交换中，需保证操作的同步性。

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

当前的 0.5 版本即将完成，主要针对协议实施经验进行调整，以提高操作便利性和工作效率。同时，PolkaVM（PVM）也进行了重要修改，从 32 位寄存器架构转换为 64 位，增加新指令并引入内存分页概念，将内容分割成 4K 页面，页面的可访问性基于页面而非字节。此外，新的主机调用和操作也被加入，以优化性能。

关于 1.0 版本的规划，0.6 版本将对灰皮书进行整理和格式化，纳入网络协议，优化 JAM 协议的轻客户端和跨链实现。0.7 版本将根据在 JAM toaster 上的实际测试反馈进行调整，包括网络优化和消息格式更改。0.8 版本将开发初期的 JAM 服务，测试其性能和互操作性，必要时进行协议功能的调整。0.9 版本的重点则是安全性，以及从在 Canary 网络中的实际应用获得的反馈。

JAM 服务的开发计划即将发布第一个用于开发 JAM 服务的 SDK，设计简洁，仅包含几个文件，以帮助开发者快速了解服务的构建方式和代码结构。在接下来的 12 到 15 个月内，Parity 将计划开发的前几个服务。

将启动初始引导服务 CoreBoot ，已在测试网发布，支持在创世区块中创建和部署新服务。CoreBoot 负责指定验证者组、核心时间分配、新超级用户服务创建、引入特权服务、余额转移及与预映像系统交互，目前已接近完成。

接下来 CoreVM 将展示 JAM 的首个实际应用，设计用于运行 PVM 二进制文件，任何可编译为 PVM 的可执行文件（如 RISC-V）均可在此部署。使用 LLVM 编写的无操作系统依赖简化程序（如 Rust、C++、C）可以在 CoreVM 中运行。PVM 程序可无限期执行，无 gas 或 I/O 限制，采用 32 位可寻址内存，存储在 JAM 的 1.6 PB 存储中并按需分页。最终目标是在 JAM 核心上运行 Doom 游戏。

在 CoreVM 之后，CoreChains 是优先级最高的项目，兼容大部分中继链但存在数据格式差异。其核心思想是确保足够的兼容性以支持 Cumulus 升级，并为现有平行链提供兼容 API，以利用 JAM 作为安全托管基础设施，替代中继链功能。未来，Polkadot 术语可能会变化，尤其是“平行链”可能被称为“区块链”或 L1 区块链。JAM 为 L1 区块链提供安全性、消息中继和最终确定性。

接下来 CorePlay 是在 JAM 上最具野心的项目，基于 CoreVM，允许不同 VM 实例相互发送消息、依赖并进行组合。它可视为一种“角色框架”，支持 PVM、EVM 风格智能合约和无限期执行的程序。用户可选择同步或异步组合，后者不需共同调度，更类似于 XCM，支持如 futures 和 promises 的异步编程原语。

在这些团队中，一些已进入 M1 阶段，具备了同步区块链的能力。M2 阶段要求能够作为验证节点运行，而目前有部分团队甚至已接近 M2 的一半进度，这非常鼓舞人心。

明年将继续开展灰皮书巡回演讲，具体日期将在灰皮书内容最终完善后公布，预计将包括多个亚洲场次。目前，已覆盖灰皮书链上部分的内容（前约 14 章）。下一系列巡回讲座将重点聚焦于灰皮书的链下部分和附录内容，同时简要回顾链上部分，但主要讲解自上次演讲以来的更新与新增内容。