Linera协议中的委员会存储优化方案

背景

在Linera协议中，委员会(committee)的管理机制存在性能瓶颈问题。原有的实现方式要求每个新链都需要通过跨链消息向管理链(admin chain)订阅委员会变更通知。每当新纪元(epoch)产生或旧纪元移除时，管理链都需要向所有订阅者发送跨链消息，这导致系统通道成为性能瓶颈。

原有机制的问题

原有的实现存在几个关键问题：

1. 跨链消息泛滥：每个新纪元或旧纪元移除时，都需要向几乎所有链发送跨链消息
2. 数据冗余：每条链的状态中都保存着委员会的完整副本
3. 系统通道瓶颈：所有订阅和通知都通过系统通道进行，限制了系统的可扩展性

优化方案设计

Linera协议团队提出了一种基于事件流(event stream)和blob存储的优化方案：

核心变更

1. 移除原有机制：

   • 删除CreateCommittee和RemoveCommittee系统消息变体
   • 删除系统通道订阅机制
   • 从所有链状态中移除委员会数据

2. 引入事件流机制：

   • 当管理链创建新委员会时：
     • 将委员会数据存储为新的blob
     • 发出事件流名称为NEW_EPOCH_STREAM_NAME的事件
     • 事件ID为新纪元号
     • 事件内容为blob ID
   • 当管理链移除委员会时：
     • 发出事件流名称为REMOVED_EPOCH_STREAM_NAME的事件
     • 事件ID为旧纪元号
     • 事件内容为空

3. 新增系统操作：

   • ProcessNewEpoch(Epoch)：处理新纪元事件
   • ProcessRemovedEpoch(Epoch)：处理移除纪元事件

客户端同步机制

为了确保所有客户端都能及时获取委员会变更：

1. CLI处理：

   • 处理任何链的收件箱时，同步管理链状态
   • 发现新纪元事件时立即处理

2. 节点服务：

   • 通过gRPC订阅管理链的新区块通知
   • 发现新纪元事件时在所有拥有的链上处理

技术优势

1. 性能提升：

   • 消除了跨链消息的泛滥问题
   • 减少了数据冗余，各链不再保存委员会副本

2. 可扩展性增强：

   • 事件流机制比原有订阅机制更高效
   • 系统通道不再成为瓶颈

3. 简化设计：

   • 移除了复杂的订阅管理逻辑
   • 统一使用blob存储委员会数据

实现细节

在实际实现中，需要注意以下几点：

1. 事件流命名：

   • 新纪元事件流名称定义为&[0]
   • 移除纪元事件流名称定义为&[1]

2. Oracle响应：

   • 处理系统操作时需要从存储读取事件
   • 创建包含事件ID和内容的oracle响应

3. 纪元管理：

   • 每个区块高度仍需明确定义纪元边界
   • 纪元过期无需显式确认，所有链立即生效

总结

Linera协议通过将委员会存储优化为基于事件流和blob的机制，有效解决了系统通道的瓶颈问题。这一优化不仅提升了系统性能，还增强了协议的可扩展性，为Linera网络的进一步发展奠定了坚实基础。