加入 PolkaWorld 社区，共建 Web 3.0！

接着昨天的文章，PolkaWorld 今天继续为大家带来 JAM 实施团队对 JAM 的解释、以及对发展现状的分享！

不论你是一个想要加入 JAM 的开发者，还是看好 JAM 未来发展的普通用户，这篇文章都值得大家去阅读和学习！

该内容较长，PolkaWorld 将分为两篇来发布，本文为下篇，主要涉及以下内容：

  • JAM 的核心应用场景是作为国家级的基础设施？

  • 如何加入 JAM 开发？

  • JAM 的治理体系未来会怎么演变？

  • JAM DAO 的目标是什么？

  • JAM 的数据存不住？24 小时后会消失吗？

  • 没有什么在 Polkadot 上绝对做不到的事情，只是有些事情在 JAM 上更容易、更高效

  • 为什么 Polkadot 的治理要搬到 Asset Hub，而不是直接在 JAM 上运行？

  • JAM 对整个区块链市场有什么影响？

  • JAM 协议的开发分为几个阶段？

  • 这么多的 JAM 客户端最后都会被使用起来吗？

  • 开发者期待 JAM 生态中有什么样的功能或工具？

  • JAM 如何提升 Polkadot 未来的用户体验？

继续阅读，查看全部内容！

上篇《JAM 是构建真正 Web3 的唯一路径？听听这些 builder 怎么说》

JAM 的核心应用场景是作为国家级的基础设施？

Q1：关于 Polkadot 在去中心化程度上领先其他区块链的说法。你觉得，各国政府、机构、大公司，真的准备好完全去中心化了吗？还是说他们更倾向于选择像以太坊这样存在中心化控制点的链，以便进行监管或审查？

Daniel：我来回答这个。我非常坚定地认为 JAM 的核心应用场景是作为国家级基础设施。你想想看，现在全世界其实只有少数几个国家，在科技基础设施上是完全自主的。绝大部分国家其实都依赖谷歌、亚马逊这些中心化的云服务提供商。比如我是巴西人，巴西有两亿人口，但即使是这么大的人口基数，巴西也追不上亚马逊、谷歌这样的基础设施水平。最终，大多数国家只能依赖美国或中国的大公司。

但如果这些国家能基于区块链，基于像 JAM 这样的系统搭建自己的基础设施，那他们就能真正实现技术主权，他们不再需要信任某个国家或大公司。所以我反而认为，Polkadot 和 JAM 是国家实现技术自主的唯一途径，如果他们信任以太坊，那实际上就是信任了两个主要托管在美国的中心化节点，根本称不上主权，只有 Polkadot 和 JAM 能给这些国家真正的主权，这也是我这么看重它们的原因。

如何加入 JAM 开发？

Q2：你好，大部分项目目前还不是很开放，很多细节也不透明。假设我刚完成了一个两周半的强化培训班，学了很多 Rust 语言和其他知识，现在我想找机会参与到你们的项目中，应该怎么联系你们团队呢？

Maciej：我这里有一些建议。首先，你可以去看一下灰皮书的页面。读一遍灰皮书，不用要求自己百分之百理解，简单浏览一下就好，了解个大概。然后灰皮书页面上有一个“实现团队列表”，上面列出了参与实现的各个团队，大概有 40-50% 的团队留下了联系方式（比如 Telegram 账号或者邮件地址）。你可以根据名字去谷歌搜索，或者直接发消息联系他们。如果想直接加入现有团队，这是比较推荐的路径。当然你也可以自己找同学或朋友组建一个新的团队，这也是个不错的选择。

Tomek：对，还有一个方法 —— 可以加入 Element 群组（一个去中心化的聊天平台）。灰皮书网站上也有 Element 群的链接，主要有两个群：一个是灰皮书讨论群，一个是 JAM 总群。你可以在群里发个消息，做个自我介绍，说你想加入项目。很多 JAM 的开发者都在里面，他们有的还有自己更小的团队群组，会邀请你进去。每个团队的路径可能不太一样，但这样你能找到适合你的机会。

