号称「公链分片」技术的五大谎言 - 区块链公链如何才能快起来 (系列之二)

我的上一篇文章探究了单链公链系统在性能和容量上受限的本质原因。本来我以为文章过于「技术」，会遭到普通读者的嫌弃。完全出乎我意料的是，竟然有上万的读者通过各种渠道阅读了这篇文章，并且，我收到了不少朋友和读者的反馈。他们鼓励我继续写下去，把我自己在分布式系统研究和区块链投资领域的经验和心得分享出来。

我非常感谢这些朋友，还有每一位读者。但是我还是非常担心，我的文章有太多技术性语言和技术上的分析——比如今天这一篇。不过，我会努力用最简单的词句、最直白的语言，把区块链领域看似很深奥的理论和方案，用浅显易懂的方式介绍给大家。

通过上一篇文章「区块链公链如何才能快起来 」，希望读者可以从文中解释的那些原因出发，明白这样一个结论：安全的共识机制本质上并不跟系统的吞吐性能以及容量相矛盾 。在区块链的系统里面，所谓的「不可能三角」——安全、去中心化、性能，这三者只能取其二的说法，并没有技术逻辑的论证，而只是对现有解决方案的观察。

不过，对于现有的单链系统，确实有一个不可逾越的物理限制，那就是全节点平均带宽。以13Mbps的带宽为例(这是互联网带宽中位数, 4K电影在线播放带宽下限要求为15Mbps)，无论基于什么共识技术，即使完全丧失去中心化，并忽略传送协议，以及层层封包等额外引入的代价，以比特币网络现在的每秒处理 7 笔交易的吞吐量来算，其吞吐量理论上限为6825TPS（7TPS × 13Mbps / 8Mb × 600s）。否则就会出现部分全节点脱网，即长时间无法赶上全网的区块增长，而离最新头部块越来越远。

我的上一篇已经提到，性能瓶颈和容量瓶颈在现在的结构下无法突破，因为单个全节点的带宽和存储资源总是有限的，并且我们还不能要求部署全节点的机器都具备顶级的配置，因为只有保证了参与全网的壁垒较低，才能真正具备有良好的去中心化特性。从这个意义上来说，要获得大幅度的伸缩性，我们必须要能够有一个合理的设计，使的单个全节点仅仅负责整个网络吞吐量和容量的一部分，这样，才有可能在维持全节点的负荷比较小的前提下，使得全网的性能和容量有大幅提升。

分片(Sharding)技术就是针对这一思路提出的。分片最初是基于数据库系统提出的，泛指横向切分数据库服务器的负荷，用多个数据库服务器平行服务的方式，以提升整体的服务吞吐量和数据容量。实际上，分片并不单指一种特定的技术，而是一大类横向切分系统负荷，多实例并行，以提高整体性能和容量的技术。

不过，分片这个提法在区块链技术中过于宽泛。在这篇文章的最后部分，我会通过引入「异步共识组」这个概念，谈谈我认为什么会是区块链中理想的分片方案。

在讨论我认为的理想方案之前，我还是用我习惯的逻辑，先向读者解释为什么我们需要分片技术、理想的分片技术究竟应该解决什么问题这些最基本的知识；然后，我会根据自己看过的大量的分片方案，谈谈目前市面上已有的分片方案存在的五个误区或谎言。

为什么需要分片：从全节点的负担谈起

在分析具体技术方案之前，先来看看一个全节点都有哪些负荷:

网络带宽，这个部分同吞吐量(TPS)线性相关

1. 新区块的广播

全节点需要下载周期性出现的新区块，并进一步上载给其他需要的节点。对于现在7TPS的比特币区块链来说，平均下载带宽消耗是13.6Kbps，完全不是负担。但是如果TPS提高到7000TPS，则至少需要13.6Mbps的下载带宽才能承受——请注意，这个是关键数据，并且有序，如果区块数据得不到及时传输，区块链将无法持续构造，并且无法重建全网的账簿状态。

2. 未确认新交易的广播

全节点需要持续发现&#x