时差记者 | JAM：写作者众，协议为公，建构仍在进行

导读

南欧的加密生态进展如何？和 Gavin Wood 只隔几个街区的里斯本，建设者们又如何在波卡链上进行反套路的去中心化技术实现？在果酱一样鲜甜的开发现场，有开发者兼乐手的乐队、有一场场开发想法的“即兴演出”，更有真正实现“技术生产权下放”的干净的结构作为新事物的车间。正如文章中所写的：代码不仅是工具，更是制度结构本身。它回应了比特币前期的理想主义残响，也唤起了密码朋克与 GNU 世代那句未被遗忘的信念：“实现本身就是一种政治实践。”

是初夏。里斯本从不真正冬眠，但到了这个季节，什么都开始变得轻盈——街头的人多了起来，海风穿过亚麻衬衫，阳光在广场的石板上打转，crypto event 也开始在城市的各个角落浮现。

我们去了 JAM 测试网的发布现场。那天晚上，Parity 把办公室临时变成了一个 DJ 派对。位置在 Chiado，老城区的心脏，桌子上摆着一排罐装的果酱，上面印着 “JAM”。是的，他们把这条链昵称为果酱，也真的做了果酱。

现场聚集了来自全球的 35 个 implementor 团队，他们刚刚从郊区回来，去参观了那个叫做 JAM Toaster 的大型数据中心——藏在 Polkadot Palace 附近，位置保密，只有受邀的人才能进入。有人说那里像个未来装置：高性能机器藏在游泳池下，以泳池来冷却机器，以机器来加热泳池。像是科幻小说才会出现的情节。

那是 JAM experience 的最后一晚。测试网上线了。Gavin Wood 讲系统结构，像在玩爵士，不太在意语速，也没有什么起承转合，屏幕上跳动着运行画面，他只是边演示边随手讲讲他的技术，好像讲的是哲学。情不自禁处，不时起身比划，身体与思想的即兴演出。

再后来，音乐开始了。极客们自己上台玩——有人打电子鼓，有人弹电吉他，声音很大，但没有喧哗的成分。大家一边跳舞，一边聊代码，或者不聊，只是喝酒、笑、走来走去。风穿过开着的窗。那是个轻盈的夜晚。系统还没稳定，规范仍未完全，谁都不知道 milestone 完成之后会怎样。

但那晚，大家都在这里。天南海北的人，各自写着不同的版本，却此时此刻身处同一个房间。

故事可以追溯到一年前，Gavin Wood 发布了一份名为 JAM Gray Paper 的技术草案 [1]。他只是以极简的语言勾勒出一套执行架构，并设立总额 1000 万枚 DOT 的激励池，向全球公开招募——任何团队、任何语言、任何方法论，只要愿意实现这份设计，皆可参与。这便是 Join-Accumulate Machine，简称 JAM 的起点。

这不是一次外包式的工程项目，而是一次有意制度化的实验。JAM 将“协作”嵌入协议诞生的原初环节，通过 clean room 并行开发、milestone 测试验证、fellowship 等级机制等结构性设计，使链的生成不再依赖中心化的团队、路线图或权威仓库，而由网络中多点分布的开发实践共同推进。

在区块链发展史中，这是一次激进的去中心化协作实验。以太坊、Solana、Aptos 等主流公链，无不由少数公司或基金会在封闭环境中完成架构设计与初始实现，即便后期开源，也始终保留着“作者中心制”的逻辑结构。JAM 与之相反：没有 canonical 实现，没有官方路线图，甚至 Gavin Wood 本人也不再写一行实现代码。他所提供的，仅是一套协议框架，以及一整套用于分布式协作的制度装置。这一结构将“协议的存在”交由集体实践来完成，而非由单一主体宣告。这不仅是工程方法的转变，更是技术生产权的重新分配。

