2024 年 4 月Gavin Wood 在 Token2049 迪拜的舞台上抛出了一整套重新设计中继链的方案。我当时盯着 JAM 这个名字看了很久直觉告诉我这不是一次常规升级。后来我反复读灰皮书、追踪社区讨论才慢慢意识到这背后藏着一个真正釜底抽薪式的转变把 Polkadot 的中继链从“调度多链的交通警察”改写成一台可验证计算的通用机器。如果你也关注 Polkadot、中继链、区块链计算的演进方向这篇内容可以帮你把 JAM 的来龙去脉一次理清楚包括它凭什么用几个函数就能重新定义链上计算以及作为开发者和生态观察者我们应该从哪些细节开始理解它。1. JAM 到底在改什么从“调度多链”到“一台可验证的全局计算机”1.1 中继链的旧角色交通警察而不是计算引擎要理解 JAM先得回到 Polkadot 过去几年的运行逻辑。传统中继链的核心职责是三件事验证平行链的候选区块为这些平行链提供共享安全以及在它们之间维护跨链消息的传递。套用一个不太精确但很贴切的比喻中继链更像一个交通警察负责确认哪辆车可以进入主路、哪辆车可以转弯、什么时候放行但警察不会去检查车里装了什么货更不会帮你计算货物重量。这个设计的优点很明确平行链不需要自己从头建立验证者网络安全性直接共享中继链的共识。但它的代价同样明显平行链的启动成本太高了。你想成为一条平行链就得参与插槽拍卖锁定大量 DOT还要经历漫长的租期和治理流程。哪怕你的想法只是一个实验性的小应用这套流程也会挡住绝大多数人。于是问题来了能不能把“链”的门槛拆掉让开发者不必构建一条完整的平行链也能利用中继链的安全和计算能力JAM 回答的正是这个问题。1.2 JAM 是什么一个可以被直接执行的通用机器JAM 的全称是 Join-Accumulate Machine直接翻译是“合入-累积机”。这里的关键词是“Machine”它不是另一条链而是一类运行在验证节点上的可验证计算模型。Gavin Wood 在 2024 年发布的灰皮书The Gray Paper中给 JAM 下过一个很关键的定义它结合了以太坊智能合约的无信任执行理念和有 RISC-V 风格的指令集灵活性最终呈现成一个更通用、更细粒度的“可信计算网格”。更直白地说JAM 不再要求一个项目必须拥有独立的区块空间才能接入 Polkadot。它允许所谓的服务Service直接向中继链提交工作包Work Package由验证节点基于一组明确的函数来执行、累积和确认状态变更。平行链仍然可以是服务但同时预言机、ZKP 验证器、数据可用性层、跨链桥逻辑甚至一个普通的链上游戏都可以作为服务存在。从这个意义上讲JAM 正在把“中继链 平行链”的双层结构收敛成“中继链即计算引擎服务即程序”的单层模型。这就是我理解中“重新定义区块链计算”的第一层含义。1.3 为什么这件事会发生在 Polkadot而不是别处很多人刚听到 JAM 时会觉得这不就是把智能合约平台做得更通用吗为什么要放在 Polkadot 的语境里讨论原因是 Polkadot 的现有架构已经为这个转变铺好了地基。中继链的验证者网络、共享安全模型、跨链共识工具都是现成的。JAM 不需要从零建立一个验证者集群它只需要改变这些验证者正在执行的任务。换句话说Polkadot 有全世界最成熟的多链安全基础设施JAM 则把这个基础设施从“给链做公证”延伸成“给任意计算做公证”。如果你是做独立应用开发的人这件事的意义可能更直接你不必为了获得共享安全而先购买一整条链的区块空间你可以只购买一笔服务所需的计算资源把业务逻辑作为服务直接运行。降低了门槛也让更多非区块链原生团队有机会进入这个生态。2. 所谓“三个函数”Join / Accumulate / Enact 的完整生命周期2.1 先澄清一个传播口径是三个还是四个聊 JAM 时几乎所有媒体都会提到“用三个函数重新定义区块链计算”但如果你去读灰皮书会发现实际上被反复强调的核心操作有四个环节Join、Accumulate、Yield、Enact。那为什么大家习惯说三个我个人的理解是Join 更像系统层面的输入边界Accumulate 和 Enact 才是真正推进状态的主干而 Yield 则是可选的异步出口。把 Join、Accumulate、Enact 连在一起看正好构成一个完整的“输入-处理-确认”闭环所以很多人就用“三个函数”来概括这个生命周期把 Yield 当作挂在 Accumulate 上的异步回调。这种简化不影响理解但在深入技术之前心里要先有这个数JAM 的主流程并不是真的只有三行代码而是由这几个逻辑步骤共同约束的协议。2.2 从函数视角看状态转换如果你写过函数式编程理解 JAM 会顺畅很多。中继链的每一个区块周期本质上是在执行一个状态转换函数输入是前一个状态和当前接收到的外部消息输出是下一个状态。具体到 JAM这个状态转换被拆成了几个阶段Join负责把上一轮区块的上下文与外部新到的消息做一次归一化组合形成当前轮次可以处理的“提案”。你可以把 Join 想象成一道安检门把所有零散的入站请求整理成标准格式才允许它们进入主流程。Accumulate这是核心的批处理步骤。验证节点会把多个工作包放在一起按照服务的累积规则执行代码推进各自服务的状态。它不需要在一瞬间完成所有事情系统允许一个服务在一段可用性窗口内分多步积累结果。Enact当累积阶段结束时系统必须做出最终确认把累积结果正式写入状态并推进到下一个区块。Enact 是整个周期里最像“定案”的一步一旦执行结果对所有人可见且不可逆转。Yield服务在累积过程中可以主动对外发起异步请求这个动作就是 Yield。它让 JAM 不必把所有事情都塞进一个同步执行上下文而是允许服务“等一下再回来拿结果”。写到这里你应该已经能感觉到 JAM 和传统区块链执行模型的差异了。以太坊的每笔交易是独立、原子化地修改全局状态JAM 则把状态转换拆成多个可分离、可验证、可异步化的小步骤。这让中继链不需要像一个巨大的单线程状态机那样硬扛所有交易。2.3 用一个小场景串起完整流程光说概念还是有点抽象我拿一个预言机服务的例子走一遍全流程。假设 A 服务是一个链上天气预言机它需要在每个区块周期内把纽约的气温更新到链上。服务先向中继链提交一个工作包里面包含“我要获取纽约当前气温”的请求和一个可验证的获取逻辑这一步触发 Join请求被纳入当前区块周期。验证节点运行工作包在 Accumulate 阶段执行请求并记录该服务希望更新的气温数据。此时数据尚未最终生效只是累积在待确认集合里。如果服务还需要调用外部 API它可以在 Accumulate 中发起 Yield表示“我这个数据来源需要异步响应请给我一个回执我下一轮再继续”。最终外部数据或证明被补充回来服务在后续的累积周期里确认该数值并在 Enact 阶段正式把气温更新写入状态。这就是 JAM 的生命周期一个服务不是像一个智能合约那样被“一次性调用”而是被持续地累积推进。它更像一个长期运行的后台进程每一轮都可能前进一步。2.4 和传统智能合约的对比从原子事务到可编程管道传统智能合约的执行模型可以类比成餐厅里的单点得单。一个订单进来厨子一口气把菜做完做完才上菜。整个过程是原子的要么全部完成要么全部失败。这个模型简单、安全但扩展性天然受限因为每个厨子同一时间只能服务一张桌子。JAM 则更像一个流水线工厂。同一个服务的不同工作包可以流水线式进入聚合后批量执行异步结果可以稍后再合流。它不是把所有事情锁在一个全局状态里而是允许每个服务维护自己的累积状态由中继链周期性验证。用这个视角看JAM 把状态转换从“交易的原子执行”升级成了“可编程的管道计算”。这就是它后来被许多人称为“通用可验证计算”的根本原因。3. 中继链的“搬运”功能如何变成“计算”功能核心原语拆解3.1 Accumulate 不是内存而是“审批窗口”我最初理解 Accumulate 时踩过一个误区以为它就是一个链上的全局数据库所有数据都可以直接写入。读灰皮书后才明白Accumulate 更像一个带严格约束的审批窗口服务的累积结果必须满足预定义的可用性和有效性条件验证节点才会接受。这里有一个容易被忽略的细节JAM 中的验证者不会盲目执行任意代码他们会检查每个工作包的有效性。无效工作包不仅会被拒绝提交方还可能被罚没抵押。这种机制和以太坊的 gas 思路有本质区别。以太坊用 gas 来限制“你愿意花多少钱执行”JAM 则用“可用性窗口 有效性证明 抵押惩罚”来保证“你提交的东西必须正确可靠”。从开发者的角度看这意味着你写的服务代码不能像写传统智能合约那样“掷骰子”必须尽量避免不确定性行为和对外部不可验证资源的依赖。如果你的工作包在验证者那里跑出来的结果不一致它就会被视为恶意或无效。3.2 Yield 让异步世界可以被验证区块链的确定性执行环境通常很讨厌异步操作因为“等待外部响应”会破坏状态机的一致性。这也是为什么绝大多数链上应用都是“请求-响应”同步模型而不是真正异步的事件驱动模型。JAM 的 Yield 函数试图解决这个矛盾。它允许服务在累积过程中挂起一个状态向外部发送一个异步请求同时保留一个“恢复点”。下一轮服务可以携带外部响应回到累积流程继续推进自己的状态。这个设计让我想起操作系统的异步 I/O 模型。你在读一个大文件时不会让 CPU 卡在那里空转而是发一个异步读请求等内核完成后再通过回调把数据交还给你的进程。JAM 的 Yield 本质上就是区块链世界里的异步 I/O它让链上服务可以和真实世界的数据源、计算源、甚至其他服务进行非阻塞式交互同时不牺牲最终的可验证性。3.3 可用性、有效性与最终确认的三角支撑一个分布式系统要安全运行至少要有两个维度数据可得和逻辑正确。以太坊靠每个节点都执行全部交易来保证这两点代价是极低的吞吐和巨大的存储消耗。Polkadot 平行链时代靠共享安全和中继链验证来解决但平行链仍然有自己的共识轮次和出块流程。JAM 的做法不太一样它把可用性和有效性拆成了两层机制可用性层工作包提交后必须在一个可用性窗口内灰皮书中规定了一些参与者的托管职责被足够的验证者保存防止审查和事后数据丢失。有效性层工作包的执行结果必须由验证者验证保证服务状态转换符合规则。如果验证者发现结果有问题可以不接受该提案并启动罚没流程。在 Accumulate 和 Enact 之间系统还会给服务留下足够长的“确认缓冲期”。这不是拖延而是为了给各方充分的检查和质疑的时间。我对这套设计最深的感受是JAM 在故意放慢“定案”的速度以换取更强的安全性这与我们习惯的“越快越好”的区块链共识直觉形成了鲜明对比。3.4 一张表看清三个阶段的能力边界从系统设计角度看这三个函数的边界十分清晰。我整理了一份对比方便你把它们放进同一个维度里比较环节类比关键作用核心约束Join安检门接收并规范化外部请求输入必须具备可验证格式Accumulate批处理工厂推进服务状态、累积结果结果必须一致且有效Yield异步回调出口发外部请求并保留恢复点必须有明确的恢复机制Enact终审法院确认并提交最终状态只能处理已累积的有效结果这个表格的启发是JAM 的每一步都刻意边界分明原因是它想让验证者可以在不同阶段采用不同策略。有些阶段可以并行处理有些阶段必须中心化确认有些阶段可以交给异步任务等待。这种职责拆分构成了它与传统区块链最根本的差异。4. 代码级认知一个开发者在 JAM 上写服务需要理解什么4.1 Work Package 是服务的“最小执行单元”在 JAM 的开发模型里你不会直接部署一个“合约”而是提交一个可以被验证者执行的工作包。每个工作包可以包含多个工作条目Work Item它们一起被验证者纳入某个区块的累积流程。写服务时最需要理解的概念是你的服务不是被某一条交易触发的而是被持续累积的。每一轮验证者会检查你的服务是否有新的待处理工作包如果有就按规则累积执行推进一截状态。这套设计对开发者的直接冲击是“状态显式化”。你不能像写传统智能合约那样依赖调用栈和全局变量你的服务逻辑必须非常清楚地表达输入是什么、累积规则是什么、什么时候可以 Yield、什么时候算最终确认。4.2 不是所有服务都需要成为一条链过去如果你想在 Polkadot 上做一个新项目大概率会先考虑要不要拿插槽、要不要建链。JAM 改变了这个决策路径。预言机、随机数生成器、链上身份系统、ZK 验证聚合器、去中心化存储索引这些都可以作为独立服务运行而无需把自己包装成一条有独立共识协议的链。这带来的直接好处是工程复杂度的下降。你不必再维护一套自有的验证者节点流程、不同步机制和跨链调度逻辑只需要专注写好服务自身的执行规则。当然JAM 服务也不是完全没有门槛。由于中继链会直接验证你的服务状态转换你必须保证服务代码具备确定性和可复现性。你还要了解抵押与罚没的经济博弈因为无效工作包会导致提交方资产受损。4.3 目前的环境和工具还在快速演进期如果你现在就想动手建议先明白一件事JAM 尚处于部署与实现者竞争的早期阶段。灰皮书本身还在持续修订多个实现版本正在推进社区也提供了一些测试网和沙盒环境供开发者实验。从现有资料看最稳妥的起步路径是三步走先精读灰皮书中关于 Work Package、Accumulate 和 Availability 的章节把数据结构的定义理解透再选择一个已有的实现库跑通一个最简单的服务示例感受工作包从提交到累积确认的完整生命周期最后做一些简单的链上验证实验比如写一个只做加法运算的服务观察它在验证者之间的同步结果我强烈不建议一上来就模仿复杂的 DeFi 业务逻辑。JAM 的抽象层级和以太坊差异很大先用最小可执行服务跑通流程比一次性设计一个大型架构要稳妥得多。4.4 最容易踩的坑把智能合约思维直接搬过来在社区论坛里我看到不少新手会把 JAM 服务理解成“一个支持并发调用的智能合约”这其实是最容易踩坑的地方。智能合约天生适合原子化、短事务的操作而 JAM 服务更适合周期性的、可累积的任务。如果你的业务逻辑非常依赖低延迟的立即确认比如高频交易那现在不要急着迁移到 JAM。JAM 的累积和确认周期天然面向“可以容忍确认延迟”的应用场景比如预言机更新、跨链证明验证、ZK 批处理等。把面向的对象搞对了很多痛苦都会自然消失。5. 它真的能“重新定义区块链计算”吗和其他扩容方案的对比5.1 和以太坊 Rollup、Celestia、Solana 的定位差异任何一个新方案都不可能存在于真空里。JAM 对外宣传的“重新定义计算”能不能站得住脚得看它与现有主流路线之间的对比。以太坊的 Rollup 路线本质上是把执行从主链剥离让执行层以“证明提交”的方式回到主链。这个模型很成熟但有一个结构性痛点执行层仍然依赖一个个孤立的 Rollup 容器跨容器互操作需要额外的桥接和信任假设。Celestia 走的是数据可用性分离路线它不做通用执行只保证数据可查询。它能帮助很多项目低成本启动自己的链但验证共识仍然需要项目方自己解决。你可以说 Celestia 是一个数据库但它不是一个通用计算引擎。Solana 的全局状态模型则走了另一个极端一台高配的“单线程”计算机让所有状态都在一个全局内存里共享。这种模型的并行扩展能力在硬件极限面前会遇到瓶颈而 Solana 的异步执行也依赖外部调度器的精细规划。JAM 虽然也强调高吞吐和可扩展性但它的核心路线更接近“可验证计算网格”让多个服务在共享安全的环境下并行运行每个服务维护自己的状态由中继链统一验证。它不依赖分层也不依赖单一全局状态而是把信任集中在一组明确的验证函数上。5.2 和 Polkadot 2.0 / Coretime 的关系先有 Coretime再有 JAM很多读者可能已经注意到Polkadot 最近一年聊得最多的话题之一就是 Coretime 取代插槽拍卖。这是 Polkadot 2.0 路线图的第一阶段也是 JAM 落地的前置准备。Coretime 把“平行链插槽”重新定义为一种可灵活购买的资源让团队按月、按周甚至按需购买核心时间。JAM 则进一步把这种核心时间转化为“通用计算时间”直接执行服务的工作包而不是仅仅给一条平行链分配出块时间。可以理解为Coretime 改变的是资源分配方式JAM 改变的是资源使用方式。一个是经济模型升级一个是执行模型革命。两者叠加才能真正让 Polkadot 从“多链枢纽”走向“可验证计算中心”。5.3 需要冷静看待的挑战我对 JAM 的态度是积极的但也必须承认这套设计存在很大的不确定性绝不是所有人都能轻松驾驭。第一是脚本与执行环境的复杂度。中继链从一个调度器变成执行环境意味着验证者的工作量大增。即使有并行机制和异步 Yield验证者在面对大量服务同时提交工作包时仍会面临巨大的计算和存储压力。第二是安全模型的可组合性问题。当多种服务在同一套中继链上累积状态时一个服务产生的无效结果是否会污染其他服务灰皮书在可用性和罚没层面做了一些设计但实际对抗场景中的表现还有待检验。第三是生态迁移的惯性。已经建立在平行链模型上的项目要不要迁移、怎么迁移是一个牵涉大量工程和治理成本的问题。短期看JAM 更像新项目的选择而不是对存量系统的即时替代。5.4 对普通用户和生态观察者的判断建议如果你不是开发者只关心生态走向我有一个比较直接的判断办法盯住中继链实际执行的交易构成。如果未来一年中继链的区块里出现了大量来自非平行链服务的工作包并且这些服务在没有独立共识的情况下依然能稳定运行说明 JAM 的通用计算愿景正在兑现。反之如果所有流量仍然来自传统平行链那 JAM 可能还需要更长时间的磨合。6. 追踪 JAM 进展的几条实用路径6.1 三个真正值得关注的里程碑很多项目把白皮书发出来就消失了JAM 目前的推进节奏还算扎实。我个人认为接下来有三个真正值得关注的里程碑。第一是 Coretime 的全面落地。当插槽拍卖彻底退出历史舞台核心时间变得像云服务器一样可以按需购买JAM 的“服务”才能真正获得灵活的载体。第二是灰皮书的版本稳定性。如果灰皮书的接口定义和核心数据结构不再频繁变动意味着那“三个函数”的语义已经收敛可以实现协议层面的稳定。第三是 JAM 实现者竞赛的产出。Web3 基金会为 JAM 的实现设置了高额奖金第三方团队从不同语言、不同角度实现同一套协议会暴露很多灰皮书里没有写清楚的问题。这些问题被市场讨论和修复的过程就是 JAM 走向成熟的过程。6.2 必须澄清的三个常见误区这些误区我在各种文章里反复看到忍不住多说几句。第一JAM 不是“杀死平行链”。它更像平行链模型的泛化平行链可以作为服务继续存在只是不再需要独占一条链的身份。第二JAM 不是“Polkadot 的硬分叉”。它是一套新的中继链执行机制迁移过程会通过运行时升级和生态治理逐步推进而不是一夜之间替换所有节点。第三用“三个函数”定义计算不代表只有三个函数这么简单。它是指协议最关键的状态转换逻辑由少数几个入口约束具体代码仍然极其复杂涉及大量经济博弈和密码学机制。6.3 我的学习路径和建议如果你也对 JAM 感兴趣我个人的学习顺序是先看一页灰皮书中的核心状态转换图再读代码实现不要过于依赖二手解读最后是实际部署一个测试服务把 Work Package 提交和确认的完整路径跑通。这个过程读下来我最大的体会是JAM 不是在修补旧问题而是把区块链计算的底层抽象从“交易/合约”换成了“服务/求值”。那三个函数就像操作系统的系统调用定义了所有程序与内核交互的接口。一旦这套接口跑通中继链就不再只是多链网络的轴心而会成为真正意义上的可验证网络计算机。