区块链系统，首先是一个分布式系统。首要面临的问题就是一致性的保障。
一致性问题
定义
一致性(consistency)是指对于分布式系统中的多个节点，给定一系列操作，在约定协议的保障下,试图是的它们对结果处理达成"某种程度"的认同。
理想情况下，各个服务节点严格遵循相同的处理协议，构成相同的处理状态机制，给定相同的初始状态和输入序列，则可以保障在处理过程中每个环节的结果都是相同的(无论是对错)。
一致性并不代表结果正确与否，而是系统对外呈现一致的状态。
挑战
节点间的通信网络是不可靠的，包括消息延迟、乱序、内容错误等
节点处理时间无法保障，结果会出现错误甚至自身宕机
采用同步可以简化这一序列，但会严重降低分布式系统的可扩展性，甚至退化为单点系统。
将可能引发不一致的并行操作进行串行化也成为解决一致性问题的基础思路
一致性要求
分布式系统达成一致需要满足：
可终止性(termination)： 一致结果需在有限时间内完成；
约同性(agreement)：不同节点最终完成决策的结果是相同的
合法性(validity)：决策的结果必须是某个节点提出的提案。
可终止性：有限时间内保障服务可用，完成决策。
约同性：要么不给出结果，要么给出的结果必定是达成了共识的，保障安全性(safety)
合法性：达成的结果必须是节点执行操作的结果。
一般来说一致性包括：强一致性和最终一致性，对一致性要求越强往往会造成越弱的处理性能，以及越差的可扩展性。
带约束的一致性
顺序一致性： 一种比较强的约束，保证所有进程看到的全局执行顺序的一致，并且每个进程看到自身的执行顺序跟实际发生顺序一致。比如 A->B->C 不能出现 A->C->B.
顺序一致性限制了各个进程内指令的偏序关系，不同的进程间按照物理时间进行全局排序。
线性一致性：在顺序一致性前提下加强了进程间的操作排序，形成全局唯一顺序，通常依赖于全局的时钟或锁，具有很强的原子性保证。
最终一致性(弱一致性)
由于强一致性比较难实现，实际中会适当放宽对一致性的要求，进而降低系统实现的难度。保证系统总会某一个时刻,达到一致的状态。
共识算法
共识(consensus)经常会和一致性(consistency)放在一起讨论，但两者含义严谨地讲并不相同。
一致性：分布式系统中多个副本对外呈现数据的状态。
共识：分布式系统中多个节点之间，彼此对某个状态达成一致结果的过程。
一致性描述的是结果状态，共识则是达成结果的一种手段；达成共识并不意味着保障了一致性。
含义
共识算法是对某个提案大家达成一致意见过程的解决方案。对分布式系统来说，各个节点通常是相同的确定性状态机模型(又称状态机复制问题state-machine replication)，从相同初始状态开始接收相同顺序的指令，则可以保证相同的结果状态。
挑战
不同节点之间通信存在延迟(光速物理限制，通信处理延迟)，并且任意环节都可能存在故障，比如网络中断、节点发生故障、甚至恶意节点伪造信息等
常见算法
解决两种类型问题：
1、非拜占庭错误(non-byzantine fault)或故障错误(crash fault): 出现故障(crash)/不响应(fail-stop),但不会伪造信息的情况
2、拜占庭问题(Byzantine Fault): 伪造信息恶意响应的情况，对应节点称为拜占庭节点。
根据上面解决错误情况(是否为拜占庭问题)，共识算法分为:Crash Fault Tolerance(CFT)类算法和Byzantine Fault Tolerance(BFT)类算法。
非拜占庭错误： Paxos、Raft及其变种，此类算法容错往往比较好、处理较快，容忍不超过一半的故障节点。
容忍拜占庭错误： PBFT (Practical Byzantine Fault Tolerance ) 为代表的确定性系列算法、 PoW 为代表的概率算法等。确定性算法，一旦达成对某个结果的共识就不可逆转，共识即是最终结果；概率类算法，共识结果是临时的，随时间推移或某种强化，共识结果被推翻概率越来越小，成为事实上的最终结果。容错性能比较差，容忍不超过1/3的故障节点。
实践中，一致性的结果往往还需要客户端的额外支持，典型情况如通过访 问 足够多个服务节点来比对验证，确保获取共识后的正确结果 。