在由中美主导的区块链体系中，技术快速商品化，被纳入投资与平台的逻辑中。而 JAM 作为一个起源于欧洲的链级实验，延续的是这方土地上的自由软件与工程哲学传统——构建不是为了市场，而是为了共识；代码不仅是工具，更是制度结构本身。它回应了比特币前期的理想主义残响，也唤起了密码朋克与 GNU 世代那句未被遗忘的信念：“实现本身就是一种政治实践。”在今天，“去中心化”已成商业套话。JAM 所代表的，是一次拒绝产品化、领导化与模板化的技术政治尝试。

这不仅是一次区块链技术史的切片，更是一份关于共识、秩序与协作如何发生的现场笔记。

人物

在那个初夏的 testnet launch party，我们认识了 yc。她站在人群中，粉红挑染的发色醒目，有着日漫里才会出现的公主切发型，身上却穿着再寻常不过的那种开发者夹克——紫色、防水布料、袖管鼓鼓的那种。她是 JAM implementor 之一，来自台南的 technologist 女孩。

你很难不注意到她。既像个小朋友，第一次来欧洲什么都很好奇。论起技术的历史又如数家珍，像一个早已看过行业沉浮的老人。那种“年轻的老程序员”的气质——早慧的、安静的天才极客，心里运行着另一套时间系统。

从国中起，她就开始学编程。那时候没有人教她，她就一个人上网搜，跟着论坛写，从 Java 到 C，再慢慢摸到 Rust。在高中她又自修完了大学课程，在研究生入学读到中途，就跑去微软工作。但传统公司的节奏不适合她。流程繁复，节奏迟缓。于是转行做直播，一个完全相反的世界，但那种生活也不是答案，投入与产出不成正比。

于是她停了下来。去年恰好学校复学还没开始，她作为技术负责人加入了一个初创团队。合伙人看到了 JAM Prize 的 open call，也看到了那封没有代码、只有结构草图的灰皮书，于是他们决定开始动手。

在我们的聊天中，她的叙述提供了一个关键视角：当权力被解构，制度如何依然被集体实践持续生成？

以下为她的采访文稿。

第一章：出走系统，进入协议

开端：从分布式技术，到一纸灰皮书的回应

早在 2016、2017 年，我就已经接触过分布式系统，也对区块链略有研究。这次刚好有机会重新投入这个领域，发现 JAM 是传统的分布式技术用于区块链实践的创新尝试。JAM Prize 竞赛的奖金看起来相当诱人。出于经济现实的考虑和时间自由度的需求，我们决定参与其中。在选择开发语言时，我个人对 Rust 比较熟悉，但团队中其他成员之前在台湾做博弈项目管理时用 Go 更多一些，因此最终我们还是选择了团队成员更熟悉的 Go（注：选择不同语言会进入不同的奖金池，详情可见 appendix）。

我对波卡生态一直有所关注，认为波卡的独特之处在于它敢于开创，而非简单地在公链之间进行速度或费用的竞争。相对于其他公链，波卡已经在速度和费用方面做得足够领先，现在的主要优势在于创新。波卡生态未来的两个发展方向，一方面是在生态系入口的建设，另一方面则是 JAM 这类全新协议的探索。JAM 是对公链技术的全新尝试，因此不适合直接与其他现有的公链进行横向比较，而更应该被视为开创新技术的一个独特方向。

我们团队由于是最近才加入波卡生态的，因此目前正在等待 JAM 竞赛结束后的等级审核，预计初始等级会是 Fellow Rank 3。Fellowship Ranks 的制度设计是有意义的，它通过等级的设立提高了成员参与生态建设的积极性与忠诚度（注：Fellowship Ranks 是波卡独创的游戏化生态身份系统，详情可见 appendix）。这种机制鼓励人们持续维护和升级已有的协议层技术，使基金会能够长期留住真正熟悉 JAM 的核心贡献者。虽然等级制度可能带来一定的竞争或导师制的关系，但目前阶段仍以团队协作为主，尚未出现传统公司的上下级氛围。整体来说，这种等级制度有助于生态成员明确自身定位，也提供了一种逐步进阶的激励机制。

