CSM v2中的优先队列

本文档已关闭！

请在 https://learnblockchain.cn/article/27223 发表评论并参阅该文档。

CSM v2 中的优先队列

前言

对于 CSM v2，需要找到一种方式，让那些很可能是独立运营者的节点先于其他无需许可的运营者获得存入。由此引入了优先队列的概念——一种优先请求存入数据的队列。同时我们也意识到，参与 CSM 的节点运营者有多种类型，因此有必要针对不同类型设置不同的存入优先级。为实现这一目标，思路是引入多个具有不同优先级的优先队列。

技术设计

CSModule 维护着一个预定义的优先队列列表。每个队列由其索引标识，该索引同时也作为其优先级指示符。索引为 0 的队列拥有最高优先级。该模块拥有固定数量的队列，其数量由部署时常量 LOWEST_PRIORITY 限制。因此，该模块可以处理 [0; LOWEST_PRIORITY] 范围内的任何队列，其中 LOWEST_PRIORITY 被保留用作默认队列。

CSM v2 在模块组成中引入了一个独立的合约，名为 CSParametersRegistry，因此各优先队列的配置存储在注册表中。队列配置如下所示：

struct QueueConfig {
    uint8 priority;
    uint32 maxDeposits;
}

在此结构中，priority 指示使用哪个队列，maxDeposits 表示一个节点运营者通过该优先队列最多可以存入的验证者密钥数量。

节点运营者可以被分配到由其 curveID 标识的组中，因此每个 curveID 都有其对应的优先队列配置。配置并不局限于使用某些特定队列，但保留队列不可使用。我们可以想象如下设置：

curveID    QueueConfig
0          (p0, 10)
1          (p1, 10)
2          (p0, 50)
3          (p3, 10)
...

将密钥添加到队列

节点运营者添加新密钥的机制如下：

1. 获取与节点运营者的 curveID 关联的 QueueConfig。
2. 检查是否存在未存入且未入队的密钥；如果数量低于 QueueConfig.maxDeposits 限制，则可以将这些密钥放入优先级为 QueueConfig.priority 的队列中。
3. 将尽可能多的密钥添加到优先级为 QueueConfig.priority 的优先队列中，其余密钥则添加到默认队列，即优先级为 LOWEST_PRIORITY 的队列。

请注意，节点运营者通过其优先队列最多可以让 maxDeposits 个密钥获得存入。换句话说，以下场景是实际存在的：

1. 节点运营者上传了 10（maxDeposits）个密钥，并将它们放入优先队列。
2. 节点运营者改变主意，移除了所有密钥。
3. 节点运营者在优先队列中的批次被跳过。
4. 由于节点运营者尚未从该队列获得任何存入，因此再次上传 10 个密钥并将它们放入优先队列。

从队列获取存入数据

机制很简单。CSModule 按照优先级顺序（0 -> LOWEST_PRIORITY）遍历队列，并依次处理各队列中的批次：当一个队列耗尽时，就使用下一个队列来获取批次。

队列清理

清理机制与存入数据获取机制类似。队列按照优先级排序并处理，无法获得存入的批次会从对应队列中被移除。

从旧方案迁移

为了将当前队列迁移到新机制，需要为该队列专门分配一个独立的优先级，该优先级不能被任何 curveID 使用。LEGACY_QUEUE_PRIORITY 被设置为 LOWEST_PRIORITY - 1。因此，我们得到如下可用优先级范围：[0; LOWEST_PRIORITY-2]。最终，遗留队列将被全部存入，保留的优先级将被释放，供 CSM 的下一个版本（v3）使用。

• 原文链接： hackmd.io/@lido/Sy7fj_zY...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～