数字货币: JAM 12-20 个月内交付？三位核心开发者揭秘 M1、PoP 经济模型与 ZK 未来！

点击查看 PolkaWorld 最新英文直播总结！

加入 PolkaWorld 社区，共建 Web 3.0！

JAM，这个名字已经被 Polkadot 社区讨论了很长的时间。随着 Gavin Wood 在 Web3 Summit 上抛出一连串重磅信息，大家对 JAM 的期待与疑问都达到了新高 —— JAM 到底是什么？它会给 Polkadot 带来哪些改变？它离正式上线还有多远？

为了让社区有更全面的理解，PolkaWorld 邀请到了三位直接参与 JAM 核心开发的嘉宾——来自 Acala 团队的 Bryan、JAM Rust 实现"FastRoll"的开发者 Junha，以及 JAM Zig 实现"JAMZig"的开发者、Polona 项目的联合创始人 Boy Maas。

三位嘉宾不仅深度参与 JAM 的技术落地，还在不同方向上探索着 JAM 的潜力：从多语言客户端实现到跨链工具链迁移，再到 PVM 的未来应用，他们是最能代表 JAM 现阶段进展的人。

在这期访谈中，他们将用第一视角带我们走进 JAM 的世界：

Gavin 公布的 JAM 重大更新到底意味着什么？
JAM 的代币上限（π × 10 亿）和 PoP（Proof of Personhood）机制，会怎样改变 Polkadot 的经济模型？
Milestone 1 的技术目标和进展如何？测试网何时上线？
ZK（零知识证明）未来如何与 JAM 结合？
JAM 的治理机制与灰皮书编辑委员会，又将如何影响协议的长期演进？

如果你想了解 JAM 的未来，以及它将如何重塑 Polkadot 生态的基础设施——这一期，不容错过。

认识三个 JAM 开发团队

Kristen：大家好，我是 Kristen，今天我们请到了三位来自 JAM 的核心开发者，他们正在直接参与 JAM 的开发。如果你有关注 PolkaWorld 或者 Polkadot 的最新动态，应该已经知道最近正在举行 Web3 Summit，而 Gavin 在大会上发布了一些关于 JAM 的重磅消息。社区这边也已经开始频繁向我们发来提问，所以我们临时组织了这场直播，希望能通过三位嘉宾的分享，帮助社区全面了解 Gavin 在 Web3 Summit 上公布的 JAM 的相关内容。

接下来的第一部分，我想先请三位嘉宾依次简单做一下自我介绍，说明一下你们在 JAM 项目中负责的部分以及目前的开发进展。虽然有些嘉宾已经是我们节目的老朋友了，但每次都有新观众加入，所以还是要麻烦你们重新介绍一下自己。那我们先从 Junha 开始吧。

Junha：谢谢 Kristen 的邀请。大家好，我是 Junha，我是第一次参加这个节目。

现在我正在开发 JAM 协议的 Rust 语言实现，项目名称叫做 "FastRoll" 。目前我团队只有我一个人，算是独立开发者。

这个项目我已经做了一年左右，现在正在为第一阶段的里程碑评审做准备，同时也已经开始推进第二阶段的一些工作。

Kristen：欢迎你 Junha！接下来我们请 Bryan 做一下介绍。

Bryan：大家好，我是 Bryan，来自 Acala 团队。目前我带领一个小团队在开发 JAM 协议的另一个实现版本，项目名叫做 "Boka"。

我们现在也在推进第一阶段的最终完善，并同步在更新一些链下组件，为第二阶段做准备。
另外，我们也刚开始了 PVM 重编译器的开发工作，不过目前还处在比较早期的阶段，离完成还有段距离。

Kristen：好的，谢谢 Bryan 再次做客我们的节目，Bryan 其实是我们第一个请来介绍 JAM 项目的嘉宾，很高兴你又来了。最后我们来欢迎 Boy Maas，我们之前也做过你的专访。

Boy Maas：是的，是的，大家好，我是 Boy Maas。我是 JAM 协议的 Zig 语言实现的独立开发者，我们的客户端叫"JAMZig"。

