加入 PolkaWorld 社区,共建 Web 3.0!
上个月,又一批开发者和学生通过 Polkadot 区块链学院(PBA)在瑞士的卢塞恩完成了对 Web3 的学习!Gavin 亲自去参加了毕业典礼,在毕业日向大家带去了祝福和愿景!同时,JAM 协议的多个实施团队也在活动现场为毕业生分享了他们在 JAM 中的旅程,以及对 JAM 协议的深刻理解!
不论你是一个想要加入 JAM 的开发者,还是看好 JAM 未来发展的普通用户,这篇文章都值得大家去阅读和学习!
该内容较长,PolkaWorld 将分为两篇来发布,本文为第一篇,主要涉及以下内容:
JAM 实施团队介绍为什么加入 JAM 协议做开发?JAM 开发现状:38支团队、15种语言、没有老板、没有命令这 38 个开发团队在做什么?他们的中短期目标是什么?Polkadot 向 JAM 迁移路径会是怎样的?如果想真的实现 Web3,现在唯一选择就是 Polkadot 和 JAM
继续阅读,学习全部内容!
JAM 团队介绍
Jay:欢迎来到卢塞恩的 Academy 活动!今天现场有一群非常棒的观众朋友。现在我们进入 Academy 中一个非常重要的环节 —— 深入探讨 JAM 项目,今天我们请到了一组非常精彩的小组嘉宾,接下来把时间交给 Kian Paimani ,让他来为大家介绍嘉宾并开启讨论,敬请期待!
Kian:谢谢大家!对于在教室里观看直播的朋友们,大部分嘉宾你们应该已经认识了。但为了线上观众,我们还是做一个简单的自我介绍,让每位嘉宾说一下自己在哪个团队,以及他们是如何参与到 JAM 项目中的。那我先把话筒交给 Tomek。
Kian
Tomek:大家好,我是 Tomek,我来自 Fluffy Labs 。大概八个月前,我们决定用 TypeScript 来实现 JAM 协议,这个实现版本叫 Typeberry 。在开发过程中,我们还有一个目标,就是改善其他 JAM 团队的开发体验,所以我们也在积极构建与 JAM 相关的工具链。
Kian:为什么叫 Fluffy Labs?
Tomek:当时我想取个有趣的名字,因为很多公司都爱用严肃的数学概念命名,Fluffy Labs 还能让人联想到 Fluffy Labrador(毛茸茸的拉布拉多犬),其实我们的贴纸上就画了一只狗,就是想体现轻松有趣的氛围。
Daniel:大家好,我是 Daniel,我在 jamixir 团队工作,我们用 Elixir 语言实现 JAM。我们团队只有我和 Luke 两个人。我差不多在一年前,也就是 PBA 课程结束后开始做这件事的。我是在香港参加的 PBA 课程,为了更好地了解 JAM,我边学边做,同时也会在 Twitter 上分享一些 JAM 相关的内容,希望能让更多人了解这个项目。当然我们知道,距离 JAM 能真正投入生产环境,还有很长的路要走,但现在这个阶段非常有趣。
Maciej:大家好,我是 Maciej,我在 Graymatter 团队。我们也在用 Elixir 构建 JAM 实现,但我们团队稍微大一些,有四个人,不过都是兼职做的。这里也想跟大家分享一个观点:参与 JAM 开发不一定非得是全职投入,你可以用业余时间参与,比如做轻量级的客户端开发,或者做相关工具,适合各种不同类型的人参与。
我们也很清楚,既然是兼职做,速度肯定比不过全职团队,但我们希望能尽可能走得更远,同时也积极和其他团队合作,比如共享工具、测试集等等,目的是让整个协议更加健壮。至于我个人加入 JAM 的原因,是因为我相信它会成为 Polkadot 的未来。JAM 能提供更高层次的抽象,打开一些过去无法实现的新可能性。
Alistair:大家好,我是 Alistair,目前在 Web3 基金会担任首席科学家。我的主要工作是从理论层面支持 JAM 的设计。
Kian:好的,谢谢各位!补充一下,我是 Kian,也在 Graymatter 团队,担任项目经理角色,平时也是兼职参与 JAM 开发。我的主要动机是想通过参与初期的两个里程碑,深入理解这个协议,为将来 JAM 上线正式生产环境后,能有更多参与和贡献的机会打下基础。
为什么加入 JAM 协议做开发?
接下来我想请大家再展开讲一讲,你们为什么选择加入 JAM,具体的动机是什么?为什么觉得值得投入?
Tomek:对我和我的团队来说,一开始其实也是想着兼职做,纯粹是因为觉得很有意思。我以前在 Parity 工作,做过 Polkadot,休息一段时间后,我发现 JAM 项目是一个很好的回归方式,我可以利用过去积累的知识和经验重新回到生态圈中,当我把这个想法跟一些朋友分享后,他们也很感兴趣,所以后来我们就决定更全职地投入进来了,大概就是这样吧。
Maciej:和 Kian 组队并非偶然,也是因为我们在动机上非常一致。我也觉得,学习 JAM 协议很有必要,因为它未来肯定会很重要。即便目前我的主业与此不同,但深知这项技术的前瞻性。我也经常有 PBA 的学生或者其他开发者来问我关于 JAM 的问题,作为现在还在参与 Polkadot 开发的人,我觉得有责任了解并能回答这些问题,而最好的方法,就是亲手去做、去搭建、去读灰皮书和里面的各种设计细节。当然,我也相信 JAM 能带来过去不可能实现的新特性,如果我不相信它的潜力,也不会花时间去投入了,正是因为觉得它值得期待,所以我愿意投入时间和精力。
Kian:Alistair,你想分享一下你觉得 JAM 有哪些有趣的地方吗?
Alistair:我最开始是因为有人找我咨询 JAM 相关的事情,所以就参与进来了。至于 JAM 有趣的地方,我觉得 JAM 的数据可用性设计极具魅力,我迫不及待想见证其应用场景。
如果你问我,JAM 是为了什么?除了是对 Polkadot 的一种扩展外,更深层而言,Polkadot 协议复杂度已超出单人理解范畴。所以撰写 Gray Paper 的一个初衷,就是希望至少为 Polkadot 的一部分制定一个统一的协议规范,做到能够被人理解,如果能理解清楚,就能更好地优化系统。因此,JAM 的目标是实现比现在 Polkadot 更高的性能。这是一个很有野心的协议,我非常期待看到它最终的样子。
Tomek:抱歉,我想补充一点。从工程角度来看,JAM 项目真的很吸引人。你可以拿到一份完整的协议规范(虽然还在不断完善),可以选择任何你喜欢的编程语言来实现它,而且你还可以通过 " JAM 实施奖计划 " 获得激励,所以即使你暂时还没完全认同 JAM 的理念,这种开放的技术挑战本身也极具吸引力。
Daniel:我的故事始于 PBA(Polkadot 区块链学院),结业时我就想着以后要做一些和 Polkadot 相关的事情,但方向未定。正好我刚完成 PBA,恰逢 JAM 计划启动,与奖项激励形成完美契机。不过奖项只是副产品——即便未能获奖,过程中积累的知识、与 Gavin Wood 等顶尖开发者的协作、以及对协议底层的透彻理解,这些才是无价之宝。
因为在 JAM 建成之后,会有很多基于 JAM 的服务可以开发,了解底层细节的人肯定会有巨大优势。我之所以投身其中,是因为我非常相信 Gavin 很早以前提出的 Web3 核心愿景:我们需要一个真正去中心化、无需许可、抗攻击的系统。现在所谓的区块链,不管是以太坊还是其他,都还远远达不到这个标准。而 JAM,可能是人类历史上第一次真正有机会把这件事做成,所以,我发自内心想参与,成为这一切的开创者,也很高兴能和大家一起在这里努力。
Daniel
Kian:说得太好了。听完各位的背景介绍,值得注意我们这个小组的多元性。作为观察者,我很欣喜看到既有 Polkadot 的“老兵”,像 Alistair 这样从以太坊时代就开始写代码的人,也有像 Daniel 和其他人这样从 PBA 走出来的新生力量。希望这能鼓励在场的各位同学,告诉你们:这条路其实并不是不可逾越的。一年前、两年前、三年前,还跟你们一样坐在教室里的人,现在已经在亲手实现 JAM 协议了。只要努力,机会是有的。
Daniel:我还想补充一点,我们现在依然处在非常早期的阶段。这条路很长,不是百米冲刺,而是一场马拉松。我们大概才跑完第一个公里吧,后面还有 40 多公里呢。所以,现在加入还一点都不晚。
Maciej:对,绝对不要因为觉得“太晚了”而犹豫。现在还有大量的工作需要大家一起去完成。
JAM 开发现状?38 支团队、15 种语言、没有老板、没有命令?
Kian:非常好。Daniel,你刚才提到了一些其他团队和 JAM 社区的事情,能不能再展开讲讲?比如现在 JAM 社区的氛围是怎样的?这么多互不相关的人一起协作开发,有什么好处?你个人的感受又是怎样的?
Daniel:其实我觉得,JAM 奖励计划的设计真的很聪明。它激励了世界各地的人,不同背景的人,围绕同一份蓝图(Gray Paper)独立开发。大家互不抄袭,也互不干涉,但都在朝着同一个标准努力。如果每个人都严格按照规范去做,最终这些独立实现就可以互联互通,组成一个真正的去中心化网络。
我们已经开始看到这个过程了。几个月前,各个团队开始能自己产出区块,并把生成的区块发送给其他团队来验证,检查是否符合规范。彼此并不知道对方的代码细节,但却可以互相验证,这本身就非常激动人心。当然有时候会发现一些小 bug,大家就各自回去排查自己的问题。这样社区氛围慢慢就形成了。我们还计划今年五月在里斯本举行 JAM Experience 活动,届时计划启动 JAM 测试网(虽然能否如期尚存挑战)。另外值得一提的是,我们还在搭建一个叫做 JAM Toaster 的数据中心,为未来的大规模测试做准备。这个超算集群配备数百核心、PB 级存储和 TB 内存,能模拟真实网络压力,届时不同实现将在其中互联,那场景将极为壮观。
Tomek:对了,可能很多人还不知道,目前已有 38 个团队公开参与,覆盖约 15 种编程语言。可能有人质疑是否需要这么多实现 —— 其实目标并非让所有版本都上生产环境,而是培育专家社区。就像 Polkadot 现有的技术 Fellowship,但 JAM 选择在协议上线前就建立这种知识网络,为未来升级奠定人才基础。
Maciej:是的,奖项的一个核心目的就是:通过知识去中心化推动生态繁荣。PBA、JAM Prize、还有 Fellowship 都是为了同一个目标:让更多人了解、参与并能真正理解协议,未来能独立开发工具,推动生态发展。如果只有少数人懂,那整个生态是脆弱的。所以,我们一定要把知识传出去,才能真正保证未来成功。
Maciej
Kian:我今天早上在讲座里也提到过一点,当前 Polkadot 技术 Fellowship 的重要作用就是防止任何单一公司成为开发瓶颈或知识垄断点。而 JAM 通过奖项计划,已聚集 40 多支团队、数百名开发者,在知识去中心化方面超前部署。未来 JAM 的维护升级将完全脱离单一组织掌控,我觉得这是非常了不起的。
这 38 个开发团队在做什么?他们的中短期目标是什么?
那我们来聊聊未来吧,每个开发团队希望在接下来一年内,看到 JAM 和自己团队整体达成哪些目标?比如短期和中期希望达到什么目标?
Tomek:那我先说吧。关于 JAM,我真心希望一年内能有一个稳定运行的测试网。我觉得这个目标是可以实现的。至于我们自己的团队,我们选择的编程语言并不是最快的,所以可能很难超过 Milestone 3(对应 Kusama 级别的性能)。不过最近发现新路径:比如无需自行开发高性能 PVM 编译器,而是借助其他语言的本地代码编译能力。因此我们目标调整为完成第二里程碑(基础功能实现),之后可能转向开发浏览器轻客户端,为 JAM 生态提供访问入口。
Daniel:我们团队用的是 Elixir 语言,能不能撑到 Milestone 5 现在还是个问号。我是相信可以的,但还是得看进展。如果真做不到极致性能,我们也可以用 Rust 之类的低层语言去处理最吃性能的部分,让 Elixir 专注于上层的逻辑控制和管理。我相信 Elixir 在这一块是非常合适的。
我的计划是,未来至少十年都会留在 JAM 生态里。因为 JAM 完成后,还有太多事情要做:在它之上建设各种服务,帮助其他人基于 JAM 开发。就像进入了一个全新的世界。而且,我很喜欢现在这种工作方式:没有公司、没有老板、没有客户。我们是一群志同道合的人组成的社区,在一起自由协作、互相分享,这是最棒的。我希望这种氛围能够一直保持下去。
Maciej:我也很认同前面 Daniel 说的关于 Elixir 的观点。我自己是最近一个月才开始参与 JAM 项目的,所以目前还在快速学习和熟悉的阶段。老实说,刚开始确实信息量非常大,但我在慢慢理顺中。
我观察到,目前多数团队聚焦第一里程碑(基础状态转换功能),即将面临分片架构的核心挑战 —— 而这些正是我之前在 Polkadot 2.0 里长期研究和开发的方向。所以接下来,我希望不仅能帮助自己的团队,还能把自己掌握的知识分享给更多 JAM 团队,帮助他们理解分片机制,怎么去做 ELVES(执行环境)、怎么让系统各部分协同运作。如果顺利的话,一年之内我们应该能在 JAM 上看到初步的 ELVES 运行成果。过去几年我们在 Polkadot 领域积累了很多优化经验,现在是时候把这些经验传承下去了。
Alistair:我当然也很期待!对我来说,我的关注点是:在 JAM 的第一个版本里,我们能放进去哪些功能,哪些又不得不推到以后。比如说,Tenderbake 团队前两周在讨论 DKG(分布式密钥生成)协议,如果 JAM 能在第一个版本里引入门限加密(threshold cryptography)技术,那验证人节点的工作量可以减少 40% —— 也就是说,相同的硬件条件下,系统的处理能力可以提升 40%。这是一个很大的提升,不过我不确定这个能不能赶上第一个版本上线,而且我猜很多开发者其实也不想赶上哈哈,因为那样一上来要做的活儿就更重了。
Kian:说到这里,我想接着问 Alistair 一个问题:你刚刚提到 JAM 会有版本升级。那么能不能解释一下,JAM 未来的升级路线会是怎样的?因为很多人一开始会疑惑,Polkadot 是可以链上升级的,而 JAM 好像不是特别强调链上升级机制。这中间有什么区别?如果未来真的要对 JAM 进行大升级,需要重新制定灰皮书,甚至硬分叉的话,会是因为什么情况?
Alistair:其实现在的 Polkadot,严格来说也只是运行时(Runtime)支持链上治理升级,共识算法等底层变更仍需硬分叉,不比比特币简单多少。那 JAM 呢,未来确实会有自己的硬分叉管理模式,这是 Polkadot 生态里的一个新课题。也许,到时候技术 Fellowship 会扮演更重要的角色,毕竟他们现在在 Polkadot 上的运行时升级里已经很重要了。JAM 可能也会有自己的“Fellowship 分支”,来负责未来的大型变更,但具体怎么做,说实话,现在我们也还没最后定下来。
Alistair
Kian:我之前听 Gavin 在一次采访里提到过,好像未来 JAM 的某次硬分叉或者重大版本更新,有可能会涉及到量子抗性加密(Quantum Resistant Crypto)。Alistair,你对这块比较懂,能不能说说这是不是真的?还是我听错了?
Alistair:嗯,这个嘛,我觉得目前来看还没有非常紧迫的马上上量子抗性加密。不过重要的是—— 我们要提前准备好一个能随时切换的分叉版本。现在我们正在审视 Polkadot 里的各种密码学原语,看哪些可以比较容易地替换成抗量子的。有些地方很简单,例如将椭圆曲线签名替换为已标准化的格基签名相对容易,但比如说,我们在 ELVES 和 Sassafras 里用的 VRF(可验证随机函数),要用抗量子加密就没那么容易了,可能得改用随机信标(Randomness Beacon)或者像之前我提到的基于 DKG 的方法。我们正在认真思考这些问题,比如是不是可以先在 Kusama 上试试。总体来说,如果直接在 JAM 上上线一个全抗量子的系统,性能会有一定的下降。不过更重要的是,要有准备好能随时切换的分叉版本,即使短期内不会马上启用。
Daniel:所以说,想要抗量子的话,肯定是要牺牲性能的喽?没办法又快又抗量子?
Alistair:不过某些协议优化能缓解影响。例如采用哈希密集型算法可能保持速度,但会增大带宽消耗。比如原本在链上执行的 100KB 零知识证明(SNARK),可迁移至链下服务处理,这样链上性能不受影响。真正痛点在于签名体积膨胀 —— 主要消耗区块空间而非计算资源。
Tomek:值得注意的是,JAM 作为极简协议,原生不包含代币和治理机制,所有功能都要以服务(Service)的形式去扩展。所以,未来升级将聚焦底层协议改进,比如换成抗量子加密,或者提升验证人的效率,减少他们的工作量。而且,判断一次硬分叉是否必要,有一个很直观的标准:只要能证明这个升级不会带来系统性风险,只会提升系统性能或者安全性,大家一般都能接受,不太可能出现社区意见严重分裂的情况。
Polkadot 向 JAM 迁移路径会是怎样的?
Kian:所以也就是说,正是这种设计使得 JAM 需要硬分叉的概率极低。那想问一下在座各位,你们觉得现有的 Polkadot 系统和各个 Parachain(平行链)未来的升级和迁移路径会是什么样?当然现在还没走到那一步,但以你们目前的理解,可以预测一下吗?
Maciej:我觉得这个问题可以拆成两部分来讲。首先,可以明确的是:Parachains 在 JAM 上是有位置的。每次我谈到 JAM,我都会强调这一点,现有的平行链团队,会有办法迁移到 JAM 上去,会有专门的服务来支持平行链运行。
至于具体怎么迁移,这个就比较难了,现在有些人在讨论是不是需要 Regenesis(链重启)?是不是一定需要?目前还没定论,大家都还在分析各种利弊。可以确定的是,到时候技术 Fellowship 会参与,甚至可能需要通过某种形式的治理决策,但现在还不好下定论。
Alistair:对的。最基本的思路是,先开发出一个 Core Chain Service,能够在 JAM 上支持运行平行链。现有的 Parachain 节点,很多是基于 FRAME 构建的,用 Cumulus 框架,只要稍微适配一下,理论上就能继续运行,这是第一步 —— 先让逻辑上能跑得通。至于迁移的细节,比如数据怎么迁、状态怎么保持,这是另一回事,也是个很有趣的技术挑战,但那是下一阶段要考虑的。
Kian:我也补充一点。像 Maciej 说的,目前 Parity 和 Fellowship 的目标,是尽可能让迁移过程做到无缝过渡。当然,现在还处在早期规划阶段,具体方案仍需探索。但方向是确定的:尽量无缝,减少影响。
Maciej:对,其实现在 Polkadot 2.0 的升级过程中,我们也正在经历类似的事情,比如把 Relay Chain(中继链)上的功能迁移到各种服务(Service)上。这个过程中,我们也在积累大量迁移经验。我相信,到时候这些经验能为 JAM 的迁移提供很多帮助,也许还能让我们提前发现和解决一些潜在问题。
Kian:值得注意的是在今年剩下的时间里,Polkadot 有很多升级,核心就是在把一部分功能从中继链上迁移到系统链,比如 Asset Hub。这样做不仅能改善协议本身、用户体验和开发者体验,也是在为未来的 JAM 做准备。我们正在一点点把中继链“清空”,让它尽量轻量,这样以后换成 JAM 时就能顺利无痛地完成替换。
如果想真的实现 Web3,现在唯一的选择就是 Polkadot 和 JAM
最后我还有一个开放性的问题,然后就交给大家提问啦:在座的各位,有没有什么关于 JAM 的想法或者感受想分享的?比如说,让你们最兴奋的点,或者对未来的期待?开放式问题,谁都可以来聊聊。
Tomek:这个问题太开放了哈哈,那我先从一个工程师的角度讲讲。现在其实是一个非常独特的机会,就像前面大家说的,JAM 的通用性远超现有 Polkadot 架构,就是我们可以直接把现在的 parachains 迁移过去,依然能正常运作。
但更重要的问题是:除了迁移现有的平行链之外,我们还能做什么? JAM 给我们打开了很多新的可能性,比如 —— 未来一定还要用“链”的形式吗?能不能有新的模式?可以基于 JAM 打造什么样的新服务?更酷的是,我们甚至还没有一个标准的框架来开发这些服务,虽然 Parity 和 Gavin 正在做一个 JAM SDK,但 JAM 本身运行的是 PVM,开发者可以自由选择自己的开发框架,只要最后能编译到 PVM 就行。而且因为 PVM 是基于 RISC-V 架构的,理论上支持几乎所有主流编程语言。所以,这意味着未来大家可以用自己喜欢的语言,自己定义适合自己应用的开发框架,这将成为 JAM 生态未来的基础。
Tomek
Daniel:我的想法可能更哲学一点。如果你真的相信 Web3 的理想 —— 去中心化、抗审查、链可以完全自运行而不依赖任何中心化实体,那我想说,目前来看,只有 Polkadot 和 JAM 还在真正坚持做这件事。你看看别的,比如 Ethereum,现在的以太坊其实已经被“卡死”了,技术也落后了,社区也很难再推动大的升级了。而其他那些号称要超越以太坊的链,本质上都是一些中心化公司在运营的,一两家实体就能控制局势。即使是以太坊的二层(L2)扩展,比如 Base、Arbitrum,这些其实也都是中心化的,本质上跟 Web3 的理想背道而驰。
如果你真的想做真正意义上的 Web3,现在唯一的选择就是 Polkadot 和 JAM。当然,要把这个理想变成现实,需要更多人一起努力。我们正在努力吸引更多人加入。人越多,我们就能越快实现这个目标。
Alistair:是的,完全同意。Polkadot 和 JAM 的梦想就是,要能真正构建出去中心化、抗审查的协议。虽然现在设计上还有一些挑战,比如有些地方还需要更多探索和创新,但我们会继续推进下去。
Maciej:我的感受是这样:Polkadot 作为首个分片区块链原型,虽然我们很多设计是对的,但一路走来也意识到,有些地方可以做得更好。JAM 正好是一个机会,让我们把这几年积累的“技术债”清掉。我们可以用更抽象、更简洁的方式重新设计,打造出真正接近理想状态的协议。
另外,现在有人觉得 Polkadot 协议难理解,未来在 JAM 上,这种情况会好很多。因为 JAM 只保留了最核心、最必要的东西,逻辑简单,架构清晰。这样以后无论是开发者、社区,理解起来都会容易得多。其实,不只是区块链,所有大型软件系统都会积累技术债,但大多数项目很难有机会彻底重构,我们现在正在抓住这个机会,去重新做对。
Alistair:我想补充一点,现在我们其实也还不知道 JAM 上最终能实现哪些新的东西。但是我们希望,JAM 里的各种抽象和通用化设计能打开新的可能性。比如说,Gavin 当年提出过一个“Coreplay”的想法,就是一种超越现有 parachain 的新思路,虽然那个想法当时没有正式成为 PR(拉取请求),版本也比较旧了,但如果有兴趣,大家可以去挖挖 Polkadot Fellowship 的 RFC 仓库,有些灵感的来源在那里。
Maciej:我也想补一句,可能有点“毒舌”了。如果 JAM 生态最终只是平行链的翻版,那将是彻底的失败。我们期待的是,能基于 JAM 开发出更多新的东西!Coreplay 是我特别期待的一部分,我真心希望未来能在 JAM 上看到它被真正应用起来。
Kian:好的,谢谢大家的分享!那接下来,我就拿着麦克风,在场地里走一圈,大家可以自由提问啦!
下文主要是一些社区关心的 Q&A 问答,PolkaWorld 将于明天发布!
#JAM #Polkadot