拜占庭将军问题

大致：

在 存在消息丢失的不可靠信道上 试图通过 消息传递 的方式达到 一致性 是 不可能 的

来源

由于当时拜占庭罗马帝国国土辽阔，为了达到防御目的，每个军队都分隔很远，将军与将军之间只能靠信差传消息。在战争的时候，拜占庭军队内所有将军和副官必须达成一致的共识，决定是否有赢的机会才去攻打敌人的阵营。但是，在军队内有可能存有叛徒和敌军的间谍，左右将军们的决定又扰乱整体军队的秩序。在进行共识时，结果并不代表大多数人的意见。这时候，在已知有成员谋反的情况下，其余忠诚的将军在不受叛徒的影响下如何达成一致的协议，拜占庭问题就此形成

自己的理解

即存在不可信通信点，信道不可靠的情况下，如何达成一致性

问题描述（距离快速了解）

当有三个将军，其中一个为叛徒时

这样是解决不了一致性问题

这样也是，解决不了

当有四个将军，一个为叛徒时

在 N ≥ 3F + 1 的情況下一致性是可能解決
（N为总计算机数，F为有问题的计算机总数）

互联网理解

“拜占庭将军问题”延伸到互联网生活中来，其内涵可概括为：在互联网大背景下，当需要与不熟悉的对方进行价值交换活动时，人们如何才能防止不会被其中的恶意破坏者欺骗、迷惑从而作出错误的决策。进一步将“拜占庭将军问题”延伸到技术领域中来，其内涵可概括为：在缺少可信任的中央节点和可信任的通道的情况下，分布在网络中的各个节点应如何达成共识

问题

在中本聪发明比特币以前，世界上并没有一个非常完美的方法来解决“拜占庭将军问题” [5] 。
究其根底，“拜占庭将军问题”最终想解决的是互联网交易、合作过程中的四个问题：
（1）信息发送的身份追溯
（2）信息的私密性
（3）不可伪造的签名
（4）发送信息的规则
“拜占庭将军问题”其实就是网络世界的模型化
仅拿比特币世界来说，我们可以将每一个比特币交易账号看作一个将军，这些账号分布在世界各地，无法聚在一起，很可能会有恶意账号，账号之间的沟通也很可能因为机器坏了、网络断了、黑客攻击等受到破坏，并且有关账号是不是要支付、具体支付多少的讨论也会浪费很多时间

区块链–解决拜占庭问题的方法

区块链轻而易举地解决了这一问题，它为信息发送加入了成本，降低了信息传递的速率，而且加入了一个随机元素使得在一定时间内只有一个将军可以广播信息。这里所说的成本就是区块链系统中基于随机哈希算法的“工作量证明”。哈希算法所做的事情就是计算获得的输入，得到遗传64位的随机数字和字母的字符串

区块链系统计算的输入数据是指节点发送的当前时间点的整个总账。当前计算机的算力使其可以实时计算出单个哈希值，但是区块链系统只接受前13个字符是0的哈希值结果作为“工作量证明”。而前13个字符是0的哈希值是非常罕见的，需要整个网络花费10分钟的时间才在数以亿计的数据中找到一个。在一个有效的哈希值被计算出来之前，网络中已经生产了无数个无效值，这就是降低信息传递速率并使得整个系统成功运行的“工作量证明”。

在拜占庭将军问题中，第一个广播信息的将军就是第一个发现有效哈希值的计算机，只要其他将军接收到并验证通过了这个有效哈希值和附着在上面的信息，他们就只能使用新的信息更新他们的总账复制，然后重新计算哈希值。下一个计算出有效哈希值的将军就可以将自己再次更新的信息附着在有效哈希值上广播给大家。然后哈希计算竞赛从一个新的开始点重新开始。由于网络信息的持续同步，所有网络上的计算机都使用着同一版本的总账 。

比特币区块链系统找到有效哈希值的时间间隔为10分钟，这是算法设置好的。算法难度每隔两周调整一次就是为了保证这10分钟的间隔，不能多也不能少。每隔10分钟，总账的信息就会在区块链更新并在全网同步一次。因此分散的交易记录是在所有网络上的计算机之间进行对账和同步的 。

当个人用户在区块链系统发起一笔交易的时候，他们会使用私钥和公钥为这笔交易签名，而内嵌在比特币系统的标准公钥则承担了加密工具的角色，对应在拜占庭将军问题中，加密工具就是用于签名和验证消息的印章。
因此，哈希算法对信息传递速率的限制加上加密工具使得区块链构成了一个无须信任的数据交互系统。在区块链上，一系列的交易、时间约定、域名记录、政治投票系统或者任何其他需要建立分布式协议的地方，参与者都可以达成一致

Byzantine Fault Tolerant算法

面向拜占庭将军问题的容错算法，解决的是网络通信可靠，但节点可能故障情况下的一致性达成。
最早由Castro和Liskov在1999年提出的Practical Byzantine Fault Tolerant（PBFT）是第一个得到广泛应用的BFT算法。只要系统有2/3的节点是正常工作的，则可以保证一致性。

PBFT算法包括三个阶段来达成共识：Pre-Prepare，Prepare和Commit。如下图所示：

Request：请求端C发送请求到主节点，这里是0节点；
Pre-Prepare：节点0收到C的请求后进行广播，扩散至123；
Prepare：123节点收到后记录并再次广播，1->023，2->013，3因为宕机无法广播；（这一步是为了防止主节点给不同从节点发送不同的请求）
Commit：0123节点在Prepare阶段，若收到超过一定数量（2F，实际使用中，F为可以容忍的拜占庭节点个数）的相同请求，则进入Commit阶段，广播Commit请求；
Reply：0123节点在Commit阶段，若其中有一个收到超过一定数量（2F+1）的相同请求，则对C进行反馈；

根据上述流程，在 N ≥ 3F + 1 的情況下一致性是可能解決，N为总计算机数，F为有问题的计算机总数。