同时我还是 JAM 生态上一个项目的联合创始人，我们这个项目的目标是将 Solana 的工具链和 Solana 虚拟机（SVM）完整地迁移到 JAM 上。目前已经完成了初步的概念验证阶段，也就是说我们已经能跑起来一些基本功能了。

JAM 将在 12 到 20 个月内正式交付？

Kristen：欢迎你 Boy Maas，Polona 确实是个先锋项目，致力于吸引 Solana 开发者加入 Polkadot 生态，非常棒的想法！好，欢迎三位嘉宾的到来。

接下来第一个话题我想问 Boy Maas ，你参加了 Web3 Summit，我们已经在推特上看到了不少关于 Gavin 演讲的消息，但我想请你从第一视角来跟我们聊聊你的收获，你有看 Gavin 的演讲吗？可以跟我们分享一下你觉得有哪些重要的信息吗？

Boy Maas：当然当然，能在现场真的感觉非常棒。你可以见到 Polkadot 社区的很多成员，很多有趣的分享让人能真正感受到整个社区的动态，整个氛围都很积极、充满活力，也让人对未来充满期待。今天是最后一天了，我也很期待把这段经历带回去继续推进我们的开发。

Kristen：你有看 Gavin 的演讲吧？

Boy Maas：我看了，是的。

Kristen：你有什么印象深刻的内容可以分享吗？我们在推特上看到了一些文字信息，但还是希望能通过你们开发者的视角，用更简单易懂的方式讲给大家听。

Boy Maas：当然可以。Gavin 在演讲中提到了很多内容。他是个非常有远见的人，经验也非常丰富，所以他做出的一些决策和提出的新想法对整个社区的未来方向影响很大。

最重要的一点，就是他宣布了 JAM 的代币供应总量将硬性上限设置为"π 乘以 10 亿"（π × 1,000,000,000），这是一件非常重大的事情，会带来很多后续影响。

另一个重点是，他试图向 Polkadot 社区更清晰地传达 JAM 到底是什么。JAM 本质上是为了增强和支撑 Polkadot 生态，它的定位是助推整个生态的基础设施。其实大家现在都有一种在探索和适应的感觉：JAM 到底是什么？它能做什么？它如何与 Polkadot 主网协作？它怎么实现？

作为开发者，我们了解 JAM 的技术细节，但我也能理解对大部分人来说，现在还是处于"搞不太清楚 JAM 到底会带来什么改变"的阶段。大家都在试图描绘出这个 JAM 驱动的未来世界会是怎样的。

Kristen：听起来非常有意思。我还注意到 Gavin 提到 JAM 将在 12 到 20 个月内正式交付，你们的项目 Polona 应该也很依赖这个时间表吧？你们的开发进度会和 JAM 的时间线同步吗？

Boy Maas：是的，Kristen，你说得完全正确。我们其实没有刻意准备在测试网上线时就万事俱备，但根据现在公布的时间表，发现我们的计划已经完美契合，等到 JAM 测试网一上线，我们就可以立刻投入使用。等网络正式运行后，我们也会第一时间跟上。

什么是 JAM 的 M1？

Kristen：好的，很棒，听到这些进展很高兴。接下来我想把问题抛给 Junha。

JAM 最近发布了一个技术上的重大更新，并明确了第一阶段里程碑（milestone 1）的交付目标。但是，有些听众对 milestone 1 还不是很了解，不太清楚它具体是做什么的，进展到哪一步了。你能不能给我们介绍一下，milestone 1 具体包括哪些内容？测试网的进展如何？你预期大概什么时候上线？

Junha：当然可以。正如你提到的，JAM 的《灰皮书》（gray paper）最近更新到了 0.7.0 版本。Gavin在演讲中也提到，从这个版本开始，Polkadot Fellowship 可以开始评估 milestone 1 了。所以目前大多数在做 JAM 节点客户端实现的团队，基本都在为这次评估做准备。

milestone 1 的目标是交付一个能够"正确导入区块"的节点客户端，也就是验证 JAM 最基础的运行时逻辑。

具体来说，就是给定一系列区块（其中可能包括有效和无效的区块），客户端要能识别出哪些区块格式正确。对于有效区块，客户端需要能读取其中的外部数据，执行状态转换逻辑（也就是区块链运行时的核心逻辑），并最终生成一个新的链上状态。因为区块链本质上是一个状态机：给定一个初始状态，通过导入区块执行相应逻辑，就可以产生一个后续状态。

