unitimes.io

全球视角，独到见解

学习的时间又到了！本文将使用简单易懂的语言解说区块链分片技术，耐心读完本文的读者将会发现，分片是如此的有趣！译者在翻译本文的时候，对开发者们的思路和解决问题的方式真是感叹不已...精通技术的人真是自带光环啊！废话不多说，开启学习模式吧！

本文是 Blockchain Sharding（区块链分片技术）系列的第一篇。阅读完本文之后，您将了解为何Sharding（分片）是通往未来区块链协议证明的路径，当前分片的构建方式，所有分片协议所面临的挑战，以及如何解决这些挑战等内容。本系列中的第二篇将探讨更为高级的主题，如数据可用性、数据有效性等内容，详情请关注 Unitimes 之后推出的文章。

众所周知，以太坊这条最常使用的公链主链每秒能够处理的交易不到20笔。由于这种限制，再加上以太坊网络的受欢迎程度，带来的是高昂的gas费用（即在网络中执行某笔交易所产生的成本费）和很长的交易确认时间；根据 https://ethgasstation.info/，尽管当前每10-20秒就能产生一个新的区块，但每笔交易被打包进入区块所需的时间却要1.2分钟。低吞吐量、高价格和高延迟是当前以太坊面临的主要问题。

以太坊网络低吞吐量的主要原因是什么？原因是网络中的每个节点都需要处理所有交易。在协议层上，开发者们已经提出了很多解决吞吐量问题的方案，这些解决方案大多可以分为将所有计算委托给一小组强大的节点来完成，或者让网络中的所有节点只处理所有工作中的一部分。

前一种方法的一个极端例子就只通过一个节点来处理所有交易的 ThunderCore （thundercore.com/），该平台声称可以实现每秒处理1200笔交易，比以太坊网络提高了100倍（但我并不支持 ThunderCore，或者为该平台的吞吐量背书）。还有 Algorand，SpaceMesh，Solana 等都属于前一种解决方案，通过对共识协议和区块链自身的结构进行各种改进，以此来运行更多的交易，但这种方式存在限制，即单个机器能处理的交易有限（尽管很强大）。

后一种方式就是 Sharding（分片），即将网络中的工作分摊给所有参与的节点。这就是当前以太坊基金会（EF）计划扩展以太坊网络的方式。截至目前，有关分片的完整规范还没有公布。

最简单的分片 Beanstalk

我们从实现分片的最简单的方式开始讲，本文将这种方式称为Beanstalk。Vitalik在他的文章中将之称为“scaling by a thousand altcoins（通过上千种山寨币来进行扩展）”。

在Beanstalk这种分片方式中，我们不会只运行一条区块链，而是运行很多条链，并将每一条链称为“分片”。每个分片将拥有自身的验证者（Validator，即通过PoW机制挖矿或者投票机制来验证交易和生成区块的网络参与者。）我们暂时假设各个分片从不相互交流。

尽管Beanstalk的设计很简单，但分片技术面临着一些主要挑战。

参与的验证者&信标链

首当其冲的挑战就是，由于每个分片都有自己的验证者，每个分片的安全性就会比整条链更差。因此，如果一条有X个验证者且没有分片的区块链，决定硬分叉成一条有分片的链，并将X个验证者分摊到10个分片中，那每个分片中的验证者数量就是X/10个，且只需要控制总验证者数量的5.1%（51%/10）就可能破坏一个分片。

这将我们带到了第二点：由谁来为每个分片选择验证者？要知道，只有当所有被控制的5.1%的验证者都在同一个分片中，这样才能破坏该分片。如果验证者无法选择验证哪个分片，那某个控制5.1%验证者的参与者将所有这些被控制的5.1%的验证者选入同一个分片中的概率是非常低的，从而大大降低了该参与者破坏整个系统的能力。

左：有X个验证者搭建某条区块链；需要控制51%的节点才能破坏整条链；

右：有X个验证者搭建10条链；需要控制5.1%的节点，且这些节点在同一条链中，这样才能破坏该条链。

