如何让 Polkadot 更加灵活和高效？“动态支持组” 或许是答案 | 波卡社区讨论分享

加入 PolkaWorld 社区，共建 Web 3.0！

波卡联合创始人 Rob Habermeier 在波卡论坛上发表了一篇帖子，讨论了动态支持组的问题。

动态支持组是为敏捷调度核心（Core）准备的基础，它可以提高 Polkadot 网络的效率和安全性。在帖子中，Rob 介绍了在面对未来的核心时间分配时，核心原语会遇到的问题和解决方案。

动态支持组（Dynamic Backing Group）是一种将验证人分配给不同平行链的机制，它可以根据平行链的需求和优先级，动态调整验证人的数量和分布。这样平行链就可以根据自己的负载和安全需求，申请更多或更少的验证人，而不是被固定在一个静态的配置中。动态支持组还可以让验证人更快地切换到其他平行链，从而提高网络的灵活性和响应能力。

核心原语的目标

核心原语是 Polkadot 架构的一个组成部分，它有以下几个目标：

•  限制由于数据可用性和批准检查的新输入而导致的工作负载的速率

•  解耦候选人背后的质押

•  分摊积极有效性证明的成本

•  将中继链的每个分叉限制为状态机的单个分叉

•  为预定在 Polkadot 上的平行链提供可预测的资源访问

然而，当前核心原语在调度层的设计只考虑了两种用例：

•  每个核心对应一个平行链

•  为偶尔的按需工作负载保留核心

而新的范式涵盖了整个核心时间需求分布，从小额消费者到超大额消费者。试图改进这一点的尝试，如核心时间调度区域和核心组，暴露了以前假设中隐藏的巨大复杂性。Rob 在帖子中分析了核心原语做了什么，并为未来提出了一系列必要的改变。

当前对核心原语的定义是什么？

一个核心原语是中继链状态中的一个编了号的容器。这个容器要么是空的，要么是满的。当它是空的时，中继链出块者可以将一个新的候选人放入其中。它会保持满的状态，直到该候选人的数据可用或超时。这个过程重复进行。在幕后，验证人使用核心原语索引来确定在批准检查中验证哪些候选人。

当前，我们希望验证人被划分为支持组，每个支持组负责一个单独的核心原语，并且该组支持的候选人只能进入这个核心原语。这个决定很早就做出了，当时我们假设每个平行链一个核心原语，而不是多个平行链一个核心原语或多个核心原语一个平行链，或者定期更新这种调度。

期望的属性

可以根据以下五个属性来评价核心原语：

•  与可用性和批准检查有关，并且在最终确定之前积极地检查候选人。过度负担验证人的工作会导致潜在无限的终结延迟，这是不可取的。因此，候选人的总速率必须有边界。

•  关于 Polkadot 对证明无效候选人的节点进行追责。如果一个节点预期会被 Slash，那么提交额外无效候选人的边际成本就是零。也就是说，不应该是同一个 1 或 2 个节点向系统引入所有候选人。

•  每个状态转换都带有一些常量开销，例如在纠删码、获取、解码、可用性证明中，特别是在批准检查中。通过将许多小的状态转换的数据包和有效性检查责任捆绑起来，分摊这些成本是非常有价值的。

•  通过将中继链的每个分叉限制为每个平行链的单个分叉，并利用网络的分叉选择规则来重新组织远离坏候选人，我们可以在终结之前（发送消息和更新块头）乐观地处理和执行候选人。这可以在数据可用性结束后立即完成，因为此时批准检查和争议是可能的。

•  扩展资源必须与有效分配这些资源相辅相成。

属性评分

按照 1-5 的等级对这些属性进行评分：

•  核心原语非常适合限制数据和执行负担（5 分）

•  核心原语非常适合解耦状态转换背后的质押，通过限制特定验证人可以支持的候选人（5 分）

•  核心原语在捆绑和可用性方面表现良好。不是 5 分，是因为不支持任意捆绑，只支持预先安排在核心原语上的状态机的捆绑（3 分）

•  核心原语实现了在可用性之后快速执行候选人的目标（5 分）

•  核心原语在调度数据和计算资源方面表现不佳。平行链在核心原语上与其他平行链发生摩擦，而且平行链似乎需要对特定核心原语有一定的亲和力，至少在保持目标 2 时是这样。当一个平行链试图同时消耗多个核心原语的资源时，这些问题会变得更糟。此外，核心原语假设了数据和执行时间之间的特定比例，而不是由市场供需决定（2 分）

根据这个标准，看起来核心原语总体上是一个好的解决方案 —— 但是，在为大小消费者提供核心时间方面，目标 3 和 5 对 Polkadot 的价值主张非常重要。事实上，当前的架构确保了系统不会使用太多资源，但它没有很好地利用系统的资源。我们的架构遇到问题是很自然的，因为它是建立在 1 个平行链 = 1 个核心原语（即只针对区块空间需求分布的很小一片）的假设之上。