Daniel：对，现在大概有 35 个团队在做，有些团队可能暂时不接受新成员，但也有很多团队是开放的。建议你多联系几个团队，尝试看看哪边适合自己。如果实在没有合适的，完全可以自己组队，一起推进。

JAM 的治理体系未来会怎么演变？

Q3：机构总渴望保留控制权，按常理说，他们可以买 DOT 代币，通过治理获得影响力。但据我了解，未来 DOT 主要是用于 Polkadot Hub（为平行链服务的部分），而更底层的 JAM 呢？JAM 的控制权该怎么设计？因为普通代币持有者可能根本不懂这些复杂的升级问题，他们是不是应该有投票权？目前有这方面的讨论吗？因为我觉得这是 JAM 很重要但还没有明确解决的问题。

Maciej：这个问题确实很难回答，因为它本质上是“JAM 的治理体系未来会怎么演变”的问题。就目前的设想：

1. DOT 持有者将通过现有 OpenGov 参与 JAM 治理，但权限可能收窄，不会像以前那样直接对 Relay Chain 的运行时升级投票 —— 因 JAM 链本身不可升级（仅支持硬分叉）；

2.技术联盟（Fellowship）重要性将提升，因其成员多来自 JAM 实现团队，具备协议迭代的专业能力；

3.正在开发的 JAM SDK、参与开发的贡献者也可以通过一定机制快速加入 Fellowship，形成一个技术专家 DAO，帮助管理协议的未来。不过，这只是我个人的理解，其他人可能会有不同的看法。

Alistair：是的，确实还没有确定答案。治理模式肯定会演变，Fellowship 肯定会变得更重要。未来可能会类似以太坊那种多客户端（多实现）生态，只是我们希望比以太坊实现的更快一些，不至于等五年才能搞定一个功能。但具体怎么做，目前还很难说。

Daniel：不过你看一下现实情况，虽然我们不知道未来具体怎么搞，但相比其他链，我们至少有 OpenGov 可以用。其他链，比如以太坊，几乎没有真正的链上治理，代币持有者根本没有什么话语权。而 Polkadot 至少给了我们探索治理和技术结合的空间，虽然很难，但这已经是最好的选择了。

Tomek：从工程师的角度来说，现在还是可以做一些预测的：

平行链（parachains）依然可以无分叉升级，这点不会变。Fellowship 很可能继续接受 OpenGov 的约束，也就是说最终 DOT 持有者还是有最高权力。JAM 服务是无许可的，任何人都可以部署新的服务。服务本身也可以设置成支持升级，比如开发者可以授权自己更新服务代码。要部署和运行服务，需要“核心时间”（coretime），而获取核心时间很可能还是用 DOT 来支付。

所以你可以看到，DOT、OpenGov、Fellowship 这套体系虽然形式变了，但本质上还是围绕这几个核心在运转。而且不要忘了，虽然 JAM 基础设施是去中心化和抗审查的，但在上面搭建的服务完全可以自己选择是开放的还是中心化的，这就是灵活性所在。

JAM DAO 的目标是什么？

Q4：我听说最近成立了一个 JAM DAO，你们几位应该也在这个 DAO 里吧？能不能详细讲讲它的目标是什么，以及你们对未来，比如五年、十年后的愿景？毕竟你们也在亲自构建 JAM，应该也希望能在未来发展中发挥作用吧？

Daniel：嗯，JAM DAO 其实是最近几周才刚刚成立的，非常新。这个 DAO 的核心想法是：现在设立了 JAM Prize，奖金会以锁定状态的 DOT 代币发放。这意味着未来大量锁定的 DOT 都会集中在 JAM 开发者手里，相当于我们掌握了 Polkadot 开放治理体系里的大量投票权。