JAM Experience：代码之外的生活、文化与友谊

作为 milestone 1 工程的阶段性收尾，官方在今年 5 月邀请所有 implementor 团队来里斯本办公室进行为期一周的聚会。在名为 JAM Experience 的体验周期间，最令我印象深刻的并非技术讨论本身，而是整体社区的氛围与交流方式。这不是技术研讨会，或者行业峰会，氛围比想象中更为轻松惬意。关于工程本身的讨论虽然重要，但仅占了三成左右的时间，大部分时候是团队成员间轻松的交流和娱乐活动，比如乐队表演，看足球赛，这种边工作边享受生活的节奏让我感到非常新鲜。

不同文化背景的团队也展现了鲜明的差异。比如亚洲团队倾向于直接讨论技术和收益，欧洲团队则更加轻松随性，乐于交流工作之外的兴趣爱好和文化活动，而美国团队更多地会进行轻松的 small talk。这次体验也让我意识到，不同地区对于开源社区的参与程度确实存在差异，尤其亚洲团队相对较少，这或许也与亚洲整体的开源文化尚不够深入有关。程序员的生活不能仅仅只有代码。总体而言，这次 JAM Experience 带给我的不仅仅是技术的启发，更是对社区文化和跨文化交流的深刻感悟，极大地丰富了我对未来工作的理解与期待。

第二章：规范未明，共识先行

Gray Paper：由「规范驱动」的开发过程

必须坦率地说，在实际开发过程中，Gray Paper 所提供的规范非常简洁，仅覆盖整个 JAM 架构的约三分之一，主要聚焦于状态转换函数（STF）逻辑。对于像节点层搭建、网络协议设定（如 QICLPN handshake）、连接类型（如 UP、CE）等关键部分的细节定义都没有涉及，尤其是 compiler 的处理几乎完全空白。

这意味着如果没有分布式系统或协议开发的经验，仅靠 Gray Paper 很难支撑完成后续的里程碑阶段。我们团队从 0.3 版本一路迭代开发至 0.6.5，过程中经历了大量重构与标准更动。这种反复确实影响了开发效率，也让测试的覆盖度受限，因为官方负责测试的人员似乎也较为紧张。

不过我也能理解 Gavin Wood 的出发点：Gray Paper 本意是提供一套最基础、最核心的架构逻辑，更多细节应由各实现团队依据上下文和目标进行具体设计。这种策略本质上激发了不同团队对相同协议的多样化实现探索，也许正是 JAM 实验精神的一部分。

JAM Milestone：异步考试的小步舞曲

JAM 当前阶段并没有严格的技术路线图，也尚未形成固定的标准评审机制。这种情况下，不同团队的实现方式与规范取舍自然存在差异。

不过 JAM 的 milestone 制度某种程度上起到了“标准答案”的作用：Milestone 1 和 2 更像是选择题，通过提供测试集与预期结果来检验实现是否一致。因此，这两部分的争议相对较小。而 Milestone 3 至 5 更接近开放题或效能测试，评审团队会关注实现方式的安全性、效率以及是否满足协议原则。这就留出了更多探索空间，各团队也可以在结构设计上尝试最优解（注：Milestone 为工程开发的审核标准，详情可见 appendix）。

整体来看，JAM 的协作方式有点像一场“异步考试”——答案对就能过，过程因人而异。我们在 Matrix 或 Element 讨论组中，也会不断交流、验证彼此的方案，形成一定程度上的非正式共识。这种由下而上的一致性形成机制，与 JAM 所倡导的开放协作理念相辅相成。

JAM Prize 的开发虽然没有传统意义上的产品负责人或项目经理，但每个团队都可以根据 Milestone 的阶段性要求自主提交实现版本。我们团队的协作节奏是每天晚上例会统一推进，其他团队之间也会不定期发起自发性的集体会议讨论。