可能的解决方案

一个可能的解决方案是，改变确定 “支持验证人” 的算法，并消除所有验证人支持候选人与核心原语亲和力之间的联系。将支持候选人放入核心原语的责任推给中继链出块者本身。

注意，解决问题 3 和问题 5 的关键问题源于处理整个核心时间分布：

•  低核心时间平行链的长尾。这大致对应于需要低量核心时间的引导或调整用户群。他们可能需要偶尔的大候选人或非常规律的小候选人。

•  高核心时间平行链的胖尾。这对应于核心时间消费者的用户群，他们实际上能够利用他们能够获得的尽可能多的核心时间。他们需要以高于中继链本身的频率产生规则的大候选人，例如 4 或 8 个完整的核心原语。

•  核心时间目前包括两种资源（数据可用性和执行时间），以一个任意比例表示。网络实际上的需求分布和供应能力可能与这个比例不匹配，导致当前实例化的核心时间是一个不完美的商品。

我们将在问题 3 和问题 5 中遇到的摩擦，反映到为这些用户群准备的调度工具：

•  捆绑：当许多小的状态转换由相同的验证人支持时，它们可以被捆绑和分摊，通过将它们同时放入同一个核心原语。数据和执行负担被合并。

•  在捆绑可以使用其他空闲核心原语的 “溢出” 资源，并且不被绑定到任何特定核心原语时，捆绑效果更好。

•  捆绑问题：支持许多小的状态转换只有在它们的支持者有很大的重叠时才可行，目的是为了通过可用性和批准来捆绑和分摊它们的成本

•  多核平行链：使用多个核心原语的平行链从支持者和特定状态转换的核心原语亲和力方面受益最小。

•  当前对支持组和核心原语亲和力要求的定义导致了巨大的调度低效

•  弹性扩展问题：当试图并行地支持一个平行链的一系列顺序候选人时，平行链或过多的潜在支持者对核心原语的亲和力会导致严重的摩擦

具体地说，这意味着支持组的定义和由此产生的隐含核心原语亲和力是问题的根源。我们为多核平行链引入了太多的支持者，引入了协调开销。特定支持者对核心原语的亲和力降低了资源利用率。小状态转换受益于共享支持者。

解决方案

•  支持者应该被分配给平行链，而不是核心原语。支持者可以同时被分配给多个平行链。

•  支持者的分配应该定期和确定性地打乱，以避免离线或审查支持者造成的活跃度问题。

•  任何候选人（或捆绑）都可以进入任何核心原语，只要它们得到了足够数量来自平行链组支持者的支持。中继链出块者根据他们从 gossip 中收到的内容做出选择，并且因为最优地填充核心原语而得到奖励。

•  大型平行链应该有专门的支持者，小型平行链应该与其他小型平行链共享他们的支持者。理想情况下，这个属性作为一个连续的属性出现，有一些很好的算法来分配职责

•  一些支持组将负责许多小型平行链。这是为了捆绑（优雅地处理长尾低核心时间平行链）

•  一些支持组可能只负责一个平行链，而该组中的支持者数量将是处理该平行链所需核心原语数量所需的最小数量（优雅地处理胖尾高核心时间平行链）

•  通过一个更智能和自适应地将支持者分配给平行链的算法，我们更接近于完全解决问题 3 和问题 5。这对于问题 5 来说并不完美，因为 Polkadot 仍然以固定比例卖出数据和执行作为核心时间。然而，将支持组与核心原语索引解耦是朝着粒度市场这个方向迈出的有用一步。即我们没有硬性要求一个 “核心原语” 甚至对应于特定数量的资源。

欢迎去原贴下参与讨论：

https://forum.polkadot.network/t/dynamic-backing-groups-preparing-cores-for-agile-scheduling/3629

---

活动预告

Polkadot 2.0 即将到来，它以 Coretime 为核心，把 Polkadot 重新定义为一个运行了很多应用的多核计算机。Polkadot 2.0 将带来什么样的新叙事？对平行链会有什么影响？对 OpenGov 有什么影响？

「Polkadot 2.0 Power Tour」系列活动深圳站将于 8 月 19 日举办，点击下方报名👇，第一时间获取 Polkadot 2.0 的最新消息，还能领取 Polkadot 2023 限量周边！

直播预告

• PolkaWorld Telegram 群：

  t.me/polkaworld

• PolkaWorld Youtube 频道：
  

  https://www.youtube.com/c/PolkaWorld

• PolkaWorld Twitter：

  @polkaworld_org

更多内容

关注 PolkaWorld

发现 Web 3.0 时代新机遇

点个 “在看” 再走吧！