所以成立 JAM DAO 的初衷就是：既然我们手握这么多治理投票权，就需要开始协调行动、互相了解、积极参与到其他提案的讨论中。说实话，我自己一开始对 OpenGov 几乎一无所知，作为一个普通开发者，我其实不太喜欢掺和政治事务。但现实情况是，经过这段时间的工作，我们都意识到有些关键决策必须参与，如果我们自己不发声，别人就会替我们做决定。

所以 JAM DAO 的成立，就是为了让开发者们能够一起行动，一起为我们心目中 Web3 的未来发声。当然，现在 DAO 还处于很早期很松散的阶段，但随着时间推移，希望能有更多人参与进来，一起为协议的发展投票、做决策。这就是我们现在在做的事。

JAM 的数据存不住？24 小时后会消失吗？

Q5：昨天我有机会问了 Gav 关于那个分布式数据湖（Distributed Data Lake）和纠删编码（Erasure Coding）的事情。我的理解是，大部分用来计算的数据，都会来自这个数据湖，而最终只是以哈希的形式提交到链上。那么问题是，既然这些纠删编码的数据块会在 24 小时后被清理掉，那是否意味着我们的资金数据在 24 小时后就会丢失？

Alistair：当然不会丢啦。我想你们都了解 Polkadot 的运作机制吧？这里的情况是完全相同的。在 Polkadot 中，我们存入数据可用性层的是平行链区块的 POV 数据，也就是各平行链的状态更新记录，而不是平行链本身的完整状态。如果一个平行链的区块生产者（比如 collator）没有及时分享数据，其他人还是可以从数据可用性层拿到。不过呢，如果你的服务类似“平行线程（parathread）”，也就是只有一个生产者的话，而且万一这个生产者挂了、数据也丢了，而又没人备份的话，那么过了 24 小时后确实就无法恢复了。

所以在 JAM 中，我们希望能发展出一整套超出基本验证者之外的数据备份网络。也就是说，未来应该会有一些专门的服务或者节点，负责把这些数据保存得更久，而不是仅仅 24 小时。但目前这些还没完全建好，因为 JAM 生态还处在早期，连基础的验证者和链都还在建设中。不过可以肯定的是，未来会有办法让数据保存得更持久。

Q6：所以这是不是意味着，我们仍然需要为服务部署专门的 collator 或 block builder？是不是 JAM 上真正可行的服务，还是更像是跑一个类似 parachain 的项目？而不是像部署智能合约那样，部署了就不用管基础设施了？

Alistair：不完全正确。我们确实可以将所有状态数据存储在数据可用性层中，但要想让数据保存超过 24 小时，你需要依赖外部参与者。不过这些存储数据的参与者并不局限于只保存某一条链的历史数据，也无需存储全部内容。因为我们已经引入了数据分片和编码机制。这就让我们有机会打造出一种类似于以太坊轻节点（light client）的模式，有很多分散的节点保存部分数据，这种机制能让你利用现有的数据恢复机制，从验证者之外的节点获取纠删码分片数据，理论上这些数据可以永久保存。当然，这确实需要有人来搭建基础设施，但这些设施既不需要中心化运营，也不需要与特定链绑定。

Q7：我唯一担心的是，我们仍然面临同样的博弈论问题——我们需要激励外部各方来存储我们的数据。虽然基于 JAM 的底层链能保障状态转换的安全性，但不能保证数据的“活性”。所以我们必须想办法让别人愿意永久存储我们的数据。

Alistair：是的，你永远不可能自己保存所有数据，必须激励他人参与存储。但去中心化的可能性在于：让每个参与者只保存很小的数据分片，这样存储成本并不高。这不是无法解决的问题，我们不需要依赖某个中心化服务来保存全部历史数据。当然，验证者的激励机制也存在同样挑战——我们通过系统机制激励他们保存数据，但不可能要求他们永久保存，否则存储需求会变得不切实际。