实现“撞车”的情况理论上会发生，尤其是在逻辑结构比较接近时，但架构实现上仍然存在差异。评审时会根据各团队的 Git 提交记录和实现细节，判断是否为独立完成。目前的评奖方式是多团队并行被采纳，避免了强烈的零和竞争，也促使大家更愿意在架构设计上互相取长补短，而不是争做“唯一方案”。当然，要走到 Milestone 5 仍有极高门槛，并非每个团队都能坚持到最后。

虽然官方原本预计 Milestone 1 会在六月底开放提交，但实际上很多团队已经提前在推进后续阶段的任务，哪怕有些规范还未完全敲定。某种意义上，开发者社区正在反向推动官方规范的成型，我们一方面紧跟 Gray Paper 的测试进度，另一方面也在和 Gavin 及核心团队讨论架构细节，为后续版本的标准制定出谋划策。

协作：共识不是预设，而是多线程生长出来的

在 JAM 的协作过程中，其实大部分时候并没有出现特别剧烈的冲突，更多的是对实现逻辑或架构选择的质疑和讨论。印象深刻的一次，是我们和其他团队在对比测试集输出时发现数据不一致。我们反复对照各自的实现，发现可能是某些接口调用顺序或者编码格式上不一致，而不是逻辑本身错误。

后来另一个团队放出了他们的测试资料，我们也提供了自己的版本。社区就围绕这两个版本展开了验证和比较。最终，我们没有争论谁对谁错，而是共同找出兼容性最强、与官方预期最接近的方案，并将其作为后续实现的参考版本。虽然 JAM 官方的响应速度无法像开发者这么快，但他们也会跟进社区的实践成果，必要时采纳我们提供的路径。这种双向反馈机制，是我在很多“规范驱动”的项目中少见的宝贵经验。

我认为 JAM 当前这种去中心化的协作方式，在短期内的确可以维持秩序，尤其是在参与团队数量尚可控的情况下。即便未来扩展到几十、上百支团队，我也相信会自然地形成多个“聚落”型协作小团体，通过熟人网络维持节奏。

更长远来看，是否可持续，很大程度上依赖于社区成员的“可持续性”——你需要愿意持续开发，但现实中很多人还有工作、学业、生活压力，而且奖金的激励是后置回溯，但许多人无法承担前期花销。所以我认为 Fellowship Rank 的存在非常关键，它本质上是基金会为生态中真正活跃的人“托底”，确保核心架构不会因为志愿者的流失而中断。

至于“开源协作”的定义，我觉得 JAM 的实践其实处在一种“半开源”状态。虽然最终成果将是开源的，但因为目前有 clean room 机制，团队之间并不能直接查看彼此的代码，更多是一种基于共识的并行构建（注：Clean Room 是一种通过信息隔离、文档驱动开发、流程审计来保证原创性知识产权的工程方法）。但即便如此，这种分布式协作已足够激发出多样化的实现方案，推动整个协议向更完善的方向演进。

挑战：在未定义之上，工程中的不安与应变

规范驱动带来的最大优势，是让没有经验的开发者在短时间内迅速掌握分布式系统的架构精髓，协作中成长的密度极高。尤其对那些第一次深入协议层开发的团队来说，这是一次“长期高强度战争式”的学习。

但它的陷阱也很明显：如果你太早封闭开发、只按自己的节奏推进，可能几天后整个社区的方向就变了，你的成果就变成了“白做”。因为规范本身仍在动态演进，很多时候三天前的“共识”五天后就已不再适用。如何在执行力和敏捷适配之间找到平衡，是每个团队都要面临的挑战。

在跨团队的开发协作中，处理混乱的信息流很“苦恼”——信息量过载已经是开发过程中的默认背景噪音了。我们每天都面对海量未读消息，更别说是在像 Element 这种加密为主、可用性为辅的通讯工具上。

说实话，Element 是我用过最难用的协作平台之一：文件难找，而且因为安全因素会挡住图片，Gavin Wood 连图都看不到。我觉得，它可能也就比 ICQ 稍微好用一点吧（笑）。但我理解 Element 优先保障安全和隐私，这是它存在的初衷，只是这也让“信息检索”这件事变得极为低效。

