王嘉平：号称「公链分片」技术的五大谎言

上周我们发表了创新工场负责区块链和人工智能投资方向的执行董事王嘉平的文章，他针对公链项目发展现状，提出了在 TPS 吞吐量瓶颈提高之后，公链可能出现的容量瓶颈，以及解释了为什么无论哪种算法，有可能均无法大幅提升公链性能的原因。这篇非常「硬核」的文章被众多区块链领域「大佬」转发，并且引发了不少讨论。

这是个好的迹象。在吹过牛、赚过钱，然后牛皮破了，赚到钱又赔出去之后，整个行业是时候好好探讨一些有利于技术发展的「真问题」了。

本周，链闻继续发表王嘉平先生的另一篇文章，就市场追捧和关注的「分片技术」，切开了、揉碎了进行分析，告诉大家这个话题最基本、但是也是最值得了解的知识：为什么我们需要分片技术？理想的分片技术究竟应该解决什么问题？基于此，他也提出了目前市面上已有的分片方案存在的五个误区。

同样，这是一篇「硬核」技术文章，需要时间思考和理解。最好的阅读方式是，先「收藏」，再细细阅读。并且，欢迎转发，把有价值的信息传播给更多的人。Enjoy reading！

撰文：王嘉平，创新工场执行董事
来源：链闻 ChainNews

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

