一、概述
这一改动为提案人选择带来两个简单的优化：
- 它使我们能够查看更多最近的投票历史，从而使系统反应更快
- 使提案人选择的可预测性大大降低，减少恶意行为者的攻击面
1. 背景
在 Aptos 链中，进展是按轮次组织的。在每一轮中，都会提出新的区块并进行投票。每一轮都有一个特殊的角色—提案人，负责收集上一轮的投票并为本轮提出新区块。提案人的选择（决定哪一个节点应在一轮中成为提案人）的目标是
- 对所有节点公平 —— 既要求所有节点做公平的工作量，又让它们获得公平的奖励（结合质押奖励逻辑）。公平份额的意思是应该与它们的质押成正比。
- 优先选择运行正常的节点，因为回合失败会增加提交延迟并降低吞吐量
当前的提案人选择是通过提案人和投票者的领导者声誉算法（ProposerAndVoter LeaderReputation algorithm）完成的。该算法会查看过去的历史，其中一个 window 用于查看提议者的历史，另一个较小的 window 用于查看投票者的历史。然后为每个节点选择 reputation_weight：
TIP
译者注：“window”指的是一个时间窗口，指一段特定的时间范围或历史记录。表示对过去一段时间内的数据进行观察、分析或计算的时间段。
- 如果提案人窗口内提案人回合失败率严格高于阈值，则使用 failed_weight（当前为 1）
- 否则，如果节点没有提案轮次，也没有成功投票，则使用 inactive_weight（目前为 10）。
- 否则，使用默认的 active_weight（目前为 1000）。
然后，storement_weight 按照 staked_amount 的比例缩放，并根据这些权重伪随机地选择下一个提案人。
window 大小的选择既要足够大，以便有足够的信号来保持合理的稳定性，又不能太大，以便能更快地适应变化。对于每个区块，我们只能获得一个节点的提案人信号，但三分之二的节点都是投票者信号。这意味着提案人 window 需要大一些，而投票 window 可小一些。
TIP
译者注： “proposer window”：提案人 window，是指用于收集提议者信号的时间段。 “voting window”：投票 window，是用于收集选民信号的时间段。
2. 动机和规范
本建议是将 ProposerAndVoter 升级为 ProposerAndVoterV2 选择算法。新的提案人选择算法在逻辑上做了两处改动：
-
选民历史 window
- 为了查看历史节点性能，我们会查看
(轮次 - 10*验证者数量 - 20, 轮次 - 20) window 内的提案。对于投票者，我们查看的是（轮次 - 10* 验证者总数 - 20，轮次 - 9* 验证者总数 - 20） 。我们忽略了最后 20 轮，因为历史记录会被视为已提交信息，而共识和提交是分离的，两者之间可能会有几轮延迟。除此之外，投票者 window 就没有必要那么陈旧了。有了新的变化，我们将关注(轮次 - 验证者数量 - 20, 轮次 - 20)范围内的投票人。 
- 这一变化的主要影响是，正在加入验证器集的节点或离线/滞后一段时间后刚刚赶上的节点，在被视为活跃节点并被选为提案人之前的延迟时间将大大缩短。
- 为了查看历史节点性能，我们会查看
-
伪随机选择的种子
- 目前用于伪随机选择的种子是元组（时间、轮次）。这使得每一轮都是独立的随机选择，但又是可预测的。这就意味着，要想知道谁将在未来几轮中成为被选中的提案人相对比较容易，这就给恶意行为者提供了更容易攻击/利用网络的方法。可预测的领导者选举简化了攻击，这有多种已知的方法：只攻击领导者可以更容易地实现拒绝服务；如果事先知道领导者，潜在的交易前置运行就更容易了，等等。在新的变更中，种子将变为（根哈希、时期、轮次），从而大大降低了可预测性。
3. 参考实现
二、风险和缺点
TIP
译者注：原文未提供
三、未来潜力
TIP
译者注：原文未提供
四、建议实施时间表
上述的拉取请求（PR）已经被提交，正在接受测试，并准备发布到主网。 为了启用上述更改，需要执行额外的治理提案以就链上配置达成共识。端到端的冒烟测试（E2E smoke test ）也已经完成，以确认治理提案可以顺利执行。
它已经在开发网（Devnet）上运行了超过一周，尽管开发网有其限制，并且只有AptosLabs运行验证者，因此更改没有经过压力测试。 我们将在一周或两周内在测试网（testnet）上进行测试。 如果不需要进一步的更改，计划在 12 月底创建提案并提交进行投票。
原文链接：https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-1.md