当前，几乎所有的分片设计都依赖于某种随机性（randomness）来为所有分片分配验证者。区块链本身的随机性是一个非常具有挑战性的话题，我还是以后单独出一篇文章来讨论吧。但我们当下还是先假设我们可以实现这种随机性。

随机性和验证者分配都需要进行计算，这种计算比不是针对任何特定的分片的。为了实现这种计算，实际上所有现有的设计都包含一条单独的区块链（以太坊2.0中称为信标链），这条区块链负责执行维护整个网络所需的操作：除了生成随机数和将验证者分配到各个分片，还包括接收分片的信息更新，处理权益证明（PoS）系统中验证者抵押的押金及其罚没（slashing，当验证者验证某笔交易是有效的，而实际上该笔交易并非有效时，该验证者抵押的一部分押金被罚没）等等。这条链在以太坊中就是信标链（Beacon Chain），在 Cosmos中就是 Cosmos Hub，在PolkaDot 中就是 Near 链。

在本文中，我们将这种链称为信标链（Beacon Chain）。信标链的存在将我们带入了下一个有趣的话题，即二次分片（quadratic sharding）。

二次分片

Sharding（分片）通常被宣传为一种通过增加参与网络运行的节点数来实现网络的无限扩张的解决方案。虽然理论上是可能设计出这样一种分片解决方案，但任何基于信标链（Beacon Chain）概念的解决方案都不可能无限地进行扩展。为什么这样说呢？因为信标链需要做一些记账计算工作，比如上文中提到的，信标链需要将验证者分配到各个分片链中，以及简要概述分片链区块，这些计算量是与系统中分片的数量成正比的（即分片数量越多，计算的工作量就越多）。由于信标链本身也是一条区块链，其计算受到运行信标链的节点的计算能力的限制，因此分片的数量自然会受到限制。

但是，分片网络的结构确实会因为对其节点的改进而产生乘法效应。想象一下，如果改进网络中节点的效率，那将使节点更加快速地处理交易。

如果运行网络的节点（包括信标链中的节点）处理交易的速度快了4倍，那每个分片能够处理的交易量将是之前的4倍，且信标链能够维持的分片数量也将是之前的4倍。由此来看，整个系统的吞吐量将增加4x4=16倍--因此称之为二次分片（quadratic sharding）。

当前还很难准确地衡量提供多少分片是可行的，但在任何可预见的未来，区块链用户的吞吐量需求将不可能超出二次分片的限制（即分片能够满足用户的吞吐量需求）。运行这么多分片所需的节点数量，要比当前运行所有区块链的节点数量还要多出好几个数量级。

但是，如果我们想要搭建未来的证明协议，研究这一问题的方案是非常有必要的。截至当前，最为先进的提议就是指数增长式分片（exponential sharding），其中分片本身就其结构而言就像一棵树，每个母分片（parent shard）统筹一系列子分片（child shard），而母分片本身可以是其他分片的子分片。

众所周知，Vlad Zamfir 正在研究一种不涉及信标链的分片设计，我曾与他共同研究过相关的原型，具体细节请参阅：

https://medium.com/nearprotocol/so-what-exactly-is-vlads-sharding-poc-doing-37e538177ed9

对状态进行分片

到目前为止，我们还没有很好地对此进行定义：当网络被分成多个分片时，什么东西被分离了出去，什么东西没有被分离出去。具体而言，区块链网络中的节点主要执行三个重要的任务：1）处理交易；2）将已被验证的交易和已完成的区块中继给其他节点；3）存储整个网络账本的状态和历史记录。这三项任务中的每一项都对运行网络的节点提出来越来越高的要求：

1. 随着需要处理的交易的数量不断增长，节点处理交易时需要更多的计算能力；

   
   

2. 随着需要中继的交易的数量不断增长，节点在中继交易和区块时需要更多的网络带宽；

   
   

3. 随着状态的增多，节点在存储数据时需要更多的存储空间。重要的是，与前两者不同，即便交易率（即每秒处理的交易量）不变，节点面临的存储需求依旧会不断增加。

