The Science of the Blockchain学习笔记（三）

前言

衷心感谢《The Science of the Blockchain》一书的作者Roger Wattenhofer。《The Science of the Blockchain》一书较为严谨地介绍了一种基础技术——容错分布式系统（faulttolerant distributed system）。

在容错分布式系统中，数据存储在多台服务器上，并且多台服务器协同完成一项计算操作。这里面，最大的问题便是如何进行协调（coordination problem）。围绕协调问题，研究人员提出了诸多算法与模型，如：区块链，一致性协议，电子合同，共识机制，电子账本，溯源系统，等。

容错分布式系统具有许多重要作用：
（1）同一份数据在多台服务器上进行备份，当一台服务器宕机或遭到黑客恶意攻击时，仍可从其它正常服务器获取或恢复数据（从另一角度出发，多中心化防止了一台服务器的腐败，message corruption一词用的很有意思）。
（2）客户端$C_1$离$S_a$较近而离$S_b$较远，客户端$C_2$则相反，且$S_a$和$S_b$提供相同的服务。但只有一台服务器时，总有一个客户端的响应时间较长，而有多台服务器时，客户端可就近获取服务，减少响应时长。

Randomized Consensus

思考如下场景：每个节点从输入域 { 0 , 1 } \{0, 1\} {0,1}中随机挑选一个值作为输入，期待通过该操作使所有节点达成共识。假设有$n$个节点，那么通过1次上述操作恰巧达成共识的概率为$\frac{2}{2^n}=\frac{1}{2^{n-1}}$，而不能达成共识的概率为$(1-\frac{2}{2^n})$，执行$x$次操作依旧不能达成共识的概率为$(1-\frac{2}{2^n}{)}^x$，我们求解$x$使得上述概率值逼近0。

参考文章《事件必然发生的充分事例数 》，若取概率值为0.05，$p=\frac{1}{2^{n-1}}$，$(1-p{)}^x=0.05$，有$x=\ln 0.05/\ln (1-p)$，当$p$很小时，$\ln (1+p)=0+p$。所以，$x=\ln 0.05/(-p)=3/p=3\times 2^{n-1}$。可见，$x$为$O(2^n)$。我这里仅注释为何Ben-Or算法的期望轮数为$O(2^n)$，至于为何这样子推演，需请教数学家或经济学家，我也不懂。

Ben-Or协议设计思路

0. 敲黑板，注意这里是异步模型，我们需要重点考虑如何让节点自己决定是否该停止协议了；
1. 让每个节点观察网络中的值分布；
2. 对每个节点，若它认为网络中有半数以上的值都是$v$则发起议案$v$，否则提交议案$\perp$（即无效符号）；
3. 让每个节点观察网络中的议案值分布；
4. 对每个节点，若它认为网络中有半数以上的议案值都是$v$则可考虑停止协议（记该节点为A），理由如下：如果有半数以上议案值为$v$，那么其它节点必能收到至少1个值为$v$的议案（半数以上 + 半数以上 > 总数，即有交集），令这些其余节点值改为$v$，现在，至少半数节点值为$v$（因为$n-f>n/2$），让A再广播1次议案$v$，其余节点可收到半数以上的议案$v$，它们跟着停止协议。
5. 当步骤4不成立时，需要打破该窘境：对每个节点，若收到的议案值皆是$\perp$，则让它自己从输入域里随机挑选一个新值覆盖原有值；若存在收到议案值$v$，则用$v$覆盖原有值。由于网络通信的不确定性，后者也可以看成1次随机操作。透过之前的分析，已知$O(2^n)$轮操作后“必然”出现全0或全1情形，那么步骤4“必然”出现，即协议“必然”在有限时间内停止。

随机共识Ben-Or协议具体描述如下：

为什么议案需要附上round？ 注意这里是异步模型。

再考虑如下情形，假想有5个节点：A（1），B（0），C（1），D（0），E（1）。符号$F_i$表示第$i$轮提议为$F$。节点A网速很慢导致

由超时重传机制可知${\perp }_1$、${\perp }_2$和${\perp }_3$等会反复送至A节点直至A节点接收到信息，这使得A节点最终轮数会追上最新轮数，且A节点提出的$\mathsf{p}\mathsf{r}\mathsf{o}\mathsf{p}\mathsf{o}\mathsf{s}\mathsf{e}(\cdot ,1)$和$\mathsf{p}\mathsf{r}\mathsf{o}\mathsf{p}\mathsf{o}\mathsf{s}\mathsf{e}(\cdot ,2)$是不起作用的（会被其它节点直接扔掉），这时，只要A节点不死机，它最终会承认当前网络共识值（假想最后BCDE都同意选举值0）。

