区块链首先是一个分布式系统，中央式结构改成分布式系统，碰到的第一个问题就是一致性的保障。很显然，如果一个分布式集群无法保证处理结果一致的话，那任何建立于其上的业务系统都无法正常工作。
在分布式系统中，一致性是指：对于系统中的多个服务节点，给定一系列操作，在协议（往往通过某种共识算法）保障下，试图使得他们对处理结果达成某种程度的一致。
注意：一致性并不代表结果正确与否，而是系统对外呈现的状态一致与否，例如，所有节点都达成失败状态也是一种一致
挑战:
- 节点之间的网络通讯是不可靠的，包括任意延迟和内容故障
- 节点的处理可能是错误的，甚至节点自身随时可能宕机
- 同步调用会让系统变得不具备可扩展性
要求
理想的分布式系统一致性应该满足：
- 可终止性（Termination）:一致的结果在有限时间内能完成
- 共识性（Consensus）:不同节点最终完成决策的结果应该相同
- 合法性（Validity）:决策的结果必然是其它进程提出的提案
带约束的一致性
做过分布式系统的应该能意识到，绝对理想的一致性很难达成，越强的一致性要求往往意味着越弱的性能，很多时候，人们发现对一致性可以适当放宽一些要求，在一定约束下实现一致性，从弱到强有一下几种：
- 顺序一致性
- 线性一致性
实际上，要保障系统满足不同程度的一致性，往往需要通过共识算法来达成。共识算法解决的是对某个提案，大家达成一致意见的过程。
问题挑战
实际上，如果分布式系统中各个节点都能保证以十分强大的性能（瞬间响应，高吞吐）无故障的运行，则实现共识过程并不复杂，简单通过多播过程投票即可。
但是，现实中完美的系统不存在，如响应请求往往存在延时，网络会发生中断，节点发生故障，甚至存在恶意节点故意要破坏系统。
一般把故障（不响应）的情况称为“非拜占庭错误”，恶意响应的情况称为拜占庭错误
常见算法
针对非拜占庭错误的情况，一般包括Paxos,Raft及其变种，对于要能容忍拜占庭错误的情况，一般包括PBFT系列，POW系列等等。
不可能性原理：在网络可靠，存在节点失效（即便只有一个）的最小化异步模型系统 中，不存在一个可以解决一致性问题的确定性算法。
FLP不可能原理告诉人们，不要浪费时间去为异步分布式系统设计在任意场景下都能实现共识的算法。
分布式系统不可能同时确保一致性(Consistency)，可用性(Availablity)，和分区容忍性(Partition)
- 一致性:任何操作应该都是原子的，发生在后面的事件能看到前面事件发生导致的结果
- 可用性：在有限时间内，任何非失败节点都能应答请求
- 分区容忍性：网络可能发生分区，即节点之间的通信不可保障
比较直观的理解，当网络可能出现分区时候，系统是无法同时保证一致性和可用性的。要 么，节点收到请求后因为没有得到其他人的确认就不应答，要么节点只能应答非一致的结 果。好在大部分时候网络被认为是可靠的，因此系统可以提供一致可靠的服务；当网络不可靠 时，系统要么牺牲掉一致性（大部分时候都是如此），要么牺牲掉可用性。
应用场景
既然CAP不可能同时满足，则设计系统的时候必然要弱化对某个特性的支持。
- 不保证一致性：对结果一致性不敏感的应用，可以允许在新版本上线后过一段时间才更新成功，期间不保证 一致性。例如网站静态页面内容、实时性较弱的查询类数据库等
- 不保证可用性：对结果一致性很敏感的应用，例如银行取款机，当系统故障时候会拒绝服务。Paxos、Raft 等 算法，主要处理这种情况
- 不保证分区容忍性：现实中，网络分区出现概率减小，但较难避免。网络通过双通道等机制增强可靠性，达到高 稳定的网络通信
即原子性(Atomicity)，一致性(Consistency)，隔离性(Isolation)，持久性(Durability).
ACID原则描述了对分布式数据的一致性需求，同时付出了可用性代价。
- Atomicity：每次操作是原子的，要么成功，要么不执行
- Consistency：数据库的状态是一致的，无中间状态
- Isolation：各种操作彼此互相不影响
- Durability：状态的改变是持久的，不会失效
一个与之相对的原则是 BASE（Basic Availiability，Soft state，Eventually Consistency）， 牺牲掉对一致性的约束（最终一致性），来换取一定的可用性。
Paxos 问题是指分布式的系统中存在故障（fault），但不存在恶意（corrupt）节点场景（即 可能消息丢失或重复，但无错误消息）下的共识达成（Consensus）问题。
是对Paxos的重新设计和实现，包括三种角色：leader、candiate 和 follower，其基本过程为：
- Leader 选举：每个 candidate 随机经过一定时间都会提出选举方案，最近阶段中得票最 多者被选为 leader；
- 同步 log：leader 会找到系统中 log 最新的记录，并强制所有的 follower 来刷新到这个记 录；注：此处 log 并非是指日志消息，而是各种事件的发生记录。
拜占庭问题更为广泛，讨论的是允许存在少数节点作恶（消息可能被伪造）场景下的一致性 达成问题。拜占庭算法讨论的是最坏情况下的保障。
又叫拜占庭将军（Byzantine Generals Problem）问题，是 Leslie Lamport 1982 年提出用来 解释一致性问题的一个虚构模型。拜占庭是古代东罗马帝国的首都，由于地域宽广，守卫边 境的多个将军（系统中的多个节点）需要通过信使来传递消息，达成某些一致的决定。但由 于将军中可能存在叛徒（系统中节点出错），这些叛徒将努力向不同的将军发送不同的消 息，试图会干扰一致性的达成。
拜占庭问题即为在此情况下，如何让忠诚的将军们能达成行动的一致。
Byzantine Fault Tolerant 算法
面向拜占庭问题的容错算法，解决的是网络通信可靠，但节点可能故障情况下的一致性达成。
新的解决思路：拜占庭问题之所以难解，在于任何时候系统中都可能存在多个提案（因为提案成本很低）， 并且要完成最终的一致性确认过程十分困难，容易受干扰。但是一旦确认，即为最终确认。
比特币的区块链网络在设计时提出了创新的 PoW（Proof of Work） 算法思路。一个是限制一 段时间内整个网络中出现提案的个数（增加提案成本），另外一个是放宽对最终一致性确认 的需求，约定好大家都确认并沿着已知最长的链进行拓宽。系统的最终确认是概率意义上的 存在。这样，即便有人试图恶意破坏，也会付出很大的经济代价（付出超过系统一半的算 力）。
后来的各种 PoX 系列算法，也都是沿着这个思路进行改进，采用经济上的惩罚来制约破坏 者。
OK，以上就是一些纯理论性的概念，这些也帮助我们理解区块链技术