人人都能读懂的「以太坊2.0分片设计」

        当我们在7-11买早餐的时候，如果只有一个收银员，就要排很长的队等待结帐；如果有两个收银员，立刻就会快一倍；假如有四个收银员，也许就不用排队了。这就是分片的基本逻辑，把一个人的工作分给多个人来完成以提升效率。

        从以太坊分布式账本的角度来看就是：分片前只有主链这一个账本，每秒大约能处理12～45笔交易，当交易量大于这个数据时就需要排队，也就是网络会拥堵；分片就是把一个账本变成64个账本，让它们同时来处理交易，相当于7-11开了64个收银台来收银。

        分片的逻辑很简单，但为什么如此难以实现？因为把一个账本分成64个账本记账，会面临很多新的问题，分片技术要做的正是解决掉它们。本文将从这些问题出发，来弄清以太坊2.0的分片到底是怎么一回事。

        01 如何分片

        1.把交易分配给分片

        一个分片中包含交易和把交易打包进区块的验证者，完成分片的第一步就是要确定如何给某个分片分配交易和验证者。先来看分配交易。

        让我们用三个村庄的故事来理解：有一个渔村、一个猎户村、一个农夫村，村庄内和村庄间常常有交易，但没有货币，大家记账。以前是用一个账本记三个村子的账，速度有点慢，现在改成三个账本记，那么由哪个账本来记哪些帐了？

        有一个方法是，三个账本放在那儿，来了一笔交易后，看哪个账本前没人排队就记在哪个账本上；但这会带来一个问题就是，每个账本都必须有所有人的账户信息，不然我来你这里排队，而你没有我的账户。

        正因为如此，该分片方式的一个主要问题就是不能减少单一账本上存储的数据量，而这种存储需求对于想参与记账的节点是很高的门槛；该方式还需要解决双花问题，因为一个人可以同时在不同的分片中花费同一笔钱。

        另一个方法是，渔村有一本账，猎户村有一本账，农夫村有一本账，账本中都只有自己村庄的账户信息，也只记录自己村庄内的交易。如此一来三个账本就可以同时记账，记账效率高，存储需求少。这正是以太坊采用的分片方法：状态分片，每个分片存储且只存储属于自己分片的账户状态。在实现上，以太坊是由用户自己选择加入哪一个分片，而不是按自然村庄分片。

        状态分片最大的问题是，如果渔村的人要和猎户村的人交易怎么办？渔村的账本里没有猎户村人的账户，猎户村的账本里也没有渔村人的账户。实际上，这正是分片技术面临的最大考验，跨分片通信。彻底解决这一问题的时候，就是以太坊2.0可以被使用的时候。本文将在第二部分讨论该问题的一些解决方法。

        2.把验证者分配给分片

        在把交易安排到不同的分片后，下一个要解决的问题是如何为某个分片分配记账的人，也就是分配验证者。

        以太坊有64个分片，每个分片有128位验证者，如果分片的验证者是固定的或者可预知的，那攻击者控制分片，也就是收买128中的2/3是一件容易的事情，怎么办？以太坊的解决办法是随机从所有验证者中选出某个分片的验证者，并且每6.4 分钟（一个epoch的长度）更换一次验证者。如此一来，攻击者就只有万亿分之一不到的几率能控制一个分片中 2/3 的人（推理过程见参考资料1）。

        信标链的主要工作之一就是为分片链分配验证者，该工作最需要关注的是随机性的实现。首先在于随机性的重要程度，如果不能随机分配验证者，就无法保证账本的安全；其次在于随机性的难度，在区块链上实现随机是一件异常困难的事，可以认为到目前为此还没有真正称得上是工程实现了的经受了验证的随机算法。

        以太坊的方案是使用RANDAO+VDF提供随机数，以实现随机性。把RANDAO拆解成RAN（random）和DAO就很易理解，它是指一群人中的每个人都独自提出一个随机数，再把所有人的随机数合在一起生成最后被使用的那个随机数。因为任何人都难以知道其他人提供的数字，也就难以预知合起来的最终数字。

        不过RANDAO模型有个缺陷，就是提供最后一个数字的人是有机会作弊的：他知晓前边所有人提供的随机数之和，也就能通过调整自己提供的数字使得最终结果对自已有利。

        为解决这一问题，以太坊引入了VDF（可验证延迟函数），它的作用很简单，就是让最后一个提供随机数的人无法在自己提供数字之前算出之前所有人的随机数之和，因而也就无法操纵随机数。（RANDAO+VDF的详细介绍见参考资料2）

        3. 由中继者存储分片

        不知道你有没有发现，轮换账本的验证者将带来一个新问题：验证者一会儿被分配去渔村记账，一会儿被分配去猎户村记账，如果他手上没有全部的账户信息，如何记账？如果他有全部的账户信息，就又是拿着一个全账本，没有做到状态分片。

        为解决这个问题，以太坊提出了一个重要的新设计：无状态客户端。简化理解就是，渔村的账本就放在渔村，猎户村的账本就放在猎户村，验证者手中不拿账本，只负责在不同村庄间跑来跑去记账。

        那么谁来保管不同村庄的账本？以太坊引入了中继者（状态提供者）这个角色，由他们负责存储不同分片的账户状态，且可以只为某一分片服务。中继者的工作易于理解，但怎么为他们的服务付费、如何保证他们的诚实……这些相关机制的设计是需要解决的全新问题，也是社区成员应该参与讨论的治理问题。

        无状态客户端的实际情况比上文描述的复杂很多。「交易」本身的构成与未分片时不同，它要附带见证数据以证明自己是有效的。可以认为在1.0中，验证者需要自己存储旧账，以验证新交易；在2.0中，交易需要自己把旧账带上，交给验证者作验证。

        但我们无法要求每个用户都存储全部的旧账，以便在发起交易后能够证明该交易，这时候就需要「中继者」，它存储了该分片的全部账户状态，只要用户提起需求，它就能够帮助用户向验证者提供交易的见证数据。

        Vitalik Buterin在3月11日发表文章提出用多项式承诺代替状态根，该技术就是被用于此处，它是改用零知识证明的方法为交易提供证明，可以理解为是把数据的计算结果提供给验证者做验证，而不是直接把所有相关数据提供给验证者做验证，这种方法能大幅减少见证数据的大小，也就能有效降低各种开销。（Vitalik新方法的详细介绍见参考资料3，无状态客户端的详细介绍见参考资料4）

        到这一步，就完成了把一个账本分为多个账本，也就是划分分片的工作。

        02 跨分片的交易

        如果渔村的人只和渔村的人交易，猎户村的人只和猎户村的人交易，那各个村庄把自己的账记好就行，这并不需要什么新技术。可如果渔村的人要和猎户村的人交易怎么办，不同的账本如何互通？这正是状态分片面临的最棘手的问题。

        解决这一问题有两种思路，一是同步（紧耦合），二是异步（松耦合）。

        假设渔村有个人叫甲，猎户村有个人叫乙，甲要给乙100块，同步是指：当甲发起转账后，渔村和猎户村的记账人都知道这笔交易及交易进展，渔村记账人在账本上给甲减了100，猎户村记账人在账本上给乙加了100，交易完成，两个村庄同步生成新区块。

        异步是指：当甲发起转账后，渔村的账本给甲减了100，生成新区块；猎户村记账的人在之后以某种方式收到了这个消息，确认甲的钱确实被减少后，就在自己的账本上给乙加100，交易完成，但两个村庄是异步生成新区块的。

        同步方式看上去友好，其交易执行过程的观感如未分片一样，但它隐藏着一大问题，就是难以应对「连续状态改变」。这是什么意思？

        如果甲只转给乙100块，渔村和猎户村在听到这笔交易后，很容易确认大家都是这么记账的，渔村的账本就给甲减了100，猎户村给乙加了100，完成记账。但如果甲转给乙100，紧接着又转给乙50，发生连续状态改变，不过甲一共只有120块，这时候两个村庄就难以确认对方是怎么记账的：

        要是每个验证者都自己去找对方的验证者交流，通讯开销会激增，达成某一结果也极其困难；要是通过双方的村长交流，每个村庄内部就需要预先进行一轮共识，再由村长把一个确定的结果告诉对方，这除了增加开销，还难以实现，因为以太坊的共识机制本身就是无法达成确定结果（finality）的。

        异步方式不会被连续状态改变这种情况困扰，因为它的做法就是「等」，等你的状态确定了，我再进行下一步；等渔村给甲把账记完了，猎户村看到甲是减了100还是减了50后，再决定给B加上100或50。

        异步方式自己的问题是原子性故障。交易本该具有原子性，要么执行，要么不执行，但在异步方式下，有可能出现交易的一部分确定了，但另一部分被抛弃了。

        比如渔村给甲减了100的那个区块最后在渔村主链上，被确定了，但猎户村给乙加上100的那个区块最后在猎户村侧链上，被抛弃了。原子性故障是一个问题，但可以通过设计解决，关于这一部分的详细介绍可见文末参考资料5。

        异步方式的另一个问题是时间开销和通讯、存储开销，也就是完成一笔跨分片交易所需要等待的时间以及占用的资源。在不同分片间传递信息的方式决定了这些开销的多少，不同类开销有着相互关联难以两全的关系，设计时要追求的是平衡。以太坊2.0在未来的性能正是由信息传递方式主导的。

        以太坊讨论过一些异步架构模型，最新一种是由Vitalik在2019年10月的DevCon 5 大会上提出来的，其基本思路就是用信标链传递信息：在每一个slot（12 秒），分片链产生区块并与信标链区块交叉链接，其连接方式如下图，这样一来，任何分片在打包自己的新交易时都能通过信标链知道之前所有其他分片的信息。不同分片间异步一个slot。

        这种方法减少了跨分片交易的等待时间，但提高了对信标链的要求，信标链需要为所有分片存储证明数据；这种方法还增加了交联的链接数量（原设计为每个epoch ，也就是6.4分钟、32个区块交联一次），这必然增加各种相关开销，也因为如此，以太坊的分片数量从1024片改为了64片，从另一个设计方向上减少总的链接数量。（该架构的详细介绍见参考资料6）

        从目前的一些分片设计方案看，同步模型更倾向于分片与分片自己沟通，异步模型更倾向于分片与分片互不往来，通过某个第三者沟通；前者面临通讯量的问题，后者面临多种开销的平衡问题。跨分片交易的设计与实现尚在进行之中，暂不能确定以太坊2.0最终采用哪种架构。

        03 跨分片的智能合约

        在介绍完分片和跨分片的交易后，以太坊2.0开发之路上的终极大BOSS来了，它就是跨分片的智能合约。跨分片交易和跨分片智能合约的区别在于交易只有全局变量，而智能合约有局部变量。局部变量会带来什么麻烦？

        以太坊在分片之后，从物理角度来看有64个账本，但从抽象角度来看只有一个账本：可以把账本想象成一棵大树，树的每一片叶子存储着一个账户状态数据，64个账本就是64棵树，再把这些树的树根给到信标链，就会形成一棵新的大树，64个账本也就合成了一个账本（这只是一种近似的比喻）。

        在跨分片的交易中，当一个分片需要知道另一个分片的账户状态时，不管以何种方式，它总能顺着这棵树找到那片存储状态的叶子，然后改变自己分片的账户状态，完成交易。可以认为通过这棵树，不同分片完成了信息的互通。

        但对于跨分片的智能合约，问题来了，这棵树叶子上保存的数据都是全局变量，没有局部变量，如果一个分片的智能合约调用另一个分片的智能合约时，两者如何传递局部变量的信息？这棵树无法为它们提供服务。

        也可以这么理解，交易跨分片只需要看全局变量，就是看一级状态，智能合约跨分片需要看局部变量，就是还需要看二级状态。交易跨分片和智能合约跨分片的设计难度不在一个数量级上。

        目前还没有看到成体系的智能合约跨分片的设计方案，但有看到两种提议，一种是提议把相关联的智能合约放入同一个分片执行，也就是消灭智能合约跨分片的需求；一种是提议采用SIMD （单指令流多数据流）技术，让智能合约本身能够并行执行。

        以太坊2.0会在Phase 2引入智能合约，这代表着要到Phase 2才实现智能合约的跨分片，而只有迈过这一步，才可以真正宣告以太坊进入到2.0时代。

        1.《 Minimum Committee Size Explained》；作者，Chih-Cheng Liang；https://medium.com/@chihchengliang/minimum-committee-size-explained-67047111fa20

        2.《以太坊 2.0：随机性》；作者，Bruno Škvorc；翻译，Jhonny、阿剑；https://ethfans.org/posts/two-point-oh-randomness

        3.《Using polynomial commitments to replace state roots》；作者，Vitalik Buterin；https://ethresear.ch/t/using-polynomial-commitments-to-replace-state-roots/7095

        4.《Eth2.0 的中继者网络与手续费机制》；作者， John Adler；翻译，IAN LIU、阿剑；https://ethfans.org/posts/relay-networks-and-fee-markets-in-eth-2

        5.《区块链分片的理念与挑战》；作者，Alexander Skidanov；翻译，Jhonny、 Echo、阿剑；https://ethfans.org/posts/the-authoritative-guide-to-blockchain-sharding-part-1

        6.《Eth2 shard chain simplification proposal》；作者，Vitalik Buterin；https://notes.ethereum.org/@vbuterin/HkiULaluS

        7.《给工程师的 ETH 2.0 指南》；作者，James Prestwich；翻译，Aisling、奇奇、 stormpang、 阿剑；https://ethfans.org/posts/what-to-expect-when-eths-expecting

        8.《Merge blocks and synchronous cross-shard state execution》；作者，Vitalik Buterin；https://ethresear.ch/t/merge-blocks-and-synchronous-cross-shard-state-execution/1240

声明：此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。本网站所提供的信息，只供参考之用。