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$提供相同的服务。但只有一台服务器时，总有一个客户端的响应时间较长，而有多台服务器时，客户端可就近获取服务，减少响应时长。

状态复制

定义2.8（状态复制，state replication） 网络中所有结点的初始状态一样，然后执行相同序列的命令$(c_1,c_2,c_3,\dots )$，则称该网络实现了状态复制功能。

复制状态机是一个计算机网络，整个网络系统就像单个状态机那样运行，即：当一台计算机状态欲发生变化且获得整个网络系统许可（一个时刻仅有$n\le 1$台计算机获得许可）时，这台计算机状态发生变化且其状态被复制到其余所有计算机中去。

（上示图例来自博客跨链技术践行者）

Fault-Tolerance & Paxos

这里不再赘述基本概念。现约定：分布式系统中所有节点（即所有服务器和客户端）都是诚实可靠的，服务器收到客户端的命令$m$后立刻执行。

先考虑一台服务器$S$、一个客户端$C$的应用场景。$C$发送一份消息（命令）$m$给$S$，为了解决消息污染（消息被黑客恶意篡改、因硬件等因素导致比特翻转等）和消息丢失问题，需要采用消息验证码、数字签名和消息确认（acknowledgment，即ack）等算法。

1. $C$发送$m$给$S$，并利用消息验证码或数字签名附上校验码$\tau$；
2. $S$根据$\tau$判断$m$是否安全（具体看密码学安全性定义），若安全则回复一个消息确认ack，并执行相关命令$m$（为避免重复执行同一命令，$S$可自己存储一张历史列表以进行核对检查）；
3. 若$C$在规定时间内没有收到相应的ack，重新发送$(m,\tau )$。

讨论. 在具体实现中如何建立可靠连接请参考：TCP 为什么是三次握手，而不是两次或四次？ - 山尽的回答 - 知乎。注意，是建立可靠连接而非实现共识算法，网络上很多其它解释是错误的，他们所举例子与共识算法例子混淆了，《The Science of the Blockchain》学到下一章节便会证明：三次沟通依旧无法达成共识。

再考虑多台服务器、一个客户端的应用场景。易知，客户端仅需要群发$(m,\tau )$即可实现分布式系统。

接着考虑一台服务器、多个客户端的应用场景。多个客户端可能同时发送不同命令，这多条命令之间存在冲突（服务器一次仅能处理一条命令），所幸仅有一台服务器，它可以自由决定多条命令的执行序列。

最后考虑多台服务器、多个客户端的应用场景。该场景十分复杂，例如，$C_1$发送$m_1$给$S_a$和$S_b$，同时间，$C_2$发送$m_2$给$S_a$和$S_b$，由于网络延迟（具体参考计算机网络知识），$S_a$可能先收到$m_1$再收到$m_2$，而$S_b$可能先收到$m_2$再收到$m_1$，这就导致两台服务器执行命令后的状态不一致，失去了分布式系统的最初功能。

为保证所有服务器的状态一致，我们要确保它们的命令执行序列相同，即所有服务器第$i$次命令操作都一样。先简化模型，仅考虑序列中的索引$i$，问题演化成：在一次选举中，多个客户端分别提出各自的议案$m_1$， $m_2$， $\dots$，众多服务器需要从中协调选取出一个大家都认可的议案。

最简单的方法便是指定一台串行器（serializer），所有客户端将各自的议案发送给串行器，由串行器决定第$i$次命令为哪一个，然后群发给所有服务器（即先一台服务器多个客户端，再多台服务器一个“客户端”）。但该主从（master-slave）方法弊端较为明显，即当串行器死机时整个分布式系统便会彻底崩溃。

另一种可尝试的方法便是两段互斥锁协议（借用计算机操作系统的相关思想），设计如下简单协议：

1. 阶段A，客户端向所有服务器申请锁。
2. 阶段B，若规定时间内所有服务器都将锁给了客户端，则客户端将消息$m$发送给所有服务器；否则，客户端将当前占有的锁还给服务器，等待一段时间并返回阶段A。