由此可见，存储需求看起来似乎是最为紧迫的，因为它是唯一一个即便每秒处理的交易量不变，照样会随着时间的推移而增加的要求。但实际上，当前最为紧迫的是不断增长的计算能力的需求。目前，整个以太坊状态为100G，这对于大多数节点来说，是很容易就能实现的。但当前以太坊可以处理的交易量约为每秒20笔，比许多实际用例中所需要的tps少了好几个数量级。

Zilliqa 是当前最出名的在处理交易方面进行分片的项目，但该项目没有在存储方面进行分片。对交易处理进行分片是一个很容易解决的问题，因为每个节点都存储网络的整体状态，这意味着每个合约可以自由地调用其他合约，并从区块链中读取任何数据。由此来看，Zilliqa 采取了一种非常简单的方法，详细的分析可参阅我的这篇文章：

https://medium.com/nearprotocol/limitations-of-zilliqas-sharding-approach-8f9efae0ce3b

虽然很多人提议对状态存储进行分片，而不是对交易处理进行分片，但我还没有看到有任何项目在这么做。在实践中，对状态存储进行分片，几乎也就意味着对交易处理进行分片和对计算能力进行分片。

实际上，通过对状态存储分片，每个分片中的节点其实就是在搭建自己的一条分片链，这条链中包含的交易只会影响这条分片链本地的状态。因此，分片中的验证者只需要存储本地的状态，并且只需执行和中继那些影响本地状态的交易。这种拆分减少了节点对计算能力、存储和网络带宽的需求。但也引入了新的问题，如数据可用性和跨分片交易。我们会在下文中探讨这些问题。

跨分片交易

Beanstalk 并不是一种非常有用的分片方式，因为如果各分片之间不能相互交流，那这些分片也就和多条彼此独立的区块链没有差异。即便是目前当分片还不可用时，人们对各种区块链之间的互操作性的需求是非常巨大的。

我们现在只考虑简单的支付交易，其中每个参与者只在一个分片中有一个账户。如果某人希望将一笔资金发送给同一个分片中的另一个账户，这笔交易完全可以由该分片的验证者来处理。但是，如果Alice的账户在分片#1中，她想把资金发送给Bob的账户中，而Bob的账户在分片#2中，则不管是分片#1中的验证者（他们无法将资金记入Bob的账户中），还是分片#2中的验证者（他们无法将资金从Alice的账户中扣除），都无法完整地处理这笔交易。

在跨分片交易方面，存在两种方式：

1. 同步：每当需要执行跨分片交易时，与这笔交易相关的、需要进行状态转变的多个分片中的区块将会同时产生，且这些分片的验证者们会协同执行这笔跨分片交易。在这个方面，我知道的最为详细的提议就是 Vitalik 提出的 Merge Blocks（合并区块），见：

https://ethresear.ch/t/merge-blocks-and-synchronous-cross-shard-state-execution/1240

2. 异步：即一笔影响多个分片的跨分片交易在这些分片中异步执行，“记入资金”的分片（即上文例子中的分片#2）一旦获取了足够的证据证明“扣除资金”的分片（即上文例子中的分片#1）已经完成了自己的那部分工作（即已经将资金从Alice账户中扣除了），则“记入资金”的分片就会完成自己的工作（即将资金记入Bob的账户中）。这种方式更为普遍，因为更简单且分片之间更易于协作。当前，Cosmos、以太坊 Serenity、Near、Kadena 等就提议这种系统。但这种方式的问题在于，如果与这笔跨分片交易相关的那些区块是独立生成的，那这些区块中出现某个区块被孤立出来的概率并非为零，这使得这笔跨链交易只部分被完成。我们来看看下方的图片，图片中 Shard#1 和 Shard#2 这两个分片都分叉出了两个子分片，其中Shard#1中的一条子分片中的区块 A 和 Shard#2 的一条子分片中的区块 X’ 记录了一笔跨分片交易。

