# 分布式验证器的委员会聚合 By [April1](https://paragraph.com/@april1) · 2023-02-03 --- 原文链接： [https://blog.obol.tech/committee-aggregations-with-distributed-validators/](https://blog.obol.tech/committee-aggregations-with-distributed-validators/) 翻译：[April1](https://mirror.xyz/0x572FE9a87a9FC0fc123515e62A72C0D70BEa98b5) 新提案表示，会向信标API添加两个新端点，这一提案的实现将允许DVT验证器客户端支持委员会聚合。 ![](https://storage.googleapis.com/papyrus_images/eff9942fa5feff812a9d797312e7109e3c392962eb3508b74c1233e455e8fed0.png) 委员会聚合的基本原则 ---------- 今天，我们想谈谈以太坊权益证明中的两个聚合职责，以及[Charon](https://github.com/ObolNetwork/charon)等分布式验证中间件是如何支持这两个职责的。 以太坊协议有两种委员会：[信标委员会](https://eth2book.info/bellatrix/part2/building_blocks/committees)（Beacon committees）和[同步委员会](https://eth2book.info/bellatrix/part3/containers/dependencies#synccommittee)（sync committees）。委员会是一组验证者，分别承担全套验证活动。 **信标委员会**管理共识协议的见证消息（attestation），而**同步委员会**允许轻客户端快速地、无需信任地确定信标链头。 委员会由验证者组成，验证者需要执行的职责有两种类型，即标准职责和聚合职责。标准职责包括获取数据，对其进行签名，然后将签名的消息提交回信标链。 聚合职责则要将多个标准职责消息组合（聚合）到单个[聚合和证明](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/validator.md#aggregateandproof)消息中。这种聚合由以太坊的[BLS签名方案](https://eth2book.info/altair/part2/building_blocks/signatures#bls-digital-signatures)支持，允许多达数十万个验证者参与权益证明信标链。 聚合职责比标准职责更为复杂。首先，委员会中的每个验证者必须生成一个**选择证明**（selection proof）**，即一个BLS签名。选择证明被传递给IsAggregator**函数，该函数确定该验证者是否属于该时隙（slot）。如果符合，它会通知其共识端链接相应的、用于监控待聚合消息的委员会子网。一段时间后，它会将收集到的消息聚合，并将其与选择证明组合成一条称为**聚合和证明**（A&P）的消息。验证者需要签署A&P并将其提交给信标链。注意，签署后的Aggregate and Proof是一个包含选择证明的嵌套签名。 ![标准职责和聚合职责的工作流流程](https://storage.googleapis.com/papyrus_images/6fd13dc1960e2e8e07eb46ea4d139fc32fba4cb305ae6e22f07e9bf29e3334c5.jpg) 标准职责和聚合职责的工作流流程 当前使用分布式验证器执行委员会聚合面临的问题 ---------------------- 对于如Obol的DVT中间件架构，集群中的每个验证器客户端（VC）只能访问_共享_私钥，而非完整私钥。在DVT中，共享私钥生成的签名为**_部分签名（partial signature）_**。DVT使用[BLS阈值聚合](https://eth2book.info/altair/part2/building_blocks/signatures#bls-digital-signatures)将这些部分签名组合到提交给信标链的最终签名中，称为**_组合签名（combined signature）。_** 这意味着DVT的VC生成的选择证明是**部分选择证明**（partial selection proof）。在**IsAggregator**函数中使用部分选择证明会产生错误结果，因此VC无法判定其是否为聚合器。此外，在组合签名和证明消息中组合不同的部分选择证明会产生不同的结果，这些不同的结果无法由中间件DVT客户端进行阈值聚合。 因此，VC需要以某种方式访问完整的**组合选择证明**（combined selection proof），以便执行其聚合职责。 ![执行聚合任务时的部分签名问题](https://storage.googleapis.com/papyrus_images/987acfe6f865f2ec18b135909370c1521d8782baee4c5945a2559facafca0534.jpg) 执行聚合任务时的部分签名问题 拟议解决方案 ------ 我们一直在与关键的共识层利益相关者（1，2）合作，为信标API提供两个新的非侵入性、非破坏性的端点，允许VC通过提供部分选择证明 来向中间件客户端（Charon）请求组合选择证明。 * POST /eth/v1/validator/beacon\_committee\_selections * POST /eth/v1/validator/sync\_committee\_selections 支持中间件DVT的VC必须在时隙的开始调用这些端点，以获取用于委员会验证者聚合职责（信标委员会和同步委员会）的组合选择证明。 这些端点的服务器端只需要由DVT中间件实现，不需要任何共识客户端（信标节点）。 这些端点的客户端只需要由旨在支持中间件DVT的验证器客户端来实现。点击加入功能的标志即可启用，例如：“--distributed-validator”。 验证器流程 ----- 下面让我们看看证明聚合的工作流程。 * 在验证器要进行证明的时隙开始处，VC生成部分选择证明。 * 它立即调用具有此签名的新POST /eth/v1/validator/beacon\_committee\_selections端点，一旦收到有效聚合的部分签名组合，该端点将返回组合选择证明。 * 组合选择证明响应后，VC使用is\_aggregator函数计算它是否为该时隙的证明聚合器之一。 * 如果该VC不是聚合器之一，则退出此工作流；相反，如果该VC是聚合器之一， * 该VC用IsAggregator=true值调用POST /eth/v1/validator/beacon\_committee\_subscriptions，通知信标客户端开始准备签名的聚合证明。 * 该时隙的2/3聚合器验证后，VC将调用GET /eth/v1/validator/aggregate\_attestation，将从信标节点获取组合证明。 * 组合证明与聚合选择证明组合成聚合和证明消息。 * 最后，VC签署Aggregate and Proof消息并调用POST /eth/v1/validator/aggregate\_and\_proofs，发布签名的聚合证明。 * 请注意，最终生成的已签名的聚合和证明本身就是一个部分聚合和证明，但是由于它包含组合选择证明，DVT中间件能够将其阈值聚合成一个组合的已签名的聚合和证明，并提交给信标链。 值得注意的是，在不改变任何其他现有API的情况下，只需要添加一个新端点来支持证明聚合，并且流程基本保持不变。同样，该方法也适用于支持同步委员会的聚合职责。 ![新的聚合验证器工作流程](https://storage.googleapis.com/papyrus_images/78bb74d3274ab05947d7290cb8f1d6c3056f989d272c55acb8a2db1551437dc2.jpg) 新的聚合验证器工作流程 结论 -- 本文概述了如何提高以太坊上现有验证器的可用性，对共识API规范进行简要扩展，并为验证器客户端提供更多选择。我们认为，DVT可以成为适用于所有客户端的附加功能，这比DVT的自定义验证器客户端签署消息功能更好，类似于mev-boop部分取代mev-geth，降低了客户端的集中化。 这篇文章旨在为基于中间件的分布式验证器，以及为验证器客户端添加信标API这一提议提供反馈、关注和支持。下一步，我们希望该反馈可以应用于共识实施者的[调用](https://github.com/ethereum/pm/issues/667#issuecomment-1329616698)中。 感谢阅读！ --- *Originally published on [April1](https://paragraph.com/@april1/v6UvGc1ayxAquGihqviK)*