我最近一直在对 Paxos 进行大量研究，我一直想知道的一件事是，我没有看到任何答案，这意味着我必须问。
Paxos 包含一个不断增加的提案编号（可能还有一个单独的整数，具体取决于您正在阅读的论文的作者）。当然，两个潜在的领导者可能会陷入决斗，每个人都试图在恶性循环中超越对方。但是当我在拜占庭式 P2P 环境中工作时，这让我如何处理那些试图将提案编号设置得非常高的提案者——例如，最大 32 位或 64 位字。
与语言无关、平台无关的基于 Paxos 的协议应该如何处理提案编号和/或轮数的整数最大值？尤其是故意/恶意的情况，这使得溢出回 0 的模算术方法有点没有吸引力？
从我所读到的内容来看，我认为这仍然是一个未在文献中解决的悬而未决的问题。
Byzantine Proposer Fast Paxos解决了拒绝服务问题，但仅限于通过与递增（提议）计数器泛滥无关的攻击延迟消息发送的类型。
话虽如此，整数溢出可能是您遇到的最少的问题。与其考虑整数溢出，不如先考虑成员资格攻击（通过 DoS）。在多个节点达成共识后了解成员资格可能是一种可行的策略，但在某种程度上可能仍然容易受到Sybil 攻击。
另一种策略可能是为提案合并一些工作量证明系统，以限制请求的泛滥。然而，很难知道用什么作为衡量指标来平衡（例如，当你在比特币中挖掘区块链时的自由货币）。这实际上取决于您要构建的系统类型。您应该考虑系统中信息的价值，然后创建一个工作量证明系统，该系统需要稍高的成本来规避。
但是，一旦您能够减慢提案计数器的速度，您仍然需要担心任何具有大量（有效）操作的系统中的整数最大值。您应该有一个数字换行策略或多精度方案，您可以清楚地确定您的网络可以运行多少年/几十年而不会遇到麻烦而不会破坏固定精度计数器。如果您可以确定您的系统将运行 100 年（或其他任何时间）而不会破坏您的固定精度计数器，即使是恶意实体，那么您可以选择简化事情。
在另一个（重要的）注意事项上，大多数论文中使用的系统模型并没有反映使现实实现变得实用的所有内容（Raft是一个很好的例外）。如果有的话，一些作者犯了创建一个旨在避免他们尚未找到答案的难题的系统模型的罪行。因此，如果有人说 X 可以解决所有问题，请注意他们只是表示它可以解决他们定义的非常具体的系统模型中的所有问题。另一方面，您应该考虑到系统模型与“Y 是不可能的”声明密切相关。解释这个概念的一个很好的例子是Ben-Or 共识算法的完全异步消息传递它在系统模型的状态机中使用非确定性来避免FLP 不可能结果指定的限制（它指定当系统模型的状态机是确定性时，共识需要部分异步消息传递）。
所以，在你读到一个证明说它不能完成之后，你应该继续考虑“不可能”。Nancy Lynch就这个概念写了一篇很好的文章。
我想我真正想说的是，您的问题的一个好的解决方案实际上还不存在。如果你弄明白了，请发表它（或者如果你找到现有的论文，请告诉我）。