前言
因为最近 web3.0 的概念很火，web2.0 是中心化系统，web3.0 是去中心化系统。作为一名 web2.0 的服务端开发，在学习 web3.0 相关技术的时候，不由自主地会对比 web2.0 和 web3.0 在技术实现上的区别。
在 web2.0，我们用 Mysql、Redis、MongoDB、HBase、Elasticsearch 甚至 ZooKeeper，这些数据库无论在系统中的职责是什么，我都把它们归为中心化数据库（默认集群版本，单机版不在此次讨论范围之内）。
在中心化数据库的架构下，通常有多个数据库节点，都属于同一个管理者；多个数据库之间需要达成数据一致。
而在 web3.0，存储的前提就是区块链，每一个区块链的用户都是独立的个体，都保留了一份完整的数据。所以，web3.0 也有多个数据库节点，但是每个数据库节点的管理者都不相同，可以理解为用户就是管理者；多个数据库之间也需要数据一致性；这就是去中心化的数据库。
| 数据库类型 / 特征 | 节点个数 | 管理员 | 数据一致性（共识） |
|---|---|---|---|
| 中心化数据库 | 多个 | 一个 | 需要 |
| 去中心化数据库（区块链） | 多个 | 每个用户各管理一份完整数据 | 需要 |
私以为，中心化系统和去中心化系统最大的区别就在于数据库节点之前确立数据共识的过程。 在讲确立数据共识之前，我们先来看一个网络通信里的经典问题：拜占庭将军问题。
拜占庭将军问题
9 位拜占庭将军分别率领一支军队要共同围困一座城市，因为这座城市很强大，如果不协调统一将军们的行动策略，部分军队进攻、部分军队撤退会造成围困失败，因此各位将军必须通过投票来达成一致策略，要么一起进攻，要么一起撤退。
因为各位将军分别占据城市的一角，他们只能通过信使互相联系。在协调过程中每位将军都将自己投票“进攻”还是“撤退”的消息通过信使分别通知其他所有将军，这样一来每位将军根据自己的投票和其他将军送过来的投票，就可以知道投票结果，从而决定是进攻还是撤退。
而问题的复杂性就在于：
-
因为将军之间需要通过信使交流，即便所有的将军都是忠诚的，派出去的信使也可能被敌军截杀，甚至被间谍替换，也就是说将军之间进行交流的信息通道是不能保证可靠性的。
-
将军中可能出现叛徒，他们不仅可以投票给错误的决策，还可能会选择性地发送投票。假设 9 位将军中有 1 名叛徒，8 位忠诚的将军中出现了 4 人投“进攻”，4 人投“撤退”，这时候叛徒可能故意给 4 名投“进攻”的将军投“进攻”，而给另外 4 名投“撤退”的将军投“撤退”。这样在 4 名投“进攻”的将军看来，投票是 5 人投“进攻”，从而发动进攻；而另外 4 名将军看来是 5 人投“撤退”，从而撤退。这样，一致性就遭到了破坏。
类比到数据库的话，数据节点就是将军，信使就是通信发出的网络数据包，每个数据节点都要通过通信对整个数据库的数据达成共识。
中心化系统的共识算法
中心化的系统因为从设计上就是一个 所有者/组织 管理这个系统和所有的数据库节点。所以数据库节点不会发出虚假信息——将军中不会有叛徒。
这种场景下的经典分布式共识算法有，Paxos、Raft 等。
Paxos 算法是Leslie Lamport于1990年提出的一种基于消息传递共识算法，能保证多副本数据强一致性与分区容错性；现已是当今分布式系统最重要的理论，为后续的如Raft、ZAB等算法、ZooKeeper、Etcd等分布式协调框架奠定了基础.
Raft 算法是一个管理复制式日志（replicated log）的共识算法 （consensus algorithm）。它的最终结果与 (multi-) Paxos 等价，也与 Paxos 一样高效，但结构（structure）与 Paxos 不同 —— 这使得它比 Paxos 更好理解，也更易于构建实际系统。
算法过程描述起来比较费篇幅，完整可以参考： Paxos 与 Raft 算法描述
这里只写一下大概，用比较容易理解的 Raft 算法举例。在 Raft 算法中，多个节点中只会有一个 Leader，这个 Leader 负责与客户端交互，产生的数据变动会同步给 Followers，Followers可以提供读取数据的功能。这是一个一主多从的系统架构
整个 Raft 算法分为三部分：
- Leader 选举：当前 leader 跪了或集群初始化的情况下，新 leader 被选举出来。
- 日志复制：leader 必须能够从客户端接收请求，然后将它们复制给Followers，强制它们与自己的数据一致。
- 安全性：如何保证上述选举和日志复制的安全，使系统满足最终一致性。
将 Raft 算法类比到拜占庭将军问题上，就等于，先让所有将军投票，选出一个总将军，然后总将军作出所有的决策，其他将军只是追随总将军。当然，前提是，将军中不能存在叛徒，所以经典的 Paxos 算法及其变种是没有拜占庭容错的。
区块链的共识算法
区块链的共识算法，与 Paxos 算法及其变种对比，引入了经济学的博弈算法，让攻击者的攻击成本远远大于收益。
目前比较成熟的区块链共识算法有 PoW(Proof Of Work)、PoS(Proof Of Stake)、DPoS(Delegated Proof of Stake)。
关于 PoW、PoS、DPos 的实现细节，可以参考 Proof-of-work-vs-proof-of-stake-Whats-the-difference 和 DPoS 缺失的白皮书
这里就不用太多篇幅介绍了。只说一下大致的实现方式。
首先区块链的结构是部分数据组成一个区块，运行中的区块链有多个区块且在不断生成新的区块，每一个区块都有一个地址，区块按照生成时间排序，生成时间靠后的区块会存储上一个区块的地址。
所有的区块数据加起来就是在这个系统里产生的所有数据。整个过程分为：
- 矿工出块：在区块链里，一个区块只能由一个节点掌握出块权，所有竞争出块权的节点我们称为矿工。而竞争出块权的方式不同的共识算法也不同。
- PoW：是纯算力竞争。
- PoS：PoW 会对算力有很大的浪费，所以 PoS 推出了通过 算力 + 持有币天 竞争的方式，极大地节省了计算资源。
- DPoS 是通过投票决出少数矿工之后，矿工按照顺序排队出块。
- P2P网络：当矿工获得发块权之后，会生成最新的区块，并通知全网同步最新的区块链。这个过程是由P2P网络实现的。包括用户产生的数据，也是通过P2P网络广播到全网，矿工才能把用户产生的数据打包成块。
- 密码学：密码学是所有区块链的基础，可以说如果没有密码学的支撑，区块链将会退化成普通的分布式日志系统。区块链中主要应用了两类密码学算法，第一类是哈希算法，第二类是非对称加密算法。
因为 DPoS 算法趋向于中心化系统，而Pow、Pos算法比较符合去中心化的概念。所以我们将 PoW、算法类比到拜占庭将军问题上，就等于，所有将军都要竞争通过算力竞争，获得决策权，同步给所有的将军达成一致，如果有叛徒想要破坏这个共识，那所有的将军里至少要有 50% 以上的叛徒，才能把伪造的决策作为新的共识同步给所有将军。
中心化系统和去中心化系统的共识算法对比
在对比之前，先介绍一个理论：
CAP 理论： CAP 定理是分布式系统领域最重要的定理之一。即在设计分布式系统的过程中，一致性(Consistency)、可用性(Availability)、分区容忍性(Partition tolerance) 三者中，我们只能选择两个作为主要强化的点，另外一个必然会被弱化。
- 一致性：系统的不同节点之间，数据要达成一致。
- 可用性：整个系统的功能能够正常运转。这个是每个系统必须要保证的。
- 分区容错性：系统中任意信息的丢失或失败不会影响系统的继续运作。这里主要指的是拜占庭容错。
从 CAP 的角度对比中心化系统和去中心化系统：
- 首先，两者都保证了可用性，但是明显去中心化系统（区块链）的可用性更强，甚至接近了 100%，这里主要是考虑服务瘫痪的可能性，中心化系统只要被黑客攻击，甚至服务运维出问题，都会导致不可用；而要使像比特币、以太坊这种规模的区块链不可用，至少要全球规模的网络故障。
- 对于一致性，中心化系统节点同步的速度一般都可以快到毫秒级别；而区块链取决于矿工节点的数量，PoW 算法越往后出块速度越慢，现在比特币的出块速度大概在十几分钟，往后只会越来越慢；除了矿工的出块速度之外，出块之后的 P2P 网络扩散速度也会增加全节点达成最终一致的时间。
- 分区容错性。区块链在设计上，定义了每个用户都是一个数据存储节点，所以几个数据节点信息丢失甚至恶意篡改都不会影响整体；而中心化系统几乎不支持拜占庭容错。
| 可用性 | 一致性 | 拜占庭容错 | |
|---|---|---|---|
| 中心化系统 | 较弱 | 达成一致性速度非常快 | 不支持 |
| 去中心化系统（区块链） | 较强 | 不要求速度，最终达成一致即可 | 支持 |
小结
通过对比可以发现，去中心化牺牲了达成一致的速度，从而保证高可用性和拜占庭容错。而中心化系统虽然不支持拜占庭容错，但是所有数据节点能够瞬间达成一致，实时性非常高。
去中心化是人类对未来的美好愿景，是对垄断的反抗。但是去中心化系统并不能解决所有问题。中心化系统也不会因此退出历史舞台，反而会帮助去中心化应用更好地落地。
参考：