Maciej：再补充一点，像 Polkadot Hub 这样的服务在 JAM 中可能依然存在。比如你只想部署一个智能合约，不想管太多，那可以有人在 Polkadot Hub 上实现相应的激励协议，来运行 JAM 中的 collator。你就只需要部署智能合约，其他的可以“甩手不管”。这是一种可选项，听起来也是你想要的模式。

Tomek：我觉得这里关键的一点是：虽然对数据存储的需求依然存在，但 JAM 是放宽了这个要求，并且把控制权交还给了开发者。你可以选择把所有东西都存储在链上，但这样你就受限于链上容量，而且你得为此支付相应费用。反过来，你也可以选择把所有数据都放在链下的数据湖中，那就需要考虑如何激励别人来帮你存储这些数据，并相应地付费。

没有什么在 Polkadot 上绝对做不到的事情，只是有些事情在 JAM 上更容易、更高效。

Q8：目前用户有哪些需求或功能，是在 Polkadot 上无法实现，而必须转向 JAM 才能满足的？

Maciej：我觉得最先想到的可能是“Coreplay”（核心执行）的概念。虽然我对这方面不是特别了解，但据我理解，Coreplay 能实现一种无限制的执行——代码可以跨越多个区块逐步在链上执行，而且支持用普通编程语言写 for 循环等逻辑。这类功能在 Polkadot 上目前是做不到的，而 JAM 可能会实现这一点，不过我不太清楚 Coreplay 现在的具体进展状况。

Alistair：我对此的看法是，其实没有什么在 Polkadot 上绝对做不到的事情，只是有些事情在 JAM 上会更容易、更高效。比如 Corplay 这样的东西，理论上你也可以在 parachain（平行链）上实现，但你需要管理状态的存取、跨链的数据协调等等，这在目前的模型中并不容易。

另外，人们现在使用 Polkadot 的方式，其实远没有发挥出它的全部潜力。大家还停留在“一支团队做一条链，而且都差不多”的思路上。我们当初设计 Polkadot 的 Crowdloan 系统，某种程度上模仿了当年 1C0 热潮的机制，这可能并不是个好方向。随着 Polkadot 2.0 的新功能上线，我们已经在探索超越 parachain 模式的路径，而 JAM 是这个演进过程中的下一步。总之，理论上没有什么是 parachain 做不到的，只是并没有人真正去做或解决这些难题。

为什么 Polkadot 的治理要搬到 Asset Hub，而不是直接在 JAM 上运行？

Q9：我想问一下关于资产中心（Asset Hub）迁移到 JAM 的问题。据我理解，我们现在之所以将治理、代币等核心功能迁移到资产中心，是在为未来切换到 JAM 做准备。但我的疑问是：JAM 最终还是运行在一个 runtime 下，我们还是会有 GrandPa（共识机制）和核心虚拟机（core VM）。既然如此，为什么我们不能直接在 JAM 的 core VM 上实现治理？为什么必须把它迁到一个单独的服务上？这不是反而引入了更多关于数据丢失、节点运行等安全问题吗？

Tomek：让我来解释一下。核心虚拟机服务依然需要有人来运行 —— 不能指望 JAM 一部署就自动运转。也就是说，作为一种服务，它需要“核心时间”（core time），必须由某些节点或参与方提供，来执行你的服务。虽然验证者会确保服务执行正确，但“谁来提供核心时间”这个问题还需要明确——我们目前称之为“collators”（收集者）的节点网络就是要解决这个问题。

事实上，Gavin 昨天就曾提到关于 Coreplay 的提议结构，你可以去查相关录音，我这里就不再重复。其次，你问为什么不能直接在 core VM 上运行治理？因为从实现的角度来看，最简单的路径就是把我们现有的系统先搬到 JAM 上，然后逐步把其中的部分变成 JAM 的原生服务。

