速速一览 8 个重要进展！
加入 PolkaWorld 社区，共建 Web 3.0！
大家好，欢迎来到本期 PolkaWorld 特别报道。
本月的 Polkadot 技术 Fellowship 更新，有些不同寻常 —— 不再是熟悉的 Google Meet 会议画面，而是一场真正的线下实体聚会。在这场高强度、长达三小时的面对面会议结束后，社区成员 Alice und Bob 对话了在场的 Fellowship 技术成员，PolkaWorld 第一时间为中文社区的小伙伴带来最前线的进展解读与幕后思考。
在本期内容中，你将看到：
✅ 为什么 Polkadot SDK 的版本更新让开发者"哀嚎遍野"？Fellowship 正在如何优化这一流程？
✅ 弹性扩展（Elastic Scaling）已准备就绪，就差最后一键部署！关键抗攻击功能即将上线！
✅ 500 毫秒出块机制背后的 BastiBlocks 开发进展，如何实现"计算资源"和"出块频率"的解耦？
✅ Polkadot Hub 将支持 PVM + EVM 双栈智能合约架构，AssetHub 迁移时间为什么将延迟一个月？
✅ 下一轮压力测试或将动用 46 个 core，期待一下 Polkadot 的 30 万 TPS 吧！
✅ BLS Beefy 正式重启，为 HyperBridge 提供高性能去中心化支撑！
本期采访内容信息量极大，我们也特别梳理了其中的技术细节与设计哲思。希望能为你呈现出 Fellowship 在架构演进、性能优化、治理集成上的思考过程与推进节奏。
优化令人头疼的 Polkadot SDK 版本发布流程
Tommy：Basti，你好！
Basti：嘿，Tommy。
Tommy：感谢你今天欢迎我们到现场。
Basti：没问题，非常欢迎。
Tommy：所以这次你们是线下面对面开会了？怎么不继续用 Google Meet 呢？
Basti：因为我们希望体现"人格证明（Proof of Personhood）"这个概念。这其实可以看作是 DIM 0（去中心化身份管理）的第一步。
Tommy：就是说要确认大家确实是现实中的真实人类？
Basti：没错。哈哈哈
Tommy：那你能分享一下你们今天会议上都聊了些什么吗？
Basti：从外部来看，今天的讨论可能显得不太"刺激"，但对我们来说还是很重要的。比如我们在会议尾声讨论了一个比较实际的问题 —— 版本发布流程。
目前的流程存在很大的痛点：一旦发布了新的 Polkadot SDK，Fellowship 的 runtime 就需要更新，这时候大家几乎是"哀嚎遍野"，都不愿意碰。这不仅让 Fellowship 团队很头疼，对所有运行 parachain 的开发者来说也是同样的折磨。
我们正在思考如何优化这个流程，不仅是为了我们自己，也为了整个生态系统的技术维护者。我们希望未来的发布体验能够更平滑，而不是令人逃避。
说实话，今天会议内容太多，我现在脑子都有点记不清全部细节了（笑）。
我们还邀请了 Brian 远程参与，虽然我们也开玩笑说"他是不是真的存在谁知道"😄。他介绍了一下关于 PVQ（PolkaVM Query）的一些技术细节。
我们对 PVQ 的必要性也展开了比较深入的讨论。比如，这个机制到底是不是必需的？它带来了哪些好处？又可能带来哪些成本？
从讨论来看，它确实可能引入一些延迟，这是一个负面影响。但是否值得加入，或者是否有更优雅的替代方案，也在今天被反复探讨。
这大概就是我们今天讨论的核心内容。至少对我来说，这是今天最有意思的部分。当然，其他人可能有不同的看法。
弹性扩展：一切都已就绪，就差最后按下"启动"按钮
Tommy：好的，我明白今天的重点是围绕流程和机制改进的内部讨论。那接下来我们进入今天的正式议程，我们将围绕两个重点话题展开：
Polkadot Cloud
Polkadot Hub
我们先从 Polkadot Cloud 讲起，重点是大家最关心的弹性扩展（Elastic Scaling） 功能进展。现在这项功能的进展如何？我听说它已经上线了，但目前是不是还在进行安全性和抗攻击方面的测试？
Robert，你这边可以和我们聊聊吗？
Robert：是的，整体来说，目前链已经具备弹性扩展的能力了。不过我们还有一个尚未启用的功能，它的作用是增强系统的抗攻击性 —— 防止恶意行为阻止弹性扩展的正常运行。
这个功能之前曾经上线过，但当时导致了 Kusama 网络出现故障，因此我们决定推迟部署。
在过去一个月里，我们对这项功能进行了密集的测试和修复，主要是在测试网进行压力测试。目前它的稳定性已经非常理想 —— 系统原本是为容忍最多三分之一验证人出现异常而设计的，在测试中我们甚至超过了这个阈值，系统依然能够正常运行。
所以我们现在认为这项功能已经准备就绪。接下来只需要上线一个 runtime 功能模块来确保系统的最终稳定性，预计大约 20 小时内会在 Polkadot 主网上完成部署。
这也将标志着弹性扩展最后一个关键组件的落地。
Tommy：那这个"最后一步"是不是意味着还要发布一个新版本？
Robert：严格来说并不需要发布新版本。这个 runtime 功能已经开发完毕，只是还没有启用，它需要通过 OpenGov 治理流程来激活。所以目前已经万事俱备，只等治理通过。
Tommy：了解，谢谢你。那么弹性扩展正式启用的流程中，还需要谁来负责发布新版本？
Robert：不需要再发布一个新版本了，只需要启用已有功能即可。因为我们已经准备好所有代码，只需通过治理启用即可。
所以可以说，一切都已就绪，就差最后按下"启动"按钮。
Parity 将 NOMT 引入 Polkadot，把性能提升 10 倍！年底推出 MVP！
Tommy：好的。我还记得两个月前你们宣布过，Parity 和 NOMT 团队达成了合作协议，要把 NOMT 引入 Polkadot，并把性能提升 10 倍。你这边现在有一些最新进展对吧？
Robert：对的，我刚刚看了一下最新的开发者讨论内容。目前整个工作大致分为两部分：
一部分是对 NOMT 本身的修改，让它在原理上能更好适配 Substrate；
另一部分是将它真正集成到 Substrate 中。
现在 NOMT 本体的改造已经有了不错的进展，接下来会开始处理 Substrate 层面的集成工作。
Tommy：那这个项目有明确的时间节点吗？还是说"什么时候做好就算完成"？
Robert：这取决于你如何定义"完成"。我个人希望我们今年年底之前至少能推出一个 MVP（最小可用产品），让大家能看到初步成效。但从 MVP 到真正部署到生产链，可能还需要更多时间来打磨。
500 毫秒出块：将尽快推出 MVP 部署到 Westend 测试网供大家试用
Tommy：明白了，谢谢你 Rob。
说到 MVP，我们在场还有另一位重量级开发者，他正在推进 BastiBlocks 的最小可用产品。
不过……我听说你最近真的很忙，大家都在问你"什么时候能审我的 PR"，你手上要 review 的东西好像堆成山了？
PolkaWorld 注：BastiBlocks 是 Basti 正在开发的、用于实现 500ms 出块和弹性扩展的平行链出块逻辑模块，是 Polkadot 弹性计算架构中的关键组件之一。这是在 Fellowship 会议和社区技术讨论中，大家为 Basti 的这套新 block 构建机制起的"昵称"； 有点像在说："你那套出块模型我们就叫它 BastiBlocks 吧"。
Basti：哈哈，是的，这确实是我现在面临的难题之一。
Tommy：那你最近还有时间推进 BastiBlocks 的开发吗？
Basti：有的，我一直非常希望把这个东西做完。现在虽然还没完全完成，还有一些 PR 没被合并，我还在拜托大家帮忙 review。
好在我自己也写了一些单元测试，开发过程因此轻松了不少。目前整体代码已经相对稳定，现在主要是在处理一些"技术难度较高但必要"的最后几项工作 —— 它们虽然不是很大，但每一项都必须解决掉。
举个例子来说：在区块链上出块时，每个验证人都会被分配一个 core，甚至可能被分配多个。
三四个月前，Sebastian 提出了一个模型：一个 core 对应出一个块，三个 core 就出三个块 —— 也就是说，block 的数量与 core 数量是一一对应的。
但我这边现在开发的是一个全新的逻辑。在这个新模型下，你可以自由设置出块的频率（block rate），比如说你想每 500 毫秒出一个区块，这就意味着每秒可以出两个区块，每个周期最多出 12 个。而这个出块频率，不再直接依赖于你拥有多少个 core。
比如，你哪怕只有一个 core，也一样可以设定这个 500ms 的出块频率；但如果你再增加一个 core，你就拥有了更多的计算资源和存储能力。
Tommy：也就是说，你先定义出块频率，比如每 500ms 出一块，然后再通过增加 core 来扩展资源对吧？
Basti：没错，正是这个思路。
这个模型的关键点在于，它将"出块频率"与"资源数量"这两个维度解耦了：
你可以独立地设置出块频率，比如设定为每 500ms 出一块。这种设置本身是可行的，但如果你只有一个 core，系统会自动限制你所能使用的资源 —— 因为你需要在规定的时间内完成计算和存储。
但如果你想要使用更多资源，也很简单，只需再"买一个 core"就行。
系统或 collator（区块生产者）会自动利用这些新增的资源，比如将 12 个区块平均分配到两个 core 上，每个 core 处理 6 个区块 —— 实现真正的并行处理。
我现在实现的这个机制已经可以支持这样的运行模式了。
不过目前 Polkadot 的 runtime 配置，在出块频率这部分仍然是静态设定的，也就是说每条链上线时就固定了出块时间。
但出块频率其实决定了你能用多少资源，比如我们限制它就是为了避免有人构建一个"超大区块"，在我电脑上验证要跑一个小时。
所以现在我们会针对标准硬件设定一个上限，比如 Polkadot 当前给的是每个区块最多运行 2 秒。
但如果我们要引入弹性扩展机制，就必须支持动态资源 —— 比如 core 数量是动态的、你打算出几个块也是动态的，那就不可能用"静态时间限制"去约束了。
因此，我们现在正在开发一套动态资源评估和调配机制。
实际上，我实现的版本比我刚刚描述的还要简单（笑），并不复杂。目前已经进展得不错。
虽然我现在还不敢说确切的上线时间，但我希望很快能发布一个 MVP（最小可用版本），部署到 Westend 上做测试。
我知道很多人都很期待，包括我自己也一样。
Tommy：那你现在的开发方式是先设定一个基础模型，然后 Sebastian 每次都会跳出来说"你有没有考虑过这个问题？"于是你们就展开一轮大讨论？
Basti：哈哈，差不多就是这个模式。我们现在处理的是一些比较核心的设计问题，也挑战了很多之前的默认假设。
系统越来越复杂，涉及的变量越来越多，也越来越难推导各种边界情况："如果发生了 A，那 B 会怎么运作？"
但没办法，这就是系统成长的自然过程。
Tommy：那等你完成 MVP 或 PoC（概念验证）之后，会交给别人来做集成吗？我听说现在其实已经差不多可以用了？
Basti：集成工作其实不会太复杂。
Sebastian 之前开发了一个我们叫做 slot-based collator 的模块，它已经是现在默认使用的 collator 类型了，或者说很快就会成为默认。
我开发的逻辑，就是在这个 slot-based collator 的基础上做了改进，加入了支持 500ms 出块等新特性。
如果大家也在使用 slot-based collator（比如通过 OmniNode 部署），那这套新逻辑对于 parachain 来说集成起来是很容易的。
当然，runtime 层还是需要做一些小改动，但量不大也不复杂，所以整个集成流程应该是非常顺畅的。
接下来我可能会率先在 Atop 那边完成集成，之后其他团队就可以在这个基础上继续扩展和部署。
Polkadot Hub 将同时支持 PVM 和 EVM
Tommy：好的，谢谢你！我觉得我们已经把有关 Polkadot Cloud 和 parachains 的内容都覆盖到了。
那么接下来我们可以进入 Hub 部分，我想请 Kian 来讲讲！目前智能合约相关的迁移正在进行中，你能否简要概述一下当前的整体进展？
Kian：当然，我先讲讲智能合约的部分。
首先，我们的 Polkadot 智能合约技术，也就是 Revive 及其配套工具集，现在已经在 Kusama 上线运行了。这应该是自我们上次会议以来发生的事，对吧？
这是一个值得特别强调的进展。稍微技术一点说，它使用的是 PVM 作为智能合约的虚拟机，所以合约是为 PVM 编写并在其中执行的。
与此同时，我们也发现了一些问题或潜在的瓶颈，可能会限制系统的可用性，例如合约代码可能过大等问题。
因此在 Polkadot 主网上的部署方案中，我们正在研究采用相同的技术栈，即仍然支持 PVM，但也可能增加 EVM 作为次级后端支持。
也就是说，未来你可以写 Solidity 合约（兼容以太坊），然后选择部署为：
PVM 字节码（上传到 Polkadot Hub，也就是 AssetHub），或
EVM 字节码。
这一方案的细节还在进一步完善中。我本人并不是该模块的专家，现在是代替其他同事发言，所以暂时不多评论。但如果后续时间线上有变动，应该会在 Polkadot 官方论坛发布，请大家留意。
就智能合约部分我就先说到这里。你刚刚也提得很好，Hub 的内容主要包括两个部分：合约和 AssetHub。
接下来我将话筒交给 Oliver，由他来介绍迁移的具体进展。
7 月 28 日完成 Paseo 的相关迁移！Polkadot 迁移将延迟一个月到 10 月！
Oliver：谢谢，Kian。你好，大家好。
关于迁移的部分，目前我们的目标是在本月 28 日完成对 Paseo 的相关迁移。
我们现在正在为 Paseo 做所有准备工作，实际上是为 Polkadot 准备新的 runtimes。我们有一段脚本，会将 Polkadot 的 runtime 迁移至 Paseo，包括改名、调整常量等。
这样做的目的，是为了确保未来要在 Polkadot 上运行的迁移代码，能先在 Paseo 上进行充分测试。
按惯例，我们有个原则：在 Kusama 上没有经过充分测试的内容，不会先部署到 Paseo（因为 Paseo 预期是更稳定的环境）。但这次我们获得了一个"特别许可"，可以先在 Paseo 做这次测试。
当然，我们之前已经在 Westend 上做过一次完整的演练，以确保不会一上线就崩溃。但整体来说，这次还是比平常风险稍高。
所以，7 月 28 日是我们计划中的 Paseo 迁移日。
届时，Paseo 的 AssetHub 将完成迁移，并启用异步质押（async staking）和多个 staking 模块（multi-box staking palettes）。
这样一来，未来就可以将智能合约与这些 staking palette 集成。比如，你可以直接在合约中调用治理相关的逻辑 —— 这是其中一个非常重要的吸引力。
至于后续时间表，我们原先的计划是：
8 月 15 日：Kusama
9 月：Polkadot 主网
但现在似乎有更新：由于一些合作伙伴的集成尚未准备好，我们不太希望在他们没准备好之前就直接上线，这对我们自己也不利。
据我了解，这个时间表至少要推迟一个月，但我不太确定具体进度，没有看到最新更新。
目前大概就是这个整体情况。
Kian：也许我稍后可以补充一个小细节。关于 Paseo 的状态，我看到社区里有一些困惑或评论，所以想澄清一下。
目前在 Paseo 上部署了一条平行链，叫 PassetHub。我觉得有必要说明它的来龙去脉 —— 我们现在有一个 Paseo 中继链，正如 Oliver 刚才所说，到本月底，资产迁移将按既定流程推进：来自 Paseo 中继链的大量内容将被迁移至 Paseo 的 AssetHub，之后也会在 AssetHub 上添加智能合约功能。
而 PassetHub 是我们专门为 Paseo 添加的一条 parachain，它只包含 AssetHub 和智能合约模块的一部分功能，主要是为了让大家在开发者活动（如 hackathon）中提前使用。
我不太确定 Passetub 未来会怎样 —— 大概很快就"寿终正寝"了（RIP 😅）。
但我想强调的是：PassetHub 与 Paseo AssetHub 是不同的东西。
https://x.com/polkaworld_pro/status/1942866040108806587
Oliver：再说一句关于 Kusama 上的合约功能。
大家真的应该去试试这个功能 —— 我是第一个在上面部署合约的人！
我部署的是一个标准的 ERC20 Token 合约：只需要把 ERC20 模板代码复制粘贴进 Remix，编译，然后点击部署；MetaMask 就会弹出付款请求。
整个过程非常流畅，如果你想在 Kusama 上部署合约，这绝对值得一试。
下一次 spammening 活动，可能将用 46 个核心进行 TPS 测试
Tommy：谢谢你，真的很有意思，看到你们是怎么部署一条链、配置它、把它作为测试链、迁移所有内容……我觉得这可能是全球第一次从一条链向另一条链迁移如此大量状态数据的尝试。
我有个临时问题想问一下：上次参与"spamming"（压力测试）的人有哪些？我听说最近有个传言，说又要来一轮新的 spamming（比如说……我本人就是那个在传播的人😄）。但这次的 spamming，应该没那么容易像在 Kusama 上那样随便搞。那我们是不是可以聊聊，下一轮 spamming 可能会是什么规模？
Robert：从上一次 spamming 到现在，我们对网络性能已经做了不少优化。我预计这次我们可以使用更多 core 的同时，仍然保持网络的稳定性 —— 这是我比较有信心的一点。
不过我们当前对这类测试的优先级其实不算太高，目前更优先关注的是区块确认性（block confidence）和低延迟（low latency）。
一旦我们能拿到更多 core，我们会优先在 Kusama 上进行测试 —— 虽然优先级较低，但已经在计划中。上次我们大概使用了 23 个 core，这次理论上可以翻倍。当然，这并不是纸上谈兵，我们会做实测。
至于在 Polkadot 主网上做类似的测试，技术上并不更难，但成本高、风险大：
在 Kusama 上，大家对混乱有心理预期，如果网络崩了，我们会说："我们早提醒过你了。"
但 Polkadot 是主网，社区对它的要求是"稳定可靠"，所以我们必须更谨慎。
但如果我们能在 Kusama 上稳定跑到 40 个 core，那在 Polkadot 上也可以考虑逐步提升，比如先到 30 个 core。
Tommy：那是不是很快就会开始测试？
Robert：比如之前有个叫 "quantum" 的问题现在已经修复了，我们只需要等下一个 quantum 运行周期开始。
理论上，我们很快就可以拿到 core。一旦到手，我们会先做一些内部测试，不会立刻对外开放。主要是观察网络在高负载下的表现，这其实非常依赖带宽和系统资源。
我还是希望今年能完成一轮完整测试，但说实话，这不是我们当前的首要任务。
Tommy：我之所以问这个，是因为我们最近在筹备一个叫 Polkadot 200 启动活动（Polkadot 200 Launch Campaign） 的小项目，它会跟弹性扩展有关。
我们在考虑，能不能做一些有亮点的内容，吸引更多开发者参与。这个活动有点像 spamming，但也不完全一样 —— 更像是大家一起写脚本、协同进行压力测试。目前还处在孵化阶段，我正在收集各种创意点子。
好啦，我觉得关于 Polkadot Cloud 和 Polkadot Hub 的部分差不多可以告一段落了。
BLS Beefy 正在重启，HyperBridge 去中心化迈出关键一步
Tommy：我们来更新一下 BLS Beefy 的最新进展吧。我这边刚好请到了两个关键角色：一个负责桥（Bridge），一个负责共识（Consensus），可以说是最适合讨论 BLS Beefy 的组合了。
那我想问问你们现在到底在干嘛？我刚看到你们桌上全是密密麻麻的数学公式…是在搞理论推导，还是已经进入编码阶段了？
Seun：我们现在还在为这个加密方案的设计思路争论不休。
他总说："不不不，我们的方案才是更好的！"但说实话，我还没有完全被说服。他的理由是他们的方案已经有 SDK 实现了，因此更具实用性。
但我认为他反对我们这边方案的理由并不充分。
Tommy：我记得这个争论的起点，是你一开始加入 HyperBridge 时提出来的吧？你当时就说，为了让 HyperBridge 真正具备高性能，我们必须把 BLS Beefy 落地，否则性能根本撑不住。其实这个项目一开始推进得比较慢，有不少初期的瓶颈。但现在总算进入正轨，整体是在往前走的。
Seyed：这事其实已经卡了很久了，期间一直没人真正负责，我自己也被其他项目拖住了，代码审查也一拖再拖。目前核心代码其实已经写好了。你现在已经可以启用 BLS 密钥功能，验证人会用 BLS 密钥进行签名。
但还有一个关键问题没解决 —— 签名持有证明（Proof of Possession） 还没实现。只要这个没到位，BLS 密钥就是不安全的。
我们现在正在修改 BLS 的相关代码，以便它能支持这个机制。一旦实现了，BLS 签名才是可用且安全的。
当然，我们还得走完一些审计流程，还有两个 RFC（技术标准）要通过。
整体来说，代码是已经有了，但还得走完整的流程，才能正式启用。
如果你是打算部署到 Westend 测试网，我觉得可以考虑先跳过审计，先试用看看，边用边推进正式流程，然后再上线主网。
Tommy：所以你这周的重心就是全力协助把这个项目推进，把流程一一走完？
Seun：看起来确实得由我来干了（笑）。
其实 BLS Beefy 本来很早就应该实现了。当初我们启动 HyperBridge 项目，就是基于一个假设：未来 BLS Beefy 一定能上线。有了它，HyperBridge 才能成为业内最快、最安全的跨链桥。
结果你能想象我的惊讶吗？我加入后才发现，这个事居然一直没人在做！
所以我只好在之前几次 Fellowship 会议上主动站出来问："大家，这事到底谁来管？我们能不能搞定它？"
我记得 Seyed 当时确实已经提交了不少签名相关的代码，但之后就停滞了。
不过现在，他已经开始推进签名持有证明（Proof of Possession）和 RFC 相关流程。一旦这些流程走完，我们就能让 HyperBridge 实现真正意义上的"去中心化"。
因为现在的 HyperBridge，其实只是"部分去中心化"。
我们还需要对 ECDSA（secp256k1）签名进行 zk 转换（零知识证明），这一步超级费资源。
但有了 BLS Beefy 就完全不同了：
可以直接把 Polkadot 的签名提交到 Ethereum，
不需要 zk 转换，
没有额外开销，
没有性能瓶颈，
同时去中心化程度更高！
Tommy：太精彩了，感谢你的分享！也希望你这周能顺利推进项目进展！
那我们今天的节目就到这里，感谢大家的收看，我们下次再见！
原视频：https://www.youtube.com/watch?v=bF_5zacRpQc
PolkaWorld Telegram 群：
https://t.me/+z7BUktDraU1mNWE1
PolkaWorld Youtube 频道：
https://www.youtube.com/c/PolkaWorld
PolkaWorld Twitter：
@polkaworld_org
更多内容
Coretime + 弹性扩展：为 Polkadot 构建一条产品化、可持续的 Web3 商业逻辑！
关注 PolkaWorld
发现 Web 3.0 时代新机遇
点个 "在看" 再走吧！
没有评论:
发表评论