milestone 1 的评估，就是看你这个节点实现是否能在导入这些区块后，生成一个正确的后续状态。

评估方法也很直接：我们准备一批测试区块，然后比对不同实现生成的后续状态是否完全一致。这个状态结果可以用一个"垂直根"（vertical root）来概括，所以比对起来其实非常方便。目前已经有一个测试工具叫做 JAM Conformance Fuzzer，它可以自动生成很多带有随机数据的区块，并用来测试各个实现是否能得出一致的状态根。

我觉得这是个很好找出关键 bug 并及时修复的机会，为接下来的更复杂阶段打好基础。

Kristen：明白了，那测试网预计什么时候上线呢？

Junha：你是指 JAM 测试网吗？目前有些团队已经尝试通过自己编译的二进制文件进行跨实现互操作，但我个人觉得，真正可运行的测试网应该是在 milestone 2 之后才会比较成熟。

因为 milestone 1 主要验证的是节点的状态转换逻辑，这还不足以支撑一个完整的测试网运作。而 milestone 2 才会开始评估各实现是否完成了整个网络通信协议（networking spec）的实现。但目前这部分协议还不稳定，甚至还没写进灰皮书。一旦网络协议规范稳定下来，各实现完成了相应开发后，就可以进行节点间的互操作测试了。

那时候，就比较适合正式准备上线测试网。当然，也可能有些团队会提前做一些尝试，但我个人的计划是等 milestone 2 之后再加入测试网。

Kristen：好的。那你觉得 Gavin 在峰会上发布的这些新内容，会对你的开发进度产生影响吗？

Junha：我觉得他提到的大多数内容，更多是面向长期愿景的，所以短期内对我的开发计划不会有太大影响。我目前的重心还是专注完成 milestone 1，预计还需要几周甚至一个月的时间，才能交付一个完全符合要求的客户端实现。所以从目前来看，我的开发策略不会有实质变化。

当然，从一到三年这样的更长周期来看，这些新方向可能会产生影响，但就现在而言，我还是会专注把 milestone 1 做好。

如果 PoP 替代 NPoS，会带来什么影响？

Kristen：明白了，谢谢你的分享！接下来我要问一个"硬核"的问题给 Bryan，是关于代币经济的。我们都知道，开发者通常不太愿意评价经济模型的效果，但这是社区最关心的问题之一。Gavin 在峰会上提到，将用 PoP（Proof of Personhood）替代 NPoS，同时验证者的奖励将变为固定，并引入年减半机制限制 DOT 的总供应。你作为开发者，怎么看这些变化？你认为最大的影响是什么？你个人是否支持？有没有一些担忧或建议？

Bryan：确实，这是一个很大的变动。

那我先简单回顾一下背景：无论是工作量证明（PoW）、权益证明（PoS），还是现在提出的"人格证明"（Proof of Personhood，PoP），这些机制本质上都是为了保护网络安全，防止双花、链分叉等攻击。

每种机制都有其运行成本，比如 PoW 的成本体现在区块奖励上，同时需要大量的电力和算力，而 PoS 则是需要给质押者发放奖励。

这次的新人格证明在奖励机制上有很大不同。Polkadot 原本用的 NPoS（提名权益证明），虽然没有 PoW 那么昂贵，但依然存在一个问题：为了维持网络安全，我们要不断发行新代币来奖励验证者和提名人，这会带来通胀。

现在引入 POP 的目标，就是降低网络安全的运行成本，不再依赖经济激励或惩罚，而是转向了新的方式——具体怎么实现还不清楚，但核心设想是"一个人一票"，如果这能行得通，那作弊会变得难很多，网络也更容易保障安全，这样就不用像现在这样支付大量代币作为奖励了。

从网络角度来说，这能大幅降低运营成本，是件好事。但也有副作用，原先很多人依赖提名质押来获取更多代币，现在这套收益模式基本消失了。虽然还有新方式获取代币，但数量会大幅减少。不过另一方面，作为持币人，如果网络支出减少，你的代币价值会提升，所以整体上我认为是积极的。

