更去中心化，还是更快，这是一个问题

其中一个难题，是去中心化应用所依赖的账本的性能问题 - 它每一秒能处理的交易数量很小。比特币网络每秒处理不到十笔交易，而 VISA 可以最多处理两万多笔。

过去几年里，这是一个“令无数英雄竞折腰”的难题。

它可能是无解的：只要仍然保持去中心化，那么账本的性能提升的程度有限。

什么是去中心化账本

在这个语境中，账本是按顺序组织起来的很多笔交易的集合。

账本有它自己的状态。一个账本的状态，包含了诸如某个账号有多少余额这类事实。

账本的状态，是由它记录的所有交易 - 也就是之前发生的所有事件，共同决定的。

一笔交易，就是一条对账本状态进行更改的命令。

在以太坊账本中，命令可能是简单直接的，把特定数量的代币从某个账号转到另一账号；也可能是复杂的，如计算某账号剩下多少余额，把其中一半转到另一账号。

假设某账号有 100 余额的代币，现有两笔交易，其中一笔把 10 代币转到另一账号；另一笔是把该账号余额中的一半转到另一账号。这两笔交易发生顺序的不同，会导致账本的不同状态。在一种顺序下，账号最后的余额是 45；而另一种顺序下，余额则是 40。

因此，账本的当前状态，由它所记录的所有交易、以及这些交易的先后顺序决定。

任何一个记账者，在登记一笔交易进账本之前，先要知道账本的当前状态。如果某账号余额为 30，且规则不允许余额为负值，那么这个记账者是不能接受一笔从该账号转出 60 代币的交易的。

而从根本上来说，要得到账本的当前状态，记账者需要把账本记录的所有交易按顺序处理和计算一遍。

对于账本的任何一个审计者（验证者）来说也是一样。

细心的读者应该注意到，账本状态通常并不严格依赖于所有交易之间的相互顺序。如果在一段时间内，两个账号没有任何直接或者间接的联系，那么涉及其中之一的交易集与涉及另外一个的交易集之间的顺序是无关紧要的。

但是，这带来了一个新问题：记账者要判断这两批交易是否确实毫无关联。这并不是一个简单的任务。

因此，从一般的意义上来讨论，我们权且认为账本的状态依赖于登记的所有交易以及它们的顺序。

去中心化的账本，指的是由去中心化网络来共同维护的账本。

在实践中，这个去中心化网络可能包含各种节点，有些参与记账，有些不参与。本文讨论的，主要是记账节点。

共同记账的目标

当我们从这些节点处查询账本时，对于某笔交易被登记在账本中哪个位置，我们希望所有节点的答案是一样的。

否则，共同记账就没有意义了。

但是，在去中心化网络中，可能有些节点是不诚实的。出于私利或者其他非经济偏好，它可能特意给出不同的答案。这种恶意节点，在分布式计算理论中，被称为“拜占庭节点（Byzantine Node）”。

这样的话，我们的期望要稍作更改：当我们从诚实节点处查询账本时，我们希望得到的答案是一致的。

因此，共同记账的目标是，**对于账本中登记的交易以及它们之间的顺序，所有的诚实节点都有一致的认识，能够给出同样的回答**。

我们要求网络的共同记账满足两个特性：

当新交易被登记到账本后，它不能再被删除或者修改，它在账本中的位置也不能发生变化；

当一笔交易被合理地提交给网络后，它就应该被登记在账本中，或迟或早。

它们分别被称为持久性（Persistence）和活跃性（Liveness）。

为什么要同时有这两个特性，也很好理解。

如果不要求活跃性，那么网络直接拒绝所有记账请求，便满足持久性了，但这没有任何意义；

如果不要求持久性，那么网络可以记一个扔一个，也满足活跃性，但这显然不符合我们对账本的期望。

所以，网络进行共同记账时，要同时满足这两个特性。

对共同记账的网络来说，一笔交易被登记到账本中，意味所有诚实节点对这笔交易的存在以及交易在账本中的位置达成了一致认识。

达成一致认识的过程被称为共识过程。

由于去中心化节点都是独立决策的，要完成这个过程，需要借助一个设定好的协议。我们把这种协议叫共识协议（Consensus Protocol）。也有人把它叫做共识算法。

传统的分布式计算理论把允许拜占庭节点（恶意节点）存在的共识协议称为 BFT（Byzantine Fault Tolerance）协议。BFT 协议在学界已被研究多年。

中本聪在比特币的设计中，提出了一个与传统 BFT 不同的、基于区块链的方案。

随后发明的许多共识协议，都可以用这两种不同思路来划分，分别叫做“链式共识”（Chain-based Consensus ）和 BFT 共识。

这些共识都假定，只要拜占庭节点在记账权力分配上少于某个特定的比例，账本就是安全的，它的持久性和活跃性不会受到影响。

这些共识协议都有同样的基本框架：

记账在逻辑上可分成不同的轮次；

每一轮，账本的新增部分由专门的提议者（Proposer / Leader / Block Producer）提出；

参与共识的节点根据协议所定的规则来确认新增部分；

一轮完成后，下一轮的记账必须在这一轮结果的基础上进行。