如果A-B和V’-X’-Y’-Z’这两条子分片链最终在相应的分片中（基于分叉选择规则）被选中，则这笔跨分片交易就完全敲定了。如果A’-B’-C’-D’ 和V-X这两条子分片被选中，则这笔跨分片交易就完全被抛弃了，这还可以接受。但如果A-B和V-X这两条子分片链被选中了，那这笔跨分片交易只有部分（即A-B链中的那部分）被敲定，另一部分（即V’-X’-Y’-Z’链中的那部分）则被抛弃了，导致出现原子性故障（atomicity failure）。我们会在之后的第二部分讨论如何解决这一问题。

需要注意的是，除了分片链之间的交流外，未进行分片的链与链之间的交流也是非常有用的。区块链之间的互操作性是一个很多项目都在试图解决的复杂问题。在进行了分片的区块链中，解决互操作性问题要稍微容易一些，因为所有分片之间的区块结构和共识协议都是一样的，而且还有一条信标链用于充当协调功能。在一条进行了分片的区块链中，所有的分片链都是一样的。而全球所有的区块链生态系统中，有很多条不同的区块链（如以太坊、比特币、EOS等），这些区块链有着不同的目标用例、去中心化程度和隐私保障，因此，解决这些链之间的互操作性问题要难得多。

搭建这样一个系统，系统中的所有链都具有不同的属性，但使用非常类似的共识协议，有着类似的区块结构且拥有共同的一条信标链，这样的系统能够成为一个异构区块链生态系统，这个生态系统有着一个可运作的互操作性子系统。这样的系统不太可能实现验证者轮换的功能，因此需要采取一些额外的措施来保证安全。Cosmos 和 PolkaDot 就是这样的有效系统。Cosmos 团队的 Zaki Manian 写的这篇文章对这两个项目之间的一些关键方面进行了概述了对比，感兴趣的读者可以前往阅读，文章地址：

https://forum.cosmos.network/t/polkadot-vs-cosmos/1397/2

恶意行为

你现在已经知道了分片是如何实现的了，包括信标链的概念，验证者轮换和跨分片交易。

在掌握这些信息的同时，还要考虑意见重要的事情。具体来说，就是恶意验证者将可能采取什么对抗性的恶意行为。

01

恶意分叉

一组恶意验证者可能会企图创建一个分叉。请注意，不管底层的共识协议是否是拜占庭容错（BFT），这都不重要，只要破坏足够数量的验证者，就完全有可能创建一个分叉。

对单个分片进行51%的攻击，比对整个网络进行51%的攻击要容易得多（我们会在之后的文章中详细讨论这种概率）。如上所述，跨分片交易涉及到多个分片的某些状态改变，且这些分片中发生了状态变化的相应区块，要么是完全被敲定了（即会出现在其相应分片上选定的链中），要目被孤立了（即不会出现在其相应分片上选定的链中）。由于一般来说，分片被破坏的概率不能被忽略，我们不能假定分叉是绝不可能发生的，即便分片验证者之间达成了拜占庭共识，或者在状态改变了的区块之上已经生成了很多区块。

这个问题有多重解决方案，其中最常见的解决方案是，不定期地将分片链上的最新区块与信标链进行交联（cross-link）。分片链上的分叉选择规则会变为永远倾向于选择那条已经进行了交联的链，且仅仅将分片的分叉选择规则应用于上一次交联之后发布的区块。我们将在本文的第二部分更进一步探讨什么是分叉选择规则，并对分片区块链的分叉选择规则提议进行深入分析。

02

批准无效的区块

在进行了分片的区块链中，一组验证者可能企图生通过使用一个错误的状态转换函数来生成一个区块。例如，交易前的状态是 Alice 有10个代币，Bob 没有代币，区块中包含的交易实际应该是 Alice 发给 Bob 10个代币，但交易后的状态却是 Alice 没有代币而 Bob 有1000个代币。

左边为有效的区块，右边为无效的区块