我非常感谢这些朋友，还有每一位读者。但是我还是非常担心，我的文章有太多技术性语言和技术上的分析——比如今天这一篇。:(

不过，我会努力用最简单的词句、最直白的语言，把区块链领域看似很深奥的理论和方案，用浅显易懂的方式介绍给大家。

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

不过，对于现有的单链系统，确实有一个不可逾越的物理限制，那就是全节点平均带宽。

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

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

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

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

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

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

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

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

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

全节点需要持续发现，并下载尚未被确认的新交易，然后上载给其他节点。在全网不拥堵的情况下，这个数据量和新区块的数据量相当。相对的，这个数据不需要保序，即使下载不全也不会直接导致全节点本身工作异常。但是，如果这种情况大规模地发生，最终会导致部分交易始终没有被矿工看到，而长时间不被确认，最终超时。

内存容量，这个部分同用户量 address 数量以及智能合约数量线性相关

账簿的存储占据主要的内存消耗，其他部分的消耗不多，并且基本不会随着网络扩展而增加。

区块链的基本账簿 , 至少需要维护每个用户 每个 address 上的余额，每个用户至少需要 16+32 个字节。对于支持智能合约的区块链，每个用户至少需要额外 32 个字节记录每个智能合约的代币的余额。智能合约自身还可以自定义更多的字段，可以占用远超 32
字节的内容。

当然，并不是所有的用户都参与了所有的智能合约，所以我们并不以用户量和智能合约数量的乘积作为内存消耗的估量。现实的情况是，我们按照以太坊的现状来估计，约 4500 万个地址，至少占据了约 3GB 的内存。每个地址平均消耗了 68 个字节。这里并不是说以太坊有了 4500 万个用户，通常而言，一个用户会拥有好多地址。

磁盘 I/O，这个部分同吞吐量 TPS 线性相关

全节点收到区块并确认成链之后，区块会被写入磁盘归档起来。这个部分的吞吐量大体和下载新区块的带宽一致。

这里需要注意的是，按照以太坊的观点账户模型，账簿是指全网的某一时刻的全量状态，而区块 (若干交易的集合) 是对账簿的增量修改信息。在磁盘实际存储的是区块，而不是账簿。节点在启动的时候，需要重放所有已经记录的区块，以构造账簿的最新状态。

截至目前，以太坊的全部归档区块数据量已经超过 160GB。这里的一个优化是定期将账簿全量快照也记录下来 即 checkpoint，这样只需要从最近的 checkpoint 开始重放就可以了。

而 UTXO 模型是比特币的观点，这是一个非常有意思的结构，它的区块既是若干交易的集合，同时也是部分账簿的状态，即特定地址上的余额。整条链上余额不为 0 的 UTXO 都是账簿的最新状态。至今比特币区块链的全部归档区块数据量已经超过 220GB。不过从磁盘 I/O 的角度来看，重建全网账簿还是需要扫描整条链找出全部余额不为 0 的 UTXO，并没有什么优势。当然 checkpoint 技术对 UTXO 一样有效。

在这个领域，最近我看到了一些被热炒的改进，尤其是在已确认交易集合的聚合表示方面。我注意到斯坦福大学的一个团队最近提出，RSA 累加器 (RSA Accumulator) 可以代替 MerkleTree，用来表示一个已确认交易的集合。这个想法的优异之处在于，可以直接用一个交易的 Hash 值来校验一个交易是否存在于已确认交易的集合，而 Merkle Tree 不仅需要一个交易的 Hash，还需要从树根到该交易沿途路径上的所有兄弟节点上的 Hash。不过，这个做法的代价是，这个表示本身要 1.5K 字节，Merkle Tree 的根仅需要 20 或 32 个字节。同时，这并不意味着全节点可以不再保存历史交易，原因在于，首先集合的聚合表示是不具备枚举的能力的，也就是说，在交易未知的情况下，集合的聚合表示无法告诉你里面具体的交易是什么，所以你也无法判读这个集合本身是不是正确的，所以全节点也无法仅凭这个信息确认链头的正确性。全节点在自举的时候还是需要从创始区块 (genesis block) 开始下载，逐块验证全链的完整性和正确性。但是，当这个验证过程完成之后，为了节省空间全节点，是可以删除掉区块中的实际交易内容的，其代价是丧失枚举交易的能力，同时也丧失了帮助其他全节点自举的能力。

另外，通过验证一个交易是否在链头上，来确定账户余额的做法，仅对于 UTXO 交易模型有效。对于以太网这样每个交易仅为增量修改信息的交易模型，仅靠验证一个交易是否在链头上，是无法得知账户的余额的。

CPU 处理能力，这个部分同吞吐量 TPS 线性相关

对于每一个收到的新区块，无论最终时候成功成为链的一部分，全节点都需要验证其携带的每一个交易是否被正确签名。同时会验算每个区块的 Hash，以确保其达到了当前工作量证明 PoW 难度的要求。对于拜占庭容错 BFT 算法，还需要验证各个委员会成员的签名是否正确。这里主要的工作量是验证签名。验证签名在一台普通计算机上 [email protected], C++ 并行实现的速度可达 40K op/s，也就是 4 万 TPS 每个交易需要验签一次。

对于每个交易，如果是支付交易，将需要至少查找一次账户的索引结构通常为哈希表，并做一次加法和大于的判断；为了更新账簿，还需要至少一次加法和减法。这样的一系列操作，在一台普通计算机上的速度可以轻松达到 1M op/s。如果是智能合约，会需要在虚拟机中执行对应的智能合约指令，对于现有的金融本质的应用 包括类似 Cryptokittes 类或 Fomo3D 类的区块链游戏，至少可以达到 100K op/s。

这意味着什么？

针对上面的分析，我来做一个小结：对于一台普通的计算机，拥有 13Mbps 的互联网连接，[email protected] 4Core 的 CPU，16G 内存，512G SSD 硬盘 250MB/s。网络带宽导致的 TPS 理论上限约为 7 千 TPS，硬盘文件 I/O 导致的 TPS 理论上限为 5 万 TPS，CPU 处理能力导致的的 TPS 理论上限约为 5 万 TPS。另外，内存大小导致的地址理论上限约为 2.5 亿个地址。

这里可以看到，对于性能来说，网络带宽是最首要的瓶颈根源，其次是硬盘的 I/O 和 CPU 的处理能力。对于容量来说，内存是最主要的瓶颈根源。

分片应该做到什么？

从上面对瓶颈根源进行分析之后，我们可以得到这样的结论：特定的分片方案至少要切分系统的网络带宽、内存容量相关的工作量，才有可能大幅提高全网的伸缩性，才有可能打破所谓的「不可能三角」。

必须再次强调，这个结论非常重要。因为只有真正了解这一点，才能进一步讨论分片方案是否真的可以打破「不可能三角」。

虽然在前面的分析中，带宽和内存是短板，但实际上，其他部分的约束也并不富余。理想的情况下，分片系统能够切分上述四个方面所有的负担。对于一个有 n 个分片的系统，其每一个分片仅需要承载 1/n 的全网负荷，将网络带宽、硬盘文件 I/O、CPU 处理和内存容量的消耗都降到原来的 1/n。在分布式系统中，这个是高伸缩性能带来的性能和容量提升的上界。一个分片系统如果可以实现这个，即性能和容量可能随着分片个数 n 而线性提升，那么理论上，可以使得全网的性能和容量能够被无限地提升。

而现实情况是，分片系统为了实现应用逻辑的正确性，协调各个分片之间的运作以及实现整体的安全性，需要每个全节点引入额外的工作量 overhead。这些额外的工作量是个常数 O(1)，即和分片个数 n 无关，那么全网线性提升仍旧可以保证。

如果额外的工作量的阶 order 小于线性，例如 O(log n)，那么就意味着随着 n 的增加，全网提升比额外工作量的增加要来得快，全网线性提升还是可以实现的。但是，如果额外的工作量的阶大于或等于线性，例如 O(n log n) 或 O(n^2)，那么基本上全网提升到一定程度，就无法继续了。因为全节点额外引入的工作量成为了新的首要瓶颈。

跨分片交易的原子性保证

区块链中的每一个交易都是原子的，必须保证其涉及到的操作或者全部完成，或者一个都不开始，才能使得最终状态是正确的。

对于涉及到多个分片的交易，我们不得不协调发生在各个分片中的操作，保证它们都能被没有错误地完成，并且不受其他交易的干扰。这里看起来可以简单借用在多线程编程中常用的线程同步概念，用诸如临界区 critical section 等方式，锁住涉及到的状态，阻止其他交易触碰这些状态，在完成交易所有操作后释放。但是，这会导致部分分片的执行被阻塞，而导致实际性能大打折扣。并且随着全网规模扩大，分片数量增多，跨分片交易的比例必然会极剧上升，从而使得加锁变得非常频繁。

一个设计良好的分片系统，必须具备高效的跨分片交易处理算法，并且算法的开销应该和分片数量 n 无关。

单个分片的安全性保证

分片系统中，如果每个分片有独立工作的共识系统，也就是每个分片自己一条链，全网能最大获得的吞吐量的 n 倍提升。

共识系统的安全性依赖于出块权力的大多数 majority 是可信的，这个大多数在 PoW 系统中为 50%，在 BFT 系统中为 2/3，甚至更高。而当全网有 n 个独立工作的共识系统时，这时平均分到每一个分片的大多数变会降低到原来的 1/n。这样攻击这些分片中的共识系统的壁垒，对于 PoW 系统会降低到全网的 50/n, 对于 BFT 系统则会降低到 1/(3n)。从而导致，仅需要非常低的成本，就可以攻击某一个特定的分片，例如构造双花攻击 double spend。而在一个分片系统中，只要有一个分片被攻击，其后果会藉由跨片交易迅速污染到其他的分片。

这就是为什么每一个分片系统都必须处理好安全问题，使得攻击特定分片的代价同攻击全网一样高。

分片方案的一些误区

误区一：分片的颗粒度不够细

分片的切分依据需要有足够的颗粒度，这样才能使得分片个数 n 取到足够大的值，并且不容易产生单点过热 hotspot。例如按照交易参与方的地址分，或者按照交易本身的 hash 值来分。这些是可行的方案，因为地址和交易的数量本身足够的多。

早期我还看到有些分片的方案按照业务来切分的，这是不可取的，颗粒度不够细，并且如果单个业务活跃度很高，需要更高的性能和容量，却无法获得分片系统所带来的提升。

在全网分片结构不发生改变的前提下 例如给定分片数量 n ，分片的切分依据应该是确定的，和账簿状态无关的，并且是可以被简单计算的。

对于提交交易的轻量节点，可以根据交易内容唯一确定这个交易应该被发送到对应的某个分片。早期看到动态的调整地址归属，试图将经常交互的地址划分在同一个分片，从来减少跨分片交易发生的概率。这种做法是不切实际的，因为本质上同分片数量相矛盾。就以太坊 ERC20 的历史支付交易来看，在 4 个分片的时候，跨分片交易比例为 75%，在 32 个分片的时候，跨分片交易比例为 97% 按支付发起者的地址 , 平均随机划片。

误区二：鼓吹智能合约的计算复杂性

从前面的分析可以看到，CPU 处理并不是短板。不过我却在现实中看到若干方案，强调智能合约非常复杂，不仅 GPU 不够用，甚至还需要 GPU 乃至集群来计算。

在分片设计中，每个分片依旧承载全网全部的吞吐和容量，只是将交易的验证以及状态更新分开在各个分片做，并且之后引入一个 O(n^2) 的通讯量，将部分更新过的状态传播到其他分片。而事实上，即使是现实世界中的业务，各种交易、清算其实际计算一点都不复杂，就是一些加减乘除，而更多的工作量是在安全验证以及通讯上面。

当然我们可以假想一种奇特的应用，需要巨大的计算量来完成逻辑层面的交易验证和状态更新。这会使得 CPU 处理最先成为瓶颈，并且使得 GPU 加速变得可能有意义。不过我会很怀疑这样的应用 或者应用的这个部分 是不是区块链的真实需求，是不是应该由区块链来承载。

误区三：忽略容量瓶颈

近期我看到一些分片方案，认识到了性能瓶颈的本质是带宽的约束，并从这一点切入划分工作量，让每个分片负责全网的一部分交易，包括其相关的计算。

不过非常遗憾，我看到的这些方案没有切分和用户容量相关的负荷，每个分片仍旧需要维护全网所有用户所有 DApps 的状态。并且，由于所有用户状态需要每个分片都维护，导致某用户在特定分片中的更新必须广播到其他的分片，这将额外引入一个 O(n) 的通讯量。由于用户容量相关的负荷没有被切分，导致系统无法承载更多的用户和 DApp 在链上发生交互，从而使得性能的提升无法被充分利用，约束上层应用的发展。

误区四：忽略安全问题被稀释的可信大多数

前面的分析已经提到，在分片之后可信大多数被稀释，攻击成本将极大下降。但是，到目前为止，我还没有看到有可靠的方案，能切实解决这个问题。

可能会有团队说，攻击成本即使降个几倍，也是很难攻击的，攻击要花很多资金，没人会真的去攻击。我不认同这种看法。

我的观点是，即使在不分片系统中，直接的暴力算力攻击已经屡有发生，更别说攻击成本被降低的分片系统了。如果我们不处理这个问题，只是祈祷没有人来攻击，那么在这样的系统设计之下，性能和安全就构成了直接的矛盾，越高的性能，即越多的分片，就会导致更低的攻击成本。这其中安全风险巨大。

误区五：双层设计

有不少分片方案，在各个独立的分片之外，引入了一个根链 有些叫做主链或母链，由其完成各个分片之间的沟通和协调，或者由其来保障各个分片的安全。

对于这类方案，需要比较细致的个例分析，不排除有可行的方案出现。但是总体上，当跨分片交易的比例很高的时候，根链有极大的可能成为系统的瓶颈。而利用根链作为安全保障的系统，其实本质上很可能就是一个单链系统。

在我看来，优异的分片设计方案，不应有分层的结构，而是各个分片应该是同质的，在功能上完全一致，地位上也完全平等。

异步共识组

可以说，以伸缩性为目标的公链研发项目，其方案中如果没有分片的设计，都是不切实际的，在未来的实际应用中必将面对性能瓶颈和容量瓶颈，至少会遭遇这两个瓶颈中的一个。

由于分片这个术语本身太过于宽泛，我想在下面引入 异步共识组 Asynchronized Consensus Zones 这个概念来，大家讨论一下理想的分片设计究竟应该是什么样的。

我先来解释一下，什么是异步共识组。

异步共识组由多个同质的、功能上完全一致、地位上也完全平等，并逻辑上尽量隔离的独立共识系统的实例所构成，他们并行工作，分摊全网的吞吐压力，分摊全网状态的维护工作。

异步共识组中每一个共识组采用具体的共识算法可以是 PoW/PoS，也可以是 BFT 类算法，或这些算法的改进。异步共识组的设计是如何让他们完全独立地并行工作，由于各个共识组在 IT 资源的消耗上是互相独立的，那么全网的吞吐性能和账簿容量将随着全网共识组的数量增加而线性增加，而参与其中的全节点的工作压力依旧是单个共识组的负荷。

异步共识组是共识算法中立的，并不限定具体的在各个分片中采用的共识算法。有很多团队在研究和改进共识算法，无论共识算法被改进到什么程度，任何已知的共识算法或者是今后的改进版本，都可以被应用在异步共识组这个技术架构之中，从而得几个数量级的性能和容量的提升。

假设我们用比特币的 PoW 算法，用同样的配置参数 1MB 块，10 分钟出块间隔 作为共识组的共识算法，对于一个具有 1024 个共识组的网络，全网将获得 7000 多 TPS 的吞吐性能。分片的全节点按照一台普通的计算机来算，在 13Mbps 的互联网连接、[email protected] 的 CPU、16G 内存、SSD 硬盘 250MB/s 的情况下，全网将具备等效的 13Gbps 带宽、16TB 内存、4096 个 Core 的计算能力，以及 250GB/s 的 I/O 能力，用来承载所有用户的账簿和 DApp 的状态，以及其中涉及的计算。而对于每个共识组里面的每个节点，它们所负担的通讯、计算和存储的压力，仅同运行一个比特币系统的全节点的负荷相当。无论全网扩张到多大的程度，网络中的单个参与者始终不会有明显増大的负担。

异步共识组的挑战有哪些？

异步共识组是一个理想方式的模型，不仅概念简单，而且可以完美突破全网的性能瓶颈和容量瓶颈，实现高伸缩性的区块链系统，并且对去中心化程度没有任何的牺牲。但是，这个模型要成为切实可行的方案，正如上文提到的，需要让这样的一个系统正确工作并保障安全性。这里需要两个方面的设计巧思：

只有，解决了这两个挑战，才能使得异步共识组系统能够正确安全地工作，释放其强大的性能和容量，打破所谓的「不可能三角」，服务于大体量的区块链应用。

具体这些挑战如何解决，并且如何最小化所引入的额外开销？我会留点时间，在未来的文章中和大家继续探讨 :)

欢迎大家通过我的微信公众号「王嘉平」和知乎专栏「去中心化数字世界随想」，就这个话题展开更多讨论。

—-

编译者/作者：王嘉平

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。