但这也带来一个潜在的利好：对 DeFi 的促进作用。当质押收益降低，用户可能会将资金转移到其他 DeFi 协议中，比如借贷、流动性提供等，从而激活 DeFi 生态。

当然，具体影响还需要看到完整细节，即使有了完整设计，可能也很难准确预测它的全部影响。但就我个人来说，我是倾向于正面看待这些改变的。

Kristen：我觉得从短期来看，对验证者可能确实是打击比较大，毕竟他们的收入可能大幅减少，你觉得这会在初期造成一些问题吗？

Bryan：我认为这要看过渡的方式怎么设计。比如，不会从某天起突然彻底改变，而是渐进式的，就像代币供应按年减半，我们不会从第一天就把通胀砍到零，而是每年慢慢减，边走边看，这样大家就有时间适应新变化，调整策略。

毕竟，我们还是要确保网络安全，得让验证者至少能覆盖成本还有些利润，也得让大家有动力去提名验证者、选择优秀的验证者。这些前提不会变，只是不想再支付那么高的奖励了。所以变化肯定会有，但希望新的经济模型能把影响降到最低。

什么是 zkJAM？

Kristen：确实如此，社区意见也很分化。一开始大家都呼吁"减少通胀"，现在要走向通缩阶段了，又有人开始抱怨。我觉得这个方向是好的，谢谢你分享这么深入的观点。

接下来我们来聊一个技术话题—— ZKJAM。这个词是我在 Gavin 的 PPT 上看到的，看起来还比较概念化。但"零知识证明"（ZK）这几年在 Web3 领域非常热门，很多人说 ZK 是 Rollups 和可扩展性的终极解决方案。如果未来 ZK 和 JAM 结合，会是怎样的场景呢？我想听听你们三位的看法。Junha 你先来吧。

Junha：好的。Gavin 在演讲中把 JAM 比喻为一台去中心化的"超级裸机计算机"，而在它之上的各种服务，就像运行在硬件上的操作系统，比如 Windows 或者 macOS。

那么如果未来 ZK 被整合进 JAM，从服务开发者或应用开发者的角度来看，其实不会带来特别"颠覆式"的变化，整体的开发体验和用户体验应该基本保持不变。

就算 JAM 的安全机制，从目前的"基于审计的重执行模型"，升级成了"基于 ZK 证明"的模型，只要这个升级是经过严格验证、效果更好，那就完全值得采用。

所以我觉得，要是能明确 ZK 和 JAM 适配得很好，而且比现在的方式更有利，那升级是可行的，整体体验也不会有太大变化。

Kristen：谢谢分享。我想刚才那一段可能有些听众已经被技术术语绕晕了，不过别担心，我们会有中文版本的回顾文章，大家可以反复阅读来消化内容。接下来我们请 Bryan 来谈谈你的看法。

Bryan：我觉得大家需要先区分两个概念：一个是 JAM 作为基础设施上承载 ZK 安全的 Rollup，另一个是 JAM 本身通过 ZK 来保障安全性。这两者是完全不同的。

通过 JAM 里的 PVM，任何 ZK 相关的算法或架构，比如新的 ZK-Rollup 协议，都可以作为一个服务部署在 JAM 上。这部分是比较容易实现的。

但如果要让 JAM 本身通过 ZK 来保障其安全，那就涉及大量的前沿研究以及对现有算法的优化改进。目前来看，这还处在非常"前沿"的阶段。这完全取决于现状——现在的算法可能还不够快、不够便宜，但未来谁也说不好，也许明天就有人发明了一个效率提升 100 倍的新算法，那整个局面就会被颠覆。

所以说，如果未来出现了真正有用的 ZK 整合方式，能够让 JAM 变得更安全，我当然支持使用它。

Kristen：明白，希望这个领域真的能有突破。Boy Maas，你作为资深开发者，对这个话题怎么看？

Boy Maas：其实我觉得 Bryan 和 Junha 已经说得很全面了。我喜欢 JAM 的原因之一，就是它是一个非常实用主义的系统。它的设计选择都是为了让系统真正运行起来，能够执行计算。就像 Bryan 说的，目前用 ZK 来做这一切实在太昂贵、太不现实。所以我设想，未来或许可以采用一种"混合模型"，即传统的审计方式和 ZK 并行使用。