Alistair：我理解你的问题更像是：既然我们未来 JAM 会更通用，为什么不一开始就把所有功能（比如治理）都放在中继链（relay chain）上？答案是：中继链不是为了做所有事而存在的。我们想要的是模块化、可理解的架构。如果一切都放在中继链上，那就会变得非常复杂且难以维护，扩展性也差。所以，我们必须将 Polkadot 的核心功能迁移到 Asset Hub 上，作为迁移到 JAM 的准备。这样做的核心原因之一就是简化中继链，让它更“精致”、可维护。

当然，这也带来一个新的问题：我们需要确保 Asset Hub 的数据不会丢失，需要有足够多的全节点来保障它的可用性和抗审查性。否则，我们从原来 Polkadot 拥有的一千个验证者的高安全性，就变成了更脆弱的结构，这是不可接受的。

Maciej：还有一个原因是我们希望未来的治理系统是可升级的，而中继链的核心协议本身是不可升级的。如果你把治理机制直接嵌入核心协议，那将来要更新它就很麻烦，甚至不可能。所以我们最后的结论是：不如将它作为一个“服务”运行，这样更灵活、简单、模块化。否则一旦要改动，不仅浪费工作量，还会把系统复杂度拉得很高，不利于维护和发展。

JAM 对整个区块链市场有什么影响？

Q10：大家好，之前有提到 JAM 将如何影响 Polkadot 的开发和中继链，那么你们觉得 JAM 标准对整个区块链市场会有什么影响？它未来会不会成为业界的标准？

Maciej：这个问题其实迫使我们下一个赌注。我们所有人都在致力于这个项目，因为我们相信 JAM 有希望成为行业标准。回顾过去，比如 Polkadot Hub 和 Asset Hub 的迁移，很多人喜欢在 Solidity 上开发，所以我们就为他们在 Polkadot 上提供了 Solidity 智能合约。同样，JAM 也会支持更多跨链桥接，让大家能够从以太坊或其他生态系统中迁移资产。如果有人需要 Solidity，那当然可以实现；如果需要高吞吐和低费用，也能满足；还有人偏好平行链的开发模式，也可以有相应的方案。总体来说，JAM 将覆盖不同细分市场和用户群体。只要生态系统内拥有完善的智能合约工具，我很难想象还有什么需求是未来 Polkadot 生态无法覆盖的。

Alistair：确实如此。我们一开始就在技术上有优势，而现在我们正在进一步强化这个优势。但我们也意识到，Polkadot 在部署和用户体验方面还不够友好，所以在 JAM 上，这方面的改进非常重要。如果 JAM 协议要成功，就必须让更多开发者能便捷地在上面构建应用。

JAM 协议的开发分为几个阶段？

Q11：现在有多少开发团队是真的承诺要做出一个能上线生产环境的 JAM 节点？还是说大家只是想“做完某个阶段的里程碑”就行？你们有没有了解，目前到底有多少团队是真正冲着最终产品去的？

Daniel：这个问题确实不太好回答，因为 JAM 是一个开放协议，任何人都可以自己在角落里偷偷开发，理论上可能有上百个团队在做。但从我的观察来看：

在官方的 gray paper 网站上，有 38 个团队公开宣布他们在做 JAM。其中大概 20 到 25 个团队在聊天群里比较活跃，会提问题、反馈建议，说明他们真的在干活。我们还在组织 JAM 的线下聚会，参加这些聚会并且愿意交流协调的，大概有 15 到 20 个团队。从这些团队里，大部分应该至少能走到第三个里程碑（milestone 3）。

当然，能不能走到第五个里程碑，还要看后续发展。我的猜测是，最终会有至少 8 个成熟的 JAM 实现版本——这数量已经远超任何其他区块链协议了。不过这只是我的猜测，我们可以现在打个赌，五年后看谁猜得准，哈哈。

Alistair：其实现在大家还来得及，如果想参与、冲刺到里程碑五，还是有机会的。

Daniel：是的，如果你想问：“还能不能拿奖励？”答案是：可以的！现在加入也不晚。

