请注意，在最新的 runtime 升级 (9090) 之后，现有的提名人还是可以在所有条件下更新他们对验证人的选择。

当前的 Staking 参数如下：

• 验证人最低绑定金额：无

• 最大验证人数：1200

• 提名人最低质押：80 DOT

• 提名人最大数：22500

• 冻结阈值：90%

新议案的参数只更新一个值：提名人最低质押：120 DOT

Parity 团队的目标是将限制提高到足够大，以便至少在一个月内不需要再做一次调整。Parity 开发团队也正在其他解决方案上进行优化，你可以在这里查看有关它们的更多信息。https://github.com/paritytech/substrate/issues/9511

此外，Parity 团队发布了 8 月份的 Staking 进度报告以分享技术细节。https://gist.github.com/kianenigma/aa835946455b9a3f167821b9d05ba376

将参数值增加到 120 DOT 可以让团队有更多时间去进行优化，直到在更持久的解决方案上取得了进展。请记住，这些措施是暂时的，总体目标是网络的稳定性和安全性。

如果你想了解技术版的 NPoS 机制难点，解决方案和瓶颈，可以继续阅读下面内容。

NPoS 在区块链中是一个非常难以解决的问题。原因是我们想要一个主权算法（无论是不是我们目前使用的 phragmen 算法）为我们在链下解决 NPoS 的问题，并将解决方案重新提交到链上。

NPoS 的问题可以概括为：给定一个提名的输入 graph，找到每个提名人的质押分布，然后优化某些目标。例如，假设 Alice 提名 Bob、Charlie 和 Dave。Bob 和 Charlie 在活跃的验证人节点池中。Alice 的质押应该如何在他们之间分配？Dave 呢？

对比 DPoS 的简单性，他不存在这样的问题，因为每个提名人只支持一个账户。即使你可以支持多个账户，你的质押也是在它们之间平均分配，或者根据一些预定义的顺序进行分配。

NPoS 在 Substrate 链中的设计目标为：

• 获得最少支持的验证人的支持质押数额，应该被最大化。

• 所有当选的验证人的支持质押总和，应该是最大的。

• 所有当选的验证人的支持质押的平方和，应该最小化。

我们有一套算法来解决 NPoS 问题，进一步优化它并减小它的大小，所有这些都打包在 sp-npos-election 中。

在 runtime 中，我们有一个专用的模块来执行我们的多阶段、面向链下的选举过程，命名为pallet-election-provider(-multi-phase)，Pallet-staking 只会使用选举模块，不处理选举本身的细节。

当前系统的一个重要部分是 pallet-staking 和 pallet-election-provider 没有跟上彼此的变化，但这是故意的。在某些时候，pallet-staking 将需要向 pallet-election-provider 提供其提名人和验证人（或其子集）的快照。从这一点开始，两个模块可以独立工作。

这个设计对我们有很多好处。最重要的是，我们可以使用快照作为所有提名人和验证人的索引查找来源。在链下计算和提交的所有解决方案中，我们从不使用帐户 ID，而是使用更高效的快照索引。

考虑到系统的设计，让我们看看主要的瓶颈：

• 快照创建：这种情况发生在 on_initialize 上，很容易造成繁重的块。更重要的是，每个块可以使用多少内存是有严格限制的，所以我们肯定不能在一个块中迭代大量的提名人。

• 解决方案提交：提交的解决方案也不能达到块大小限制，也不能达到块内存限制。后者是低拥塞的真正瓶颈。

• 解决方案验证：解决方案需要在某个时候进行验证。这需要针对快照发生，因此又是一个内存密集型操作。

所有这一切的解决方案，以及我们的行动方向是在多个块上完成所有这些。快照将在多个块上进行，结果快照将是一个 page-index -> snapshot-page 的映射，而不是一个大的平面快照。

解决方案需要考虑到这一点。它需要以一种可以理解的方式向链提供提名人指数。每个提名人现在都可以通过（页面，索引）元组识别，而不是通过单个索引来识别提名人。

同样，解决方案验证也需要考虑到这一点，将解决方案的每个页面与快照中对应的页面进行验证。最后，需要将部分解决方案合并为一个解决方案。