我的解决办法很实际：我自己只做定期查阅，但让团队中的其他成员轮流关注频道消息。他们会把 Element 中的聊天记录导出成纯文本，然后统一整理成文档，帮助我们筛选出重点内容。社群甚至提供了个小工具自动化提取文字，避免一行行手动翻滚，这样就能在信息混沌中捕捉信号。

整个开发周期里，我最焦虑的时刻是在处理 PVM 的 interpreter 和 compiler 实现时。分布式系统本身我比较熟悉，但编译器相关的细节我原本并不擅长。更关键的是，那段时间 specs 还没敲定，社区对 recompiler 的技术路径也没达成统一。我陷入了一种“要不要先做？做了会不会被推翻？”的模糊状态。但好在，随着后期 JAM Experience 的面对面讨论，我对这块的理解逐渐明朗，迷茫开始退散。

第三章：试验之后，未来何往？

角色：主网上线之后，自由选择的分岔路口

主网上线后，我们这些 implementor 的角色肯定会发生转变，但不会结束。Fellowship 机制将继续推动核心开发者对 JAM 协议进行维护与更新。JAM 1.0 只是开始，后续还有 1.1，甚至可能向量子计算兼容性等更前沿方向拓展，因此仍需要一批深度参与者长期推进核心协议的迭代。至于是否投入布道与教育，更多是个人或团队的选择。一些团队可能更偏向去做 service 层的应用开发，另一些则可能希望成为社区连接者。

全球教育目前既有自发的社群提案机制，也有基金会参与的支持结构。最常见的是通过类似 Polkadot Assembly [2] 的平台发起提案，说明你希望在哪个地区推广 JAM，并提交计划与预算。社群成员会对提案进行评论和投票，若获得支持，即可获得资金与协作资源，推进课程、教材、线上活动等落地。

我认为这套机制很值得肯定。虽然确实存在一些“大票仓”影响力过重的问题，但至少它保留了参与感和治理逻辑，相比很多“伪去中心化”的项目要诚实得多。比如现在中国市场就有团队（如 lollipop）正在着手组织 JAM 的教育内容。类似 PBA（Polkadot Blockchain Academy）这样的经验，也为大家提供了很好的示范。

未来：波卡2.0时代，如何在公链之战中再次破局？

参与到现在，我最大的兴奋来自于：我们正在共同参与构建一个全新的底层框架。这种感觉很不一样，你不会觉得自己只是某个庞大系统中无足轻重的小螺丝，而是真正在推动一整代区块链技术的范式演进。

但说实话，让人沮丧的点也很明显——Polkadot 的营销还待提高。我过去做直播时常说：“如果你的曝光不够，就算你再优秀，也没人发现你。”波卡的产品本身可能极好，技术基础雄厚，但知名度不够高，注定只能留住极少数用户。相反，一些技术不那么成熟的项目，只靠强营销就能吸引上百万用户。

我也不清楚他们对推广的态度是怎样的。过去他们试图通过赞助足球队、赛车队等手段扩大影响力，但看起来不太接地气。我并不是批评这些尝试本身，而是觉得缺少一套连贯的 narrative 和社区运营策略。如果 Polkadot 想要在下一轮公链竞赛中站稳脚跟，就必须更清晰地回答这个问题：我们要如何让更多人了解、理解并使用 JAM？目前看起来，Solana、Sui 之类的新兴公链更能吸引年轻开发者，而 Polkadot 如果还想抢占未来一代 builder 的心智，就必须在 narrative 和运营方式上做出改变。

Appendix：JAM Prize

Reference

[1] JAM Gray Paper

[2] Polkassembly

[3] Gavin Wood: The Gray Paper Interview - JAM & the Future of Polkadot - Behind the Code: Web3 Thinkers

[4] 波卡JAM升级在即，或将迎来大爆发，普通人能从中获得哪些红利？