在一条传统的、没有进行分片的区块链中（如当前还没有进行分片的以太坊网络），上述这种攻击是不可能出现的，因为所有网络中的参与者都会验证所有区块，这使得那个存在这种无效状态转变的区块将被其他区块生产者和网络中没有创建区块的其他参与者所排斥。即便怀有恶意的验证者继续在这个无效区块上创建更多的区块，且速度要比搭建正确链的诚实验证者更快，使得这条包含无效区块的链要更长，这都不要紧，因为使用该条区块链的每个参与者，无论出于何种目的，都会验证所有的区块，并且会抛弃所有那些搭建在无效区块之上的区块。

在上图中，一共有五名验证者，其中三名是恶意验证者。这是那么恶意验证者创建了一个无效区块A’，并继续在这个区块之上创建新的区块。两名诚实验证者将A’认证为无效区块并将之丢弃，并在已知的最后一个有效区块上创建一个分叉。因为在诚实的分叉链中验证者更少，因此该条链会更短。

在传统的、没有进行分片的区块链中，使用该区块链的参与者们，无论出于何种目的，都有责任验证所有他们接收到的区块，并对区块状态进行重新验算（recompute the state）。因此，所有与该链利益相关的人都会观察到区块A’是无效的，因而也会立即丢弃区块B’、C’和D’，并将A-B链当做当前最长的有效链。

然而，在进行了分片的区块链中（比如，以太坊2.0将是分片区块链），没有任何一个验证者可以验证所有分片中的交易，因此验证者们必须通过某种方式来确保，该区块链的任何分片的历史记录中都不存在无效区块。

需要注意的是，信标链中的跨联（cross-linking）与上文提到的在传统未分片的区块链中的分叉是不一样的，跨联并不是一个能充分解决这一问题的方式，因为信标链不具备验证区块的能力。信标链只能验证在某个分片中，有足够数量的验证者签署了某个区块并证明了该区块的正确性，至于这些验证者是否诚实、这个被验证的区块是否真的有效，信标链是无法验证的。

对于这个问题，我只能想到两种解决方案，然而目前这两种方式都没有真正令我满意：

1.设定某个合理的机制，当有人企图添加采用了错误状态转换函数的区块时，该机制能向系统发出警报。假设每个分片都在运行某种拜占庭容错（BFT）共识，如果某个特定分片中的恶意验证者的数量少于三分之二，则至少需要有一个诚实的验证者来验证区块，并验证该区块是否采用了正确的状态转换函数。如果恶意节点的数量超过三分之二，则他们可以在没有诚实节点的参与下敲定一个区块。假设某个分片上至少有一个节点是非恶意的，则需要某种机制使得这个（些）诚实的节点能对正在生成的区块进行监控，并给予他们充分的时间来对使用无效状态函数的节点发起挑战。

2. 在区块中设置一些足以证明使用了错误的状态转换函数的信息，但比采用状态装换函数进行验证要更具成本效益（即更便宜）。最接近这种想法的机制是 zk-SNARKs（虽然我们并不是真的需要“zk”，也即零知识验证的功能，非零知识 SNARKs就足矣），但 zk-SNARKs的计算速度非常慢。

当前，很多协议都认为，只要搭载了适当的验证者循环机制或拜占庭容错共识，是不可能会出现分叉或者无效状态转换的。我们将在第二部分谈及为什么这种假设并不合理。

结尾

看完上面的信息，您现在对分片的大部分重要内容都有所了解了，例如信标链的概念、计算与状态分片、以及交叉分片交易。敬请关注第二部分，我们将更深入地探讨预防攻击的内容。

非常感谢Kadena团队的 Monica Quaintance 以及Cosmos团队的 Zaki Manian，感谢他们为本文提供了大量宝贵的反馈。

原文作者：Alexander Skidanov，NEAR Protocol & NEAR AI 编者

翻译：Jhonny，Echo

原文链接：

https://medium.com/nearprotocol/the-authoritative-guide-to-blockchain-sharding-part-1-1b53ed31e060

【文章版权归原作者所有，其内容与观点不代表Unitimes立场。转载文章仅为传播更有价值的信息，合作或授权联系请发邮件至editor@unitimes.io或添加微信unitimes2017】