Alistair：我稍微担心的一点是，后面四、五阶段的奖励是不是给得够多，因为这会影响大家能不能坚持到最后。另外，灰皮书对于共识机制那些部分其实还没完全细化清楚，现在也没人在认真做那块，但迟早得有人做。

Maciej：我同意。随着大家开发越来越深入，会冒出更多细节问题，大家在聊天群里不断讨论、提问，“这个地方是不是写得太模糊？”这样不断地推动协议细化。现在我们已经开始逐步触及 Elves 共识等核心模块了，这让我很兴奋，感觉整个协议正在慢慢成型。

Tomek：我也很认同前面说的。从我的角度看，里程碑一到二之间的跳跃最难。迈过一到二的人，基本可以看出是真的在认真干了。迈过二到三之后，虽然还有一些挑战（比如性能优化），但整体难度就没那么陡了。如果看到一个团队完成了三，那几乎可以肯定，他们会坚持走到最后。

Q12：你们说什么“第五阶段”，但具体是啥意思？还有，现在灰皮书上到底有多少是明确规范了的，又有多少是还没明确的？

Daniel：好的，简单解释一下 JAM 的五个里程碑：

Milestone 1（第一阶段）：是实现“区块导入”和“状态转换函数”的正确执行。虽然还不是整个协议的完整实现，但大概算完成了一半左右。Milestone 2（第二阶段）：搭建一个完整的节点，包括链下（off-chain）相关的所有模块。比如数据可用性层、节点间的通信网络这些都属于链下部分。走到第二阶段，你基本有一个能跑起来的完整节点，虽然性能可能还很差。Milestone 3（第三阶段）：把性能优化到和 Kusama 差不多的水平。这意味着节点至少能在测试环境中流畅使用。Milestone 4（第四阶段）：进一步优化到接近 Polkadot 的生产环境性能水平，可以支持正式上线。Milestone 5（第五阶段）：经过独立审计机构审核，确认这套软件安全可靠，可以放心部署到任何地方。

所以整体上：

一阶段是让区块能正确导入。二阶段是让节点完整跑起来。三、四阶段是性能调优。五阶段是通过审计，确认软件质量。

第五阶段其实也不仅靠团队自己，审计方会提出修改意见，必须按要求修正后才能通过。

这么多的 JAM 客户端最后都会被使用起来吗？

Q13：现在有很多激励是为了鼓励大家开发各种不同实现版本的对吧？那等奖金什么的发完之后，未来还有什么动力能保证生态里一直有多样化的实现呢？不会最后又只剩下一两个版本吧？

Kian：这个我可以简单回答一下。其实 JAM 的奖金不仅是一次性的，它也承诺了一个机会——加入 Fellowship。我们希望，那些能完整走完所有五个里程碑的团队，他们的关键成员大多数都能加入 Fellowship。Fellowship 本身是有工资的 —— 如果从纯粹的金钱角度来看，它就是一种长期的经济激励。而且，像 Daniel 刚才说的，完成了五个里程碑的团队，会得到一大笔锁仓的 DOT 作为奖励，这本身也是一种持续激励。

Daniel：不止这些。如果你能把 JAM 开发到 milestone 5，那说明你已经掌握了非常深入的区块链开发知识。那以后你就能在 OpenGov 上提议各种改进提案，拿到链上资金支持去开发更多新东西。你的知识、你的声誉，都能转化成真正的资源。所以说，做完 JAM 后，你在整个生态里就是有影响力的人了，之后想做啥项目都比较容易拿到支持。

Tomek：对，补充一下 Kian 说的：根据规则，每交付一个里程碑，团队里可以有一个成员被提名为 Fellowship 的三级成员。而且，加入 Fellowship 不只是拿工资那么简单的，它是有责任的。Fellowship 的职责是长期维护协议的。所以将来 JAM 的这些实现者加入后，他们的责任可能是继续维护各自做的实现版本。如果某天发现，没必要维护那么多版本了，可能大家会合并资源，共同维护一个或几个核心版本。

