区块链笔记（三）分布式系统核心技术

可终止性（termination），指一致的结果在有限时间内能完成。意味着可以保障提供服务（liveness），这是计算机系统可以被正确使用的前提。
约同性（agreement），指不同的节点最终完成的决策的结果是相同的。这看似容易，实际上暗含了一些潜在信息，决策的结果相同，意味着算法要么不给出结果，要么给出的结果是已经达成共识的。真正的挑战在于算法要考虑可能出现的任意情形。其中，事件发生的先后顺序（逻辑时钟）十分重要，确定了顺序，就可以消除分歧，因此解决分布式系统领域许多问题的核心秘诀就是：把不同时空发生的多个事件进行全局唯一排序，而且这个顺序是大家认可的。然而，计算机系统的时钟误差比较大，不能够据此来进行排序，这就造成了分布式系统中达成一致顺序非常困难。
合法性（validity），指决策的结果必须是某个节点提出的提案，即达成的结果必须是节点执行操作的结果。

4、带约束的一致性

实际上，越强的一致性要求往往意味着越弱的处理性能，以及越差的可拓展性。根据实际需求的不同，可以选择不同强度的一致性，包括强一致性（strong consistency）和弱一致性（weak consistency）。

强一致性主要包括：

顺序一致性（sequential consistency），又叫因果一致性。所有的进程看到的全局执行顺序（total order）一致（否则数据副本不一致）；并且每个进程看自身操作的顺序（local order）跟实际发生顺序一致。它实际上限制了各进程内指令的偏序关系，但不在进程间按照物理时间进行全局排序，属于实践中可行的最强保证。
线性一致性（linearizability consistency），是一种更强的保证，在顺序一致性的前提下加强了进程间的操作排序，形成理想化的全局顺序，性能差。

强一致性往往比较难实现，且很多场景对于一致性的需求没有那么强。例如在一定约束下实现所谓的最终一致性（eventual consistency），即总会存在一个时刻，让系统达到一致的状态。这种在某些方面弱化的一致性都笼统的称为弱一致性。

二、共识算法

共识算法解决的是分布式系统中大部分节点对于某个提案（proposal）达成一致的过程，而一致性在分布式系统领域中指的是多个副本对外呈现的状态。因此，达成了某种共识并不意味着就保障了一致性。实践中，要保障系统满足不同程度的一致性，往往需要通过共识算法来达成。

提案可以指多个事件发生的顺序、某个键对应的值、主节点的选取等，其含义非常宽泛。

1、问题与挑战

达成共识需要解决两个基本问题：

如何提出一个待共识的提案？
如何让多个节点对该提案达成共识？

实际情况中，不同节点之间存在通信延迟，任意环节都可能存在故障，如网络通信中断、节点故障、信息伪造等。

通常，把出现故障（crash或fail-stop，即不响应）但不会伪造信息的情况称为“非拜占庭错误（non-byzantine fault）”或“故障错误（crash fault）”；伪造信息响应的情况称为“拜占庭错误（byzantine fault）”，对应节点为拜占庭节点。

当存在一定信任的前提下（如介入节点可信、节点性能稳定等），达成共识相对容易，共识性能越高；反之，在不可信的场景下，达成共识的成本较高，性能也较差。

2、常见算法

根据解决的场景是否允许拜占庭错误情况，共识算法可以分为 Crash Fault Tolerance (CFT) 和 Byzantine Fault Tolerance（BFT）两类。

对于非拜占庭错误的情况，已经存在不少经典的算法，包括 Paxos（1990 年）、Raft（2014 年）及其变种等。这类容错算法往往性能比较好，处理较快，容忍不超过一半的故障节点。

对于要能容忍拜占庭错误的情况，包括 PBFT（Practical Byzantine Fault Tolerance，1999 年）为代表的确定性系列算法、PoW（1997 年）为代表的概率算法等。确定性算法一旦达成共识就不可逆转，即共识是最终结果；而概率类算法的共识结果则是临时的，随着时间推移或某种强化，共识结果被推翻的概率越来越小，最终成为事实上结果。拜占庭类容错算法往往性能较差，容忍不超过 1/3 的故障节点。

此外，XFT（Cross Fault Tolerance，2015 年）等最近提出的改进算法可以提供类似 CFT 的处理响应速度，并能在大多数节点正常工作时提供 BFT 保障。

Algorand 算法（2017 年）基于 PBFT 进行改进，通过引入可验证随机函数解决了提案选择的问题，理论上可以在容忍拜占庭错误的前提下实现更好的性能（1000+ TPS）。