使用 BLS 聚合签名的分组共识方案（一） | 技术云图

分组共识方案在现有 Giskard 共识基础上，将验证节点集合随机分组，每个分组中的节点只需要在组内达成消息共识并生成该消息的 BLS 聚合签名，各分组再进行组间签名交换，将所有分组的签名重新聚合成完整的签名结果，从而实现该消息在整个网络的最终一致性。该方案可…

· 12 分钟前

分组共识方案在现有 Giskard 共识基础上，将验证节点集合随机分组，每个分组中的节点只需要在组内达成消息共识并生成该消息的 BLS 聚合签名，各分组再进行组间签名交换，将所有分组的签名重新聚合成完整的签名结果，从而实现该消息在整个网络的最终一致性。该方案可提升现有 Giskard 共识的可扩展性，降低网络通信复杂度、消息复杂度。

使用 BLS 聚合签名的目的

缩小共识范围，不需要每个验证节点都处理网络中所有的共识消息，只聚焦本组节点的消息签名，以此降低整个网络的通信复杂度和消息数量。同时，随机分组可以尽可能的减小恶意节点联合控制分组共识，最大限度地降低整个分组作弊的可能性。

目的分组节点的角色划分

在 Giskard 1.0 中，为了尽快达成消息共识，每个节点产生的消息（prepareBlock、prepareVote、 viewChange 等）都尽可能的发送并转发给所有共识节点，传输开销在具有个节点的网络中达到了。因此，当节点超过一定数量时，协议的性能会急剧下降，且节点的网络流量也会大幅增加。倘若这些消息不发送给所有节点，而是通过 gossip 协议在整个网络中传播，消息的传播周期和消息总量依旧不可控。

为了支撑更多的共识节点数，设计了分组共识方案。验证节点通过分组机制分组后，被分成两种角色：

普通节点（Slave node）：只关注本组内共识，这类节点只会将共识消息在本组内发送和转发，不对外（其他分组）发送和转发共识消息（分组聚合签名消息）
协调节点（Leader node）：对本分组进行统一控制，这类节点不仅需要将共识消息在本组内发送和转发，还需要和其他分组的节点通信（主要用于组间 BLS 聚合签名交换）

协调节点对整个系统共识至关重要，考虑到网络的不确定性以及节点作恶的可能性，每个分组至少需要不少于分组节点总数 1/5 的协调节点，比如某个分组有 25 个节点，那么该分组一般设置为 20 个普通节点和 5 个协调节点。

同时考虑到协调节点不作为的判断依据难以确认并且重选机制复杂，这些逻辑势必会给系统带来额外开销，因此分组内的每一个节点在这两种角色上的划分并非固定，普通节点在监测到本组内的协调节点不作为时，可自动升级为协调节点并对外通信，但这也可能会造成更多的消息数量。

使用 BLS 聚合签名的分组共识方案（一） | 技术云图