区别在于第 3 步，链式共识的节点通过选择当前最长链来进行确认；而 BFT 共识的节点则是通过投票来确认。

但不管哪种方式，账本的新增部分都需要从提议者那里扩散到所有共识节点。

链式共识中，新增部分（新区块）扩散的速度必须远远大于区块产生的速度，否则，新增部分的留在账本上的可能性就会很低。用区块链的术语来说，分叉的概率很大。

在 BFT 共识中，新增部分要在共识节点中经过至少两轮的投票确认。这样的话，如果有 n 个节点参与共识，那么就需要大概 n2次的信息传输。

数据显示，跨地区互联网的单次数据来回，耗时可能是在同一数据中心内来回的几百上千倍。在互联网的环境下，网络延迟始终都是显著的。

由于物理带宽的限制，我们也不能将单次传输的数据量增大而不影响延迟。

因此，去中心化账本单位时间内能处理的交易数，受限于网络延迟和网络带宽。

另外，由于每个记账节点都需要根据账本的当前的状态来验证新增事件，账本中能够登记的交易总量，受限于记账节点的计算能力和存储空间。

因此，在追求更快的去中心化账本时，我们需要面对计算能力、存储空间、网络延迟以及带宽这些物理限制。

可扩容性的三难困境（Scalability Trilemma）

我们先定义什么是快。

在区块链世界里，人们关心的快主要包括吞吐量（Throughput）和“最终确认时间”（Time to Finality）。吞吐量是指在每个单位时间内能处理多少笔交易；而“最终确认时间”指的是当一笔交易被处理后，需要多长时间后人们才可以确信它被登记在账本中了。

其中，更被人关心的是吞吐量，因为这关系到一个分布式账本是否同时能给更多的人使用。

一个系统能不能被越来越多的人使用，这个特性我们通常用“可扩容性”（Scalability）来表示。

以太坊项目的研究者们在解决可扩容性问题时，观察到区块链系统的设计中有一个关于可扩容性的三难困境（Scalability Trilemma）。用以太坊创始人 Vitalik Buterin 的话来说，“一个区块链系统最多只能拥有以下三种特性之中的两个：去中心化，可扩容性，安全”。

当你要追求其中之一时，就要在另外两者之间进行取舍：如果要追求安全性，那么就要在去中心化和可扩容性之间取舍。

安全性 + 去中心化

这是目前的公链的现状。

虽然在实际的运行中，比特币、以太坊的激励机制促使矿工们（记账节点）组成矿池，导致事实上的（弱）中心化：记账权力被集中在少数几个矿池手中。

但是在系统的设计上，我们仍然可以认为它们是去中心化的。

因为，任何普通的人都可以对比特币和以太坊的账本进行验证，也可以参与记账，没有门槛。

安全性 + 可扩容性

对一个共享账本、一套共识协议扩容，最简单的办法就是直接提升其速度参数： 在链式协议中，增大区块、缩短区块产生时间；BFT 协议中，把投票确认的时限缩短。

但是，正如我们之前讨论过的，去中心化共识的实际速度受限于节点的计算资源和节点间通信的网络延迟及带宽。

为了保证共识协议能够正常工作，保证安全性，节点间通信的网络带宽就需要随之增大，网络延迟也要缩小；其次，由于交易量的增加，对节点的计算能力和存储空间的要求也会随之增加。

如果我们想要比特币在不改变共识协议的情况下，把记账速度提升 1000 倍，那么恐怕所有共识节点都要被部署在同一个高速网络环境中，而且每个节点都需要计算机集群来处理账本了。

区块链系统在保证安全性的前提下进行扩容，要求每个节点进行自身的扩容，也要求节点之间的通信扩容。

如果普通节点不能参与，也就失去了去中心化。但只要满足应用场景的需求，这未必不是一个选项。

毕竟，虽然去中心化很有意义，但它本身不是目的。

去中心化 + 可扩容性

如果一个区块链系统想要拥有去中心化和可扩容性，那么它就会损失安全性。

这种系统的原始形态，就是同时使用多个账本、多条区块链。正如比特币和各种山寨币的共存。

如果把这些账本看成是同一个系统的组成部分，只要账本的数量不限，它能处理的交易确实无限多，而且任何账本都不要求超级节点，系统同时拥有去中心化和可扩容性。

但在这种情况下，由于在同一时间里每个账本的记账节点都减少了，那么每个账本的安全性 - 抵御恶意攻击的能力 - 也就降低了。

分片和多链体系本质上是这类解决方案的升级版。如何提升每一个账本的安全性，是它们的主题。

可扩容性的三难困境并非铁律，很多技术创新和应用，都在尝试克服这个困境。

但目前来说，大部分区块链系统的设计方案，都仍然限于这个困境。

它可以作为我们考察去中心化账本、区块链系统设计的一个视角。在不同应用场景下对共享账本技术方案的选择，也可以通过这三个特性进行指导。

接下来的文章里，我们会介绍不同的共识协议、不同的区块链系统设计，并用可扩容性的三难困境来考察和分析它们，理解它们的适用范围。

END