区块链基础通识（1）——分布式系统的共识问题

分布式系统

我们最初了解区块链的时候，很多人会形容这个区块链是一个“分布式的不可篡改账本”，这是一个很形象的说法，但是我认为更为准确的形容是“所有节点共同维护的状态机”。为什么分布式和区块链不能划等号呢？

两种常见的分布式模型

	中心化网络（Client-Server）	去中心化网络（P2P）
交互方式	用户只能和服务器交互	用户之间可以交互
优缺点	通讯速度快，客户端需要存储的信息量少，响应稳定；相对垄断	相对自由；通讯难度随着用户数量成指数级上升
涉及分布式问题	非拜占庭问题（只存在节点挂机情况）	拜占庭问题（存在干扰一致性的恶意节点）

图例

中心化网络的请求模型（响应与箭头方向相反）

去中心化模型的请求模型

比较和联系

1. 对比上述两个图，我们很容易发现——去中心化的通信方式，每个节点需要保存的”通信信道“是超多的，因此这种模型无法适应大量的节点参与

2. 我们拿”微信“来举一个例子。微信的交流，虽然看起来是点对点的（C2C结构），但是实际上是用户请求云服务器来实现的信息交流的。（箭头方向是信息传递方向）

3. 以“种子网络“为例，在其发展初期存在的节点到其后期均被暴风影音等节点垄断。可以看出去中心化向中心化演变是一个自然的趋势。

4. 所以，我们通常的中心化分布式系统，是一个”有超强中心节点的系统“，在这个系统中只要服务器不挂机就是正常运行的，不存在恶意节点破坏一致性问题（因为只有服务器自己说了算）；而区块链涉及的分布式问题往往是有恶意节点存在的，这样的问题被称为“拜占庭将军问题”

拜占庭将军问题

背景

在网络上的节点分为恶意节点（目的是扰乱一致性）和故障节点（挂机）。拜占庭问题解决的是拥有恶意节点的问题；拥有故障节点的成为“非拜问题”

首先，我们来补充一下分布式账本的节点问题。拜占庭问题是由兰波特提出的，为了解决这个问题，采用了从理想化的“口头协议”-->解决网络延时的“PBFT算法”-->区块链使用的“PoW机制”

问题本身

拜占庭帝国派出多支军队进攻一个城池，这个城池十分坚固，一支部队无法攻克，但是多支军队一起攻打即可攻克。现在，将军中有叛徒，他的目的是使得忠诚的部队行动不一致（叛徒的目的是为了扰乱系统的一致性）。这个问题有解的前提是n(总节点个数)>3m(恶意节点个数)。

问题解法

最初的解决方法——口头协议

这个解法使用的模型叫做将军-副官模型，在这个模型的要求下，所有的节点都可以是将军也都可以是副官（我们将第一个发送命令的节点叫做将军，其余的叫做副官，值得注意的是副官与副官之间也可以通信），所有节点需要遵守两个规则：

1. 忠诚的副官们会遵守同一个命令

2. 若将军忠诚，则所有的副官会遵守他的命令

下面我们看一下最基础（m=1、n=4）的情况

副官中出现叛徒：

1. 首先，我们将“将军”发布的命令称为A，即副官1，副官2，副官（叛徒）3收到的将军命令都是A

2. 这时，副官1会询问另外两个副官，得到副官2的“将军给的是命令A”，以及叛徒3给的“将军给的命令是B”（B是假消息）的回答

3. 因此，副官1按照少数服从多数原则，推断出3是叛徒，A是一致性命令。副官2同理

将军是叛徒：

1. 叛徒将军向副官1、2、3分别发送命令A、B、C（叛徒是为了扰乱一致性的）

2. 副官1接到A命令后会联系2、3，得到副官2的“将军给的是命令B”，以及副官3给的“将军给的命令是C”

3. 这时候副官1可以推断出将军是叛徒，同时放弃这一轮的命令（要求的第二条不成立），副官2、3同理

复杂情况（以m=2,n=7为例）

这种方法要注意以下两点：

1. 签名：也就是一个人发布命令的时候需要加上自己的签名，转述别人的信息的时候需要加上他的签名（这是为了保证信息的唯一性），比如上文情况中我使用的“副官说‘将军的命令是......’”这一说法

2. 每个节点使用表格进行决策，这是一种递归嵌套的思想（下面表格展示的每行指的是节点的决策信息，纵列是节点给别人的应答）,假设将军给出的命令是A

	V1给出的应答	V2给出的应答	V3给出的应答	V4给出的应答	V5给出的应答	V6给出的应答
V1		A	A	A	b	f
V2	A		A	A	c	g