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