但现在来看，ZK 的成本太高、太不实用了，不过未来 12 个月到 5 年间，ZK 领域一定会发生很多变化。如果 ZK 真正变得高效，那绝对是很有吸引力的技术，也有可能重新定义我们整个系统的安全模型和架构方式。

不过现在来说，混合模式可能更实际：既保持实用性，又能让那些确实需要 ZK 安全保障的应用用上这项技术。

JAM 将成立灰皮书编辑委员会

Kristen：谢谢各位的分享。那我们接下来进入下一个话题：JAM 的治理机制。

Gavin 将继续担任《灰皮书》的主编，同时他还宣布将成立一个"灰皮书编辑委员会"，这个委员会将由深度参与 JAM 开发、具备技术能力的贡献者组成，未来将共同决定 JAM 协议的更新、优先级与关键决策。那我想问问各位作为开发者，你们觉得这种由委员会来治理协议的方式是否可行？是否可能出现"偏离初衷"的情况？如果发生了，应该怎么应对？我们先从 Boy Maas 开始。

Boy Maas：我觉得这个问题非常有意义。对于这样一个高技术门槛、非常专业的领域，有一个委员会来负责《灰皮书》的更新，是非常合理且必要的。因为做出这些决策的人，必须对 JAM 的底层原理有非常深入的了解和长期的实践经验，才能做出明智的判断。而由创始人 Gavin 来带领这个委员会是非常合理的，所以我完全支持这种治理方式。

Kristen：所以你认为协议由一个专业团队集体决定，是好事？

Boy Maas：是的，完全同意。

Kristen：好的，Bryan，你怎么看这个问题？

Bryan：其实你可以这么理解：所有项目本质上都是由某种"委员会"来治理的，只是规模和人员不同。区别在于有没有把治理流程明确定义出来。

我认为明确写下治理流程本身就是一种进步，至少大家都知道更新是如何决定的，这样做可以提高透明度，也便于未来对流程进行优化。要是连规则都没有，那就无从改进了。

灰皮书的内容真的非常复杂，几乎所有 JAM 实现团队的开发者都反复读过多次不同版本的内容。但老实说，可能除了 Gavin，没有人能 100% 理解它，甚至可能 Gavin 自己也不能完全掌握每个细节。现在还有很多人参与修改文档，比如修错别字、调整公式、优化逻辑，这本身就是一种协作过程。

所以我个人的观点是：只有在这个领域有多年经验的人，才适合参与修改灰皮书。因为一个微小的改动可能会带来巨大的连锁反应。毕竟这关系到 Web3 的未来，甚至互联网的未来，涉及大量资产安全，必须慎之又慎。所以透明和开放很重要。大家可以提出建议，但你需要能证明自己真的理解了你提的建议，否则噪音会淹没有效意见。

Kristen：所以你认为，这个委员会还需要建立一套机制，比如谁能加入，怎么组织成员等等。因为每个人都有自己的意见，如果没有规则，很容易产生分歧，甚至偏离初衷。

Bryan：所以我们才需要智能合约、明确流程，把一切都写下来。如果规则白纸黑字，谁都能监督执行，全程公开透明，那偏离的可能性就小多了。要是都在小黑屋里搞暗箱操作，大家都不知道进展，那才容易走偏。所以透明度很重要，尤其是如果流程能通过智能合约强制执行，那这套机制才有长期存续的可能。

Kristen：明白，我记得比特币社区也有类似的开发者委员会来推动发展。

Bryan：是的，比特币社区有一群核心开发者，但最终决策其实是通过分叉（fork）来决定的，哪一条链获得最多算力，哪一条就胜出。

Kristen：明白了，谢谢你的解释。那最后我们来听听 Junha 对这个话题的看法。

Junha：我认为成立编辑委员会是一个非常自然且有意义的步骤。JAM 这个项目本身就非常特别：在还没有开发出完整可运行的软件之前，先发布了一份完整的技术规范文档（灰皮书）。这份文档里面包含了大量数学公式，用来定义系统的输入输出行为。制定文档先于开发，其实就是为了追求更高的去中心化和更强的系统韧性。

正因为如此，灰皮书自发布以来已经被多次修订，未来甚至在 1.0 版本发布后还会继续修订。