Maciej：补充一下，Fellowship 的所谓"神秘激励"，其实本质上就是发工资——就是你作为协议维护者拿到的薪水。

Q14：我刚才问的其实也不仅是钱的事。我是想问，未来怎样确保客户端多样性？不会说，最后因为某个实现最厉害，大家全跑那个，其他的都没人用了吧？

Tomek：这个问题我有两个想法。

第一种是：选择不同实现的原因是提升网络的抗故障能力。比如说，以前比特币曾经出现过某个矿池快达到 51% 算力的情况。当时，虽然那个矿池的收益最高，但很多人还是选择退出，把算力转移到其他矿池。为什么？因为社区有共识：我们不能让一个矿池掌握过多权力。这种“社会共识”机制帮助网络避免了中心化的风险。同理，在 JAM 的实现中，如果整个网络只运行一个客户端版本，一旦这个实现出现 bug，整个网络都可能出问题。所以出于安全和稳定的考虑，大家会倾向于保持一定的实现多样性。

第二点是：这也取决于 JAM 实现者本身的策略。我可以想象，不同的实现可能会在不同的运行模式或特定场景中进行优化。比如某个实现可能特别适合运行在 Apple Silicon 上，而另一个实现可能在 AMD 处理器上更快。还有的实现可能会加入额外的功能 —— 比如说（虽然我不一定鼓励）一些与 MEV 相关的功能。这给了实现者一个创新空间：可以根据不同需求开发出独特功能，吸引用户选择你的客户端。

Daniel：我再补充一点：因为每个实现都是用不同编程语言写的，所以它们自然会吸引各自的开发者社区。比如我们团队用的是 Elixir，那以后 Elixir 社区的开发者会更愿意用我们的版本，继续在上面开发。大家都知道，开发者对自己的编程语言是很有感情的，所以不同语言、不同社区，会自然而然地维护自己喜欢的版本。

Alistair：对，我也想强调一下：就算现在有 95% 的验证人都在使用某个性能最好的实现，但不代表两年后还是这样，生态是动态的，不断变化的。

开发者期待 JAM 生态中有什么样的功能或工具？

Q15：你好，之前 Tomek 提到他的团队开发了一个工具，用于阅读灰皮书。我想知道现在是否有其他团队也开发了类似的工具，或者其他团队是否分享并使用了这些工具？这些工具是合作中产生的吗？如果没有的话，那你们有没有什么“想看到别人做出来”的工具？

Daniel：我看到的工具并不多，所以这个领域其实还有很多创新空间。我就说说我们团队吧，我们现在的工作重心完全是在开发 JAM 上，所以暂时没有时间去做其他的工具，也不想浪费时间。目前我们的团队很小，只有两个人。不同团队的情况不同，有些团队可能会花更多时间做工具开发，随着里程碑的逐步完成，你可以扩大团队规模，招更多开发者来做这些事情。

但目前我看到的工具里，Fluff Labs 做得非常棒，他们做了 PVM Runner，支持在浏览器里运行，可以将任何兼容 PVM 的二进制文件加载到浏览器里进行模拟运行。

另外，PVM 还有一个灰皮书阅读器。另外，我注意到目前还缺少一个很有潜力的工具：JAM 节点会有内部统计数据，这些数据会存储在链的状态中，记录着关于 JAM 链的元数据。

现在我们还没有一个可视化的方式来展示这些数据，只有通过日志之类的方式查看，如果能有一个可视化界面，能展示链上运行的节点和它们的状态，做一些图形化的展示，那在短期内一定会非常有用，尤其是在开始运行测试网的时候。

Tomek：昨天，Gav 展示了他开发的 JAM top 工具，或者是他团队的成员做的，是一个可以在 JSON 和 JAM 编解码器之间转换的工具。另外，Graymatter 团队在维护一个完整的文档网站，里面有 JAM 链的文档、灰皮书的一些摘录以及其他资源的链接。