上述协议耗时较长，且不具备容错能力（万一1台服务器宕机了，那么整个系统崩溃），可以进行改进，即将申请所有的锁改成申请半数以上的锁。

但两段上锁协议存在死锁问题，假想有4台服务器，客户端$C_1$和$C_2$分别占有了半数的锁，在阶段B时，$C_1$本来想释放它占有的锁，但突然$C_1$宕机了，那整个系统就彻底陷入僵死状态。一个看似可解的方法就是让服务器为锁设置占有时长（开始有Paxos的影子）。思考如下案例：

$C_1$占有了锁$L_1$和$L_2$，$C_2$占有了锁$L_3$和$L_4$，$C_1$宕机而$C_2$正常运作，超过一定时长，服务器自认为收回了$C_1$和$C_2$的锁并其锁$(L_1,L_2,L_3)$给了$C_2$，$C_2$提交命令$m_2$，碰巧的是同时间，$C_1$恢复工作并占有了锁$L_4$且由于操作系统错误$C_1$仍认为它持有锁$L_1$和$L_2$，$C_1$也提交命令$m_1$，这就产生了命令冲突。

由上述例子可知，不宜仅让服务器来维护锁的状态（是否归还），而应该由客户端和服务器$S_i$二者共同记录锁$L_i$的状态。并且，二者还应该为锁加上一个编号，当服务器看到两者持有的锁编号不一致时可判断出这把锁是无效的（服务器已收回该锁但客户端误认为自己还持有该锁）。

如何制定锁的编号？需要遵循一条原则：先发的锁无法覆盖后发的锁（因为当服务器产生后发的锁时它已认为新发的锁被“收回”了）。既然这里有个优先级且随时间增长优先级变大，那么就可以拿这个优先级来做锁的编号。

由谁来决定锁的编号？如果让服务器来决定锁的编号，那么有如下问题：有4台服务器，一个客户端向整个网络系统申请4把锁，需要维护一个数值列表$(L_1,L_2,L_3,L_4)$，存储开销较大（注意：4台服务器的时钟步长不一定一样，这会导致该办法中的$L_i$是不同步的）。相反，如果由客户端来决定锁的编号，那么就没有该问题。

如何制定锁的占有时长？时长数值设置太大容易导致系统响应时间较长，时长数值设置太小有可能导致命令还没来得及发送锁就被“收回”。Paxos协议利用客户端的通信速度来自适应决定锁的占有时长。

一个不完善的粗糙协议被制定如下（上述符号$m$接下来用$c$代替）：

注意，上述协议无法被严格证明是安全的（安全指不存在状态不一致问题）。假想，$C_1$在阶段3发送了execute(c)，但不幸由网络延迟导致发送过程较慢，碰巧更不幸的是$C_2$快速完成了半数以上锁的申请并发送了另外一条execute(c’)，这时整个系统就炸了。

为解决上述问题，我们可以想办法通知$C_2$让它主动把c’ 变成$c$，于是就有了Paxos协议。

好了，现在所有服务器执行的便都是命令$c$。为防止重复执行（先收到$C_1$发送的execute(c)，又收到$C_2$发送的execute(c)），服务器可以维护一张命令执行记录。

本文详细地介绍了Paxos协议的设计思路，我们研究人员在设计一份可靠协议时需要有一个完整清晰的思路。这里不再赘述安全性证明，若想深入研究Paxos的理论证明，请购买《The Science of the Blockchain》正版书籍进行研读。这里仅介绍如何在第$i$次协商中挑选出唯一的命令$c$，对执行多个命令，读者可进行自己思考（Tips. 为选举也打上一个编号标签）。

Reference

The Science of the Blockchain笔记（一）
区块链Paxos算法
分布式共识的工作原理，Part-2：共识问题与 FLP 不可能定理