翻译solana文档 原文链接 https://docs.solana.com/cluster/leader-rotation
领导轮换
在任何给定时刻，集群都希望只有一个验证器生成账本条目。 通过一次只有一个leader，所有验证者都能够重放账本的相同副本。 然而，只有一个leader的缺点是恶意leader能够删减投票和交易。 由于无法将删减与网络丢包区分开来，因此集群不能简单地选择单个节点无限期地担任leader角色。 相反，集群通过轮换leader节点来最大程度地减少恶意leader的影响。
每个验证者使用如下相同的算法选择预期的leader。 当验证者收到一个新的带有签名的账本条目时，可以确定该条目是由预期的leader生成的。 给每个leader分配一个插槽，并对插槽排序，此过程称为leader调度。
领导者轮换调度
验证者拒绝没有由插槽leader签名的块。所有插槽leader的身份列表称为leader清单。leader清单在本地定期重新计算。在称之为epoch的期间内，会给插槽分配leader。清单必须在它分配插槽之前很早被计算出来，以确保计算清单时的账本状态是确定的。这个期间称为leader清单偏移量。 Solana 将偏移量设置为直到下一个 epoch 的时隙持续时间。也就是说，一个 epoch 的leader清单是根据前一个epoch开始时的账本状态计算的。一个 epoch 的偏移量是相当任意的，并且假设足够长，以至于所有验证者都将在生成下一个清单之前使账本达到共识。集群可以选择缩短偏移量以减少质押更改和leader清单更新之间的时间。
由于系统在没有分区的情况下运行时会超过一个epoch， 只需要在根分叉越过 epoch 边界时生成清单。由于清单是针对下一个 epoch 的，因此提交给根分叉的任何新质押在下一个 epoch 之前都不会激活。用于生成leader清单的块是第一个跨越 epoch边界的块。
如果没有一个分区持续时间超过一个epoch，集群将按如下方式工作：
验证者在投票时不断更新自己的根分叉。
每次槽高度越过 epoch 边界时，验证器都会更新其leader清单。
例如：
假设一个epoch持续时间为100 个插槽，这实际上是更高的数量级。根叉从在槽高度 99 处计算的叉更新为在槽高度 102 处计算的叉。槽高度为 100、101 的叉由于故障而被跳过。新的leader清单是在槽高度 102 处使用分叉计算的。它从槽 200 开始处于活动状态，直到再次更新。
不会存在不一致的情况，因为与集群投票的每个验证器在其根通过 102 时都跳过了 100 和 101。所有验证器，无论投票模式如何，都将提交给 102 或 102 的后代的根。
带 Epoch 大小的分区的领导者清单轮换。
leader清单偏移的持续时间与集群对正确leader清单的看法不一致的可能性有直接关系。
考虑以下场景：
两个分区，每个分区生成一半的块。两者都没有达到绝对的绝对多数分叉。两者都将跨越 epoch 100 和 200，而无需实际提交根节点，因此集群范围内对新领导者计划的承诺。
在这种不稳定的场景中，存在多个有效的领导者调度。
为每个直接父级在前一个 epoch 的分叉生成一个领导者计划。
领导者计划在后代分叉的下一个 epoch 开始后有效，直到它被更新。
每个分区的调度将在分区持续超过一个时期后发散。出于这个原因，epoch 持续时间应该选择比 slot time 和 fork 提交给 root 的预期长度大得多。
在观察集群足够长的时间后，可以根据中值分区持续时间及其标准差来选择领导者调度偏移量。例如，一个比中位数分区持续时间更长的偏移量加上六个标准差，可以将集群中账本计划不一致的可能性降低到百万分之一。
创世配置中生成leader清单
创世配置中声明了第一个epoch的第一个leader。前两个epoch中leader都是这个，因为在插槽0的时候会生成下一个epoch的leader清单。前两个epoch的长度可以在创世文件中指定。第一个epoch的最小长度必须大于等于Tower BFT中定义的最大回滚深度。、
leader清单生成算法
leader清单使用预先定义的种子生成。步骤如下：
- 定期使用PoH 时钟高度 (一个单调递增的计数器) 来构造一个稳定的伪随机算法。
- 在那个高度，以银行中所有具有leader身份且在集群配置的tick数内投票的质押账户为样本。 该样本称为活动集。
- 按质押权重对活动集进行排序。
- 使用随机种子，根据质押权重选择节点来创建一个 质押-权重 排序。
- 此排序在集群配置的若干个tick后生效。
清单攻击向量
种子
选择的种子是可预测的，因此结果不会有歧义。没有攻击会影响其结果。
活动集
leader可以通过删减验证者投票来影响活动集。leader删除活动集有两种可能的方法：
- 忽略验证者的投票
- 拒绝用验证者的投票给区块投票
为了减少删减的可能性，在活动集采样持续时间内在leader清单偏移边界处计算活动集。活动集采样持续时间足够长，以至于投票将被多个leader收集。
质押
leader可以删减新的质押交易或拒绝验证具有新质押的区块。这种攻击类似于对验证者投票的删减。
验证者操作密钥丢失
leader和验证者应该使用临时密钥进行操作，并且权益所有者通过委托授权验证者使用他们的权益。
集群应该能够从leader和验证者使用的所有临时密钥的丢失中恢复，这可能通过所有节点共享的通用软件漏洞发生。即使权益当前已委托给验证者，权益所有者也应该能够通过共同签署验证者投票来直接投票。
追加条目
leader清单的生命周期称为 epoch。 epoch被分成多个槽，其中每个槽的持续时间为 T个 PoH 的tick。
leader在其负责的插槽中传输条目。 在 T 个tick之后，所有验证者都切换到下一个预定的leader。 验证者必须忽略在领导者分配的插槽之外发送的条目。
下一个leader必须观察到上一个leader的所有tick，以便它在其上构建自己的条目。 如果未观察到条目（leader关闭）或条目无效（leader有错误或恶意），则下一个leader必须产生tick以填补前一个leader插槽内tick的空缺。 请注意，下一个leader应该并行执行修复请求，并推迟发送tick，直到确信其他验证者也未能观察到前一个leader的条目。 如果leader错误地建立在自己的tick上，跟随它的leader必须替换所有tick。