还有一个挺有意思的想法，是有人在 JAM 实现者会议上提出的：为 Element 聊天群开发一个搜索引擎，可以索引所有消息。因为 Element 自带的搜索功能不太好用，所以这会是个实用工具。

Kian：我也可以补充一点，JAM 奖金的要求之一就是各团队要展示他们的提交历史，确保提交记录是透明的，没有做什么不合规的操作。所以我们团队开发了一个工具，作为 GitHub Action 的一部分，在每次提交时都会在 Asset Hub 或某个链的系统上发布一个带有提交哈希值的备注。这样，我们的 Git 提交历史就公开在链上了。至于我个人的愿望清单，我没有什么特别想要分享的。

JAM 如何提升 Polkadot 未来的用户体验？

Q16：你们之前提到，Polkadot 现在的用户体验有点不足，我想问一下，JAM 或者说 JAM 时代会如何解决这个问题？你们对 Polkadot 未来的用户体验有什么期望？

Daniel：我觉得这其实不在 JAM 的范畴内，JAM 主要关注的是底层协议的建设，我同意 Polkadot 在用户体验上确实有待提升，但这不属于 JAM 的职责范围。JAM 只是建造了道路，至于车子如何在上面行驶，车的颜色是什么，这些都不在 JAM 的考虑范围内。当然我们是在铺一条更好、更平整的“沥青路”，所以在它上面建的应用、做的体验自然会有更多可能性，但这并不意味着会直接改善开发者的体验，这个需要并行进行改进。

Maciej：完全同意，我觉得解决这个问题的不是 JAM，而是 Polkadot Hub 上目前正在进行的工作，像 Polkadot 应用和周边工具正在努力解决这个问题，我认为这是个值得关注的问题。

Q17：我倒不觉得这个问题很严重。其实我挺有信心，现在 Polkadot 的用户体验已经比三四年前好得多。记得我刚加入生态时，只有 Polkadot JS，那时候作为新手，体验是非常差的。而现在你有了 Nova 钱包、SubWallet 这些钱包，还有各种移动端的选择，我认为这些都是顶级产品，而且很快就会有 Polkadot App 发布，所以我的观点是，JAM 是在底层做架构变革，但我们跟 Polkadot 的交互方式还是通过这些前端工具，它们在不断改善，而且现在其实已经做得很好了。

Maciej：我同意，钱包的情况确实有了很大改善，还有很多进展空间。比如说，Polkadot Hub 上支持了以太坊智能合约，我们可以开始利用以太坊的工具、IDE 等生态资源。我不知道你们在课程中有多少人接触过 Solidity 智能合约，但我们这边已经有一些以太坊工具的原型和分支在使用，大家可以借用这些工具，直接在我们的生态中使用。

Tomek：对，我认为还有一点值得注意的是，未来可能会有两条并行发展的路径。

  • 一方面，现在 Polkadot 上已有的东西，大概率会迁移到 JAM 上来。我们不会从零开始，而是会在现有基础上继续演进、持续优化。

  • 另一方面，像 Maciej 刚才提到的，未来在 JAM 上新构建的服务，也许反而会面临更高的 UX（用户体验）挑战。因为 JAM 的架构相对复杂，涉及的组件更多，开发初期可能更难做出流畅好用的产品。

但也正是因为如此，开发者可以从头开始，构建符合自己需求的服务。未来 JAM 上的用户体验究竟会如何发展，最终还是取决于你们这些开发者，取决于其他团队如何创造服务和 SDK 来建设这个生态。

Kian：好像问题已经问完了，非常感谢各位嘉宾的分享，也感谢观众们的提问。再次祝贺大家，今天是 Academy 的最后一天，也是你们在这里的最后一个阶段，现在可以去休息了，祝大家晚安，谢谢！

#JAM #Polkadot