《拜占庭系统技术研究综述_范捷》笔记

Abstract

成果涌现，但性能上仍然与已经使用的非拜占庭系统相距较大，占用资源数量仍然较多
拜占庭系统本身在长时间应用后可能会由于错误的鸡肋导致系统崩溃，仍需要新的思路与方法来有效延长系统的可持续运行时间
BFT至少需要3f+1台服务器才能容忍f个错误，如果使用一些可信计算部件，在小的范围内人为保证不出错，那么就有可能将服务器数量减少至2f+1或者系统长时间可靠运行

整个系统对于每个请求需要满足以下条件
1. 一致性：所有忠诚节点必须使用相同的输入信息，产生一致的结果
2. 正确性：若i将军是总成的，那么其他忠诚节点都必须接受这个信息，并计算相应的结果
满足一下指标：
1. 安全性：任何已经完成的请求都不会被更改，它可以被之后请求看到
2. 活性：可以接受并且执行忠诚节点的请求，不会被任何因素影响而导致忠诚节点的请求不能执行
普遍假设条件：
1. 坏节点行为可以是任意的，坏节点之间可以共谋
2. 节点之间的错误是不相关的
3. 节点之间通过异步网络通信
4. 节点间晋西可以被第三方知晓，但是不能篡改、伪造信息的内容和验证信息的完整性，由数字签名来保证

整个系统共同维护一个状态，一般包括三个协议：
- 一致性协议：一主多从，至少包括request、序号分配、reply三个阶段(这个在区块链里可退化成两阶段)。客户端收集到2f+1个不同节点的一致信息后才能保证达成一致的忠诚节点比坏节点多
- 检查点协议：在某一snapshot，不同服务器的状态可能不一致，BFT系统设置周期性的检查点协议，将系统中的节点同步到某一个相同的状态（这里可以参照PBFT的高低water mark），在checkpoint之前的记录日志可以删除（因为已经达成一致的消息是安全的）。个人理解就跟TCP中的滑动窗口达到的效果相同，不过改窗口由所有节点共同维护。
- 视图更换协议：拿来堤防主节点作恶的措施，出发方式分为服务器触发(自己定规则，比如说主节点超时)和客户端出发(这个要求客户端一致监视服务器)

PBFT：把所有问题都放在服务器端进行，因此一致性协议较复杂，其中有两个阶段需要服务器之间的两两交互，数据处理量大，计算复杂。实际上节点增加到一定程度，整个系统效率会变低。
HQ：面向单一请求的共识协议，单一请求下不需要考虑排序的问题，此时Client就可以是主节点，先收集节点的状态信息(write1和writeOK阶段)，再发送请求并执行(write2和write2)。但是当有多个请求竞争时，则退化为PBFT。

其思想是，节点绝大部分时间处于正常的状态，因此不用每一个请求都在达成一一直之后再执行，只需要在错误发生之后再达成一致即可。
在此类协议中，节点不需要通过三阶段提交过程即可响应客户端的请求。而是更加乐观，节点同意由主节点发出的排序请求并给客户端返回结果，由客户端而不是节点来考虑一致性问题，如果发现不一致问题，由客户端负责通知节点回滚至一致状态。这里和区块链矛盾的是，我们并不能确定Client一定是忠诚的。
在大部分时间没有坏节点的情况下，基于speculation的BFT系统表现出色，但是当有错误时，因为要涉及到和PBFT类似的view change过程，其性能也会急剧下降。

一部分节点责一致性协议，一部分节点执行请求
ZZ协议：通过虚拟化技术把节点均正常场景下的执行所需节点数量从2f+1降为f+1个。在没有错误场景时，只通过f+1个节点来执行请求，其余服务器在休息状态；而当执行请求的节点发生错误时，客户端通过虚拟化技术快速启动更多的节点来执行。
ODRC协议也是将执行节点数量将为了f+1，但与ZZ协议不同，它并没有采用额外的虚拟化等技术，而是在BFT协议过程中的节点达成一致后、执行请求前增加了一个选择执行节点的阶段。该阶段根据当前系统状态，选择指定数量的节点执行请求。

Quorum机制：
- 参考https://www.cnblogs.com/hapjin/p/5626889.html
- 基于“抽屉原理”，假设有N个副本，更新操作wi在W个副本中更新成功之后才认为这次wi成功，对于读，至少需要读R个副本才能读到这次更新的数据，其中W+R>N。
- e.g.：假设系统中有5个副本，W=3，R=3，初始时数据为(V1，V1，V1，V1，V1），成功提交的版本号为1当某次更新操作在3个副本上成功后，就认为此次更新操作成功。数据变成：(V2，V2，V2，V1，V1）–成功提交后，版本号变成2，因此，最多只需要读3个副本，一定能够读到V2(此次更新成功的数据)。而在后台，可对剩余的V1 同步到V2，而不需要让Client知道，取最高版本为这次读出的数据。
Quorum-BFT
- 读操作：规定R(读子集)的大小后，任何一个自己都包含最新的数据，并且一定可以读出来。
- 写操作：规定W(写子集)的大小后，从可用时间戳中找到大于子集的副本最大时间戳的时间戳t，并发送(v,t)给所有节点(v为需更新数据，t为选中的时间戳)，直到收到某一个大小恒定的节点子集的反馈信息。
小结
1. QuorumBFT不需要维护状态，因此允许多个够客户端进行读写，更适合分布式存储领域
2. 状态机BFT需要维护状态，需要对请求排序，同一时刻只能有一个客户端更新文件，适合分布式计算等更广阔的领域