随着更多团队开始实现 JAM 协议并搭建测试网，我们一定会发现有些部分可以进一步优化，让协议在执行效率或可实现性上更好。所以就 JAM 项目的性质而言，灰皮书在主网上线后几个月内可能还会持续演进，甚至可能出现硬分叉。

这种情况下，有一群人共同负责协议规范的开发，显然比单靠作者一个人要好。

当然正如 Bryan 所说，透明度也非常重要，委员会的决策过程一定要公开。同时，我也希望更多使用 JAM 协议的团队，主动去参与文档审阅、校对和反馈，而不是只是"相信 Gavin 说的就是对的"。通过这种更主动的参与方式来发现改进点。这是个很好的开始，值得期待。结合 JAM 项目的特性，这种让规范不断升级的方式很自然，也很合理。

我们可能低估了 JAM 会为区块链带来什么

Kristen：好的，这确实是一个很好的开始。如果整个过程是透明的，那将非常棒。谢谢你们的分享，我想我们已经聊完了今天准备的所有话题。

临近结尾，大家有没有什么补充的？关于 JAM、关于 Web3 大会，还有没有什么想说但刚才没来得及讲的？那我们先从 Bryan 开始吧。

Bryan：没什么特别要补充的了。JAM 本身是一个底层基础设施，它虽然重要，但不是全部。真正重要的是建立在 JAM 之上的服务和应用——用户其实并不会直接使用 JAM，而是使用基于 JAM 搭建的各种服务。

所以，JAM 的上线只是实现最终目标的第一步。我们更应该关注那些运行在 JAM 上的服务和应用，这才是真正影响用户的东西。所以未来还有很多事情要做，我们的关注也不能只局限在 JAM 核心协议本身上，还要关注在它之上搭建的所有东西。

Kristen：好，谢谢你。那 Boy Maas，关于 Polona 或者 JAM 你还有什么想补充的吗？

Boy Maas：当然。首先还是想说 JAM。我记得之前在里斯本，Gavin 做了一次关于 JAM 的分享。当时我就有个强烈的感觉，就是我们可能低估了这个平台会为区块链社区带来什么。

JAM 所提供的"带宽"和灵活性，是之前任何区块链都没有实现过的。我觉得它已经可以算是区块链发展历程中一个重要的里程碑了，特别是在它能够承载的新应用方面，真的非常独特。

再补充一个消息，我们的 Polona 项目进展也非常快，目前已经在 JAM 上跑出了一个概念验证（PoC）版本。我们已经把 Solana 的 SVM 搬运到 PVM 上了，也就是说你现在可以直接把 Solana 的 bytecode 放到 JAM 上运行，而且包括跨合约调用的功能也已经打通了，一切都可以运行了，这真的非常酷。这也体现了 JAM 服务的强大能力。

Kristen：太好了，谢谢你！最后我们请 Junha 也来补充一下。

Junha：我希望会有更多人开始关注 JAM、Polkadot 和 Gray Paper。我真的很希望能和更多人建立联系，分享一些想法。

现在 JAM 的客户端还在开发中，所以还看不到太多"成型"的应用示例。虽然 Gavin 的团队展示过一些 demo，但目前还没有非常丰富的实际案例，足以让人真正"信服"这个系统到底能做什么。

不过，我认为，只要你对 Web3 背后的理念感兴趣，想要真正推动这个行业的边界，那么 JAM 会是一个非常值得深入研究的项目。我自己这段时间一直是一个人独立在做这个项目，所以我真的很希望能认识更多志同道合的朋友，哪怕只是一起读读 Gray Paper、讨论一下都很好。希望我们可以一起交流想法，甚至一起打造一些新的东西，尤其是在我们完成节点交付之后。

Kristen：好，谢谢你的分享，也非常感谢几位嘉宾今天带来的精彩观点和见解！感谢每一位听众今天的参与，建议大家去关注我们几位嘉宾的 Twitter，账号可以在 PolkaWorld 的公告中找到。无论你是普通用户，还是开发者，了解 JAM 的最新进展都非常有价值。谢谢大家的收听，我们下次见！再见啦！

原视频：https://www.youtube.com/watch?v=TdNbwiCxE-w