引理3.6 只要没有结点的decide设为True，无论哪个结点崩溃，算法3.15都会一直正常运行下去。

证明. 把decide = True命令行从原算法中移除出去，再移除相关命令行，可以发现，算法“卡”住的地方只有命令行6和16，即等待半数以上消息的步骤，因$f<n/2$，故命令行6和16依旧能够正常运行下去。$■$

引理3.7 算法3.15满足共识机制定义的有效性要求（具体请看定义）。

证明. 结点提出的议案值由$v$决定，而 v ∈ { 0 , 1 } v \in \{0, 1\} v∈{0,1}。接下来仅需重点考虑一种情形：在初始时所有结点$v$值一样，假设此时为1，我们需判断算法是否会走到命令行23这一步（这一步可能导致共识值为0而与有效性要求起冲突）。注意此时所有结点值为1，那么所有结点提出的议案值皆为1，进入命令行17，所有结点值为$v_i=1$且令decide = True，算法输出共识值1，不会走到命令行23。$■$

引理3.8 算法3.15满足共识机制定义的一致性要求。

证明. 记$u$为第一个设置decide = True的结点，且该事件发生在第$r$轮。$u$收到半数以上值为$v$的议案，意味着当前网络半数以上结点值为$v$，不能存在一个值为$v^{\prime }\ne v$的议案。我们分析当$u$在命令行14停止后其余结点是否会“卡”住。

对结点$u^{\prime }\ne u$，分为2种情况：① 它同样也收到半数以上议案$v$；② 它收到至少1个议案$v$（注意半数以上 + 半数以上 > 总数）。

对情形①，结点$u^{\prime }$直接停止。

对情形②，所有结点在第$r$轮设置$v_i=v$，在第$(r+1)$轮广播值$v$，这使得所有结点提出议案$v$，接着所有未停止结点收到半数以上议案$v$，设置decide = True，并在第$(r+2)$轮停止，最终达成共识。$■$

引理3.19 算法3.15满足共识机制定义的终止性要求。

证明. 从引理3.18的证明中可知，若有一个结点收到半数以上议案$v$，算法在2轮后停止。我们仅需讨论$r$的期望值取多少。当网络所有结点值一样时，结点$u$必然收取到半数以上议案$v$，前面讨论已知，当$r$的期望值为$O(2^n)$时，必然出现网络所有结点值一样的情形。算法在有限时间内以大概率停止。$■$

定理3.20 当$f<n/2$时，算法3.15在$O(2^n)$轮交互后所有结点达成共识。

定理3.21 当$f\ge n/2$时，没有任何一个共识算法可以处理异步场景。

证明. 将整个网络等分成$N$和$N^{\prime }$两部分，即$N$和$N^{\prime }$各自持有半数结点且没有交集。假想$N$中所有结点值为0，且此时$N^{\prime }$与$N$互发消息传输极慢，它们不知彼此的值分布，$N$可以采取以下2种策略：

① 选择等待：若$N^{\prime }$在重复发消息阶段不幸崩溃，$N$将无限循环等待下去，与终止性要求冲突。
② 在一段时间后选择输出一个共识值：该情况又分为以下2种情形：

a. 选择输出1：若$N^{\prime }$中所有结点值为0，即整个网络所有结点值为0，与有效性要求冲突；
b. 选择输出0：若$N^{\prime }$中所有结点值为1，由①和②-a易知，$N^{\prime }$会选择输出1，即$N$选举出0而$N^{\prime }$选举出1，与一致性要求冲突。

通过列举反例来证明定理3.21。$■$

算法3.15速度较慢，能否通过使命令行22恒输出1来进行加速？

答案是否定的。若命令行22恒输出1，则算法3.15是确定性算法，由定理3.14可知这样的算法不安全。

假设命令行22恒输出1，以下通过演示2个例子来说明算法不安全。

① 网络有3个节点，陷入死循环：

② 网络有5个节点，令关键节点（红色框对应的节点）宕机，陷入死循环：

Reference

Ellis Michael. RANDOMIZED CONSENSUS
事件必然发生的充分事例数