文章探讨了在FOCIL（一种新型的区块包含机制）中选择包含列表委员会成员的几种方法，比较了Beacon委员会方法、同步委员会方法和聚合器方法，各有优缺点，例如在可验证性、保密性和实现复杂性方面存在差异。文章最后指出，FOCIL目前使用了最简单的Beacon委员会方法。
FOCIL 中包含列表委员会的选择
IL 委员会的选择期望
- 委员会成员：规模较小（例如，每个Slot 16 名成员），一个Slot内或整个 epoch 期间没有重复
- 保密性：最好在包含列表委员会成员广播他们的包含列表之前，任何人都无法计算出他们是谁。这有助于缓解 DOS 攻击。
- 可验证性：应该容易验证某个特定的验证者是否被选为包含列表委员会的成员。此外，如果验证者将成为给定Slot的包含委员会成员，则提前进行一些预测应该很简单。
- 简洁性：设计应优先考虑信标链规范和客户端实现的简洁性。例如，验证者客户端应该只需要检索包含消息，签名并返回签名。
我们可能不太关心基于以下属性优化选择：
- 包含列表消息聚合
- 包含列表委员会的奖励和惩罚方案
- 基于验证者有效余额的选择结果偏差
潜在方法
1：信标委员会方法
以类似于信标委员会的方式选择包含列表委员会。 使用信标状态、epoch 和种子，我们获得洗牌后的索引并将它们划分到Slot中。 这些Slot索引的子集构成包含列表委员会。
def get_inclusion_list_committee(state: BeaconState, slot: Slot) -> Vector[ValidatorIndex, IL_COMMITTEE_SIZE]:
epoch = compute_epoch_at_slot(slot)
seed = get_seed(state, epoch, DOMAIN_IL_COMMITTEE)
indices = get_active_validator_indices(state, epoch)
start = (slot % SLOTS_PER_EPOCH) * IL_COMMITTEE_SIZE
end = start + IL_COMMITTEE_SIZE
return [indices[compute_shuffled_index(uint64(i), uint64(len(indices)), seed)] for i in range(start, end)]
备注：
- 易于验证
- 不满足保密性，因为任何人都可以预先计算出 IL 委员会成员
- 易于扩展以用于奖励和惩罚方案
- 验证者有效余额不影响选择，这意味着合并的验证者与未合并的验证者被选为 IL 委员会成员的机会相同
- 在 IL 委员会规模大于验证者总数 / 32 的极端情况下，会增加一些规范测试的复杂性
这是一个改进的版本，更具可读性和清晰度：
2：同步委员会方法
以类似于 proposer 和同步委员会的采样方式选择包含列表委员会。 洗牌后的索引逐个处理，有效余额会影响选择结果。
def get_inclusion_list_committee(state: BeaconState) -> Sequence[ValidatorIndex]:
epoch = Epoch(get_current_epoch(state) + 1)
MAX_RANDOM_BYTE = 2**8 - 1
active_validator_indices = get_active_validator_indices(state, epoch)
active_validator_count = uint64(len(active_validator_indices))
seed = get_seed(state, epoch, DOMAIN_IL_COMMITTEE)
i = 0
inclusion_list_committee_indices: List[ValidatorIndex] = []
while len(inclusion_list_committee_indices) < IL_COMMITTEE_SIZE:
shuffled_index = compute_shuffled_index(uint64(i % active_validator_count), active_validator_count, seed)
>- 原文链接： [hackmd.io/@ttsao/il-comm...](https://hackmd.io/@ttsao/il-committee-selection)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
