编者按：本文来自以太坊爱好者，作者：lightclient，翻译&校对：闵敏&阿剑，Odaily星球日报经授权转载。当我们向一种新的扩容范式转变时，回顾被抛弃的旧范式是一种很好的做法。这篇文章旨在让读者相信，“以rollup为中心”的方法并不会背离分片，并且有望构建对整个系统更直观的理解。OptimisticRollup的定义
出于本文的目的，我们先详细说明最简单的OptimisticRollup(ORU)实现。ORU需要具备以下几个特性：将所有交易数据提交到链上将状态根提交到链上假设状态根是正确的一些节点负责验证ORU的状态转换设有链上欺诈证明执行程序，可以撤销无效状态转换分片为什么不可行
在证明ETH2.0分片只是一种复杂的ORU系统之前，我们先来探究一下为什么原生分片系统并非安全的可扩展性解决方案。其背后原因不是特别直观。从数学角度证明分片的安全性
假设一条区块链上有16384个验证者和64条分片链，每条分片链都由128名验证者组成的委员会负责验证。委员会成员选举是不可预见的：每个slot结束后，所有委员会都会解散，并随机从全体验证者中重新选出64个委员会，因此每个验证者都不知道其他验证者所在的委员会。假设一个区块需要获得委员会中2/3成员的认可才能被添加到分片链上，这就意味着在全体验证者中包含1/3恶意验证者的情况下，通过随机的方式选出恶意委员会的概率是：
请注意，我们可以通过调整委员会的规模来按比例放大或缩小该参数，从而达到理想的安全级别。由于选出恶意委员会的概率极低，以及对不作为验证者的反向激励，该分片系统理应继承其非分片协调系统的安全性和活性保障。但是，就像现实世界中的大多数系统那样，实现这一点并非易事。由于委员会成员是提前选好的，恶意参与者就有机会贿赂理性参与者。如果可以轻而易举地创建从验证者公钥到IP地址的映射，就会出现更多行贿现象。此外，在免许可型系统中，可验证投票从本质上来说无法防止行贿。综上，分片的实际安全性相比理论上来说低至少一个数量级。与Plasma一样，分片同样存在数据可用性问题
虽然分片的安全性低于整体协议，但是我们依然能够确保其安全性，即，采用欺诈证明来撤销无效状态转换。但是，如果不为我们这个设想中的简单分片链引入额外的设计，那么恶意验证者完全可以扣住数据、不放出来，使得他人没有足够的数据来生成欺诈证明。接下来，我们将讲解如何实现这种攻击。假设有一条简单分片的区块链B，上面有X和Y两条分片链。区块链B在两个委员会中运行传统的拜占庭容错共识算法来帮助运行分片X和Y，分别是Cx和Cy。B上的每个区块都包含两个门限签名，即，Cx和Cy两个委员会中2/3的成员对各自分片链的当前区块的状态根的见证。假设每条分片链的每秒数据和交易处理量与非分片系统相同，那么引入分片链应该能提供大约两倍的吞吐量。在乐观情况下，事实确实如此。现在，让我们对B发起数据不可用攻击。假设一个恶意实体能够迫使Cx中2/3+1的成员签署无效的状态根，并且不公开对应区块的输入数据。之后，这个无效的状态根会包含在下一个即将被添加到B上的区块内。这时候，并没有合理的机制可以让B回到有效状态，我们可以举一些机制例子看看：Cx中剩余的1/3-1位成员可以在B上发出数据不可用警报。遗憾的是，这不是一个可明确归属方的错误，因此B无法确定是哪一方在作恶。怀有恶意的少数派有可能会借此发起零成本的DDOS攻击。网络中的其它节点可以发出数据不可用警报。但他们很可能做不到，因为在错误发生期间，只有Cx的成员在密切关注这个时间。由整个社区来发现错误，并主动介入将B回滚到最新的有效状态。这种处理模式显然是糟糕的。执行类似Plasma的批量退出机制，从X批量退出到B上，会产生相关的负面影响。就像Plasma一样，这里真正的问题是数据可用性。安全地提高数据可用性
希望上述分析能让你明白一个道理：我们首先应该将关注点放在扩展基础层的数据可用性上。否则，系统仍将遭受数据不可用攻击。从传统上来说，提高区块链上的数据吞吐量需要就系统所支持的最低硬件/带宽要求达成社会共识——得出一个可以接受的区块大小。MustafaAl-Bassam和VitalikButerin最近的研究提供了一种概率性机制来确保数据可用性。M.Yu等人进一步扩展了该研究，提出了CodedMerkleTree累加器这一概念，给出了最优阶数的指标。上述机制主要放宽了网络中参与者下载所有数据的要求。Vitalik的提议是，让网络中的参与者随机选取区块中的小部分数据进行验证，以确保区块提议者公开了数据。风险在于，区块提议者只需要隐藏少量数据即可发动数据不可用性攻击。因此，参与者必须多次对区块进行抽样验证，才能对区块的可用性建立起足够的信心。为了减少抽样次数，Vitalik提议采用二维Reed-Solomon编码来对区块数据进行编码。在这个结构中，区块被分割成N个份额，然后进行编码，生成M个份额，只要拥有M中任意N个份额即可重新构建区块。假设2N=M，区块提议者需要影响1/2的区块数据，才能成功发动数据不可用攻击。CodedMerkleTree采用类似的结构，只不过使用O(b)的解码成本和O(1)的哈希承诺来代替二维Reed-Solomon编码所提供的O(b1.5)解码成本和O()哈希承诺。关于该技术的详解，可以参见这篇文章。分片就是Rollup
ETH2.0的分片设计模糊了它们是信标链的ORU这样一个事实。如果将重点从分布式处理转向有序的数据可用性层，就变得一目了然了。
如上图所示，验证者集起到以下4种作用：验证并执行信标链对分片所提供的数据进行抽样验证组成分片委员会提交关于无效状态转换的欺诈证明我们已经作了两个假设：i)数据具有可用性，ii）区块链会从最近一个具有数据可用性的区块开始进行分叉。则要么人们可以构建欺诈证明，要么系统将缺乏数据可用性归咎于签署该区块的分片委员会，并回滚状态转换。从定义上来说，ETH2.0是一种ORU
这时，考虑到我们之前对ORU的定义，我们应该能够证明分片实际上就是rollup：1.所有交易数据都提交到链上分片区块数据被集中到数据可用性层上，在一定概率上会由全网进行验证。2.状态根被提交到链上分片委员会为包含在信标链区块中的分片状态根提供证明。3.状态根被假定为有效的信标链在没有进行额外验证的情况下，假定分片委员会的证明是有效的4.一些节点负责验证ORU的状态转换分片委员会验证分片的状态转换。5.有一个可以撤销无效状态转换的链上欺诈证明执行器信标链支持分片状态转换欺诈证明。解构ETH2.0
既然我们已经解释了ETH2.0和ORU系统之间不可思议的相似性，我们能够如何利用这一信息来更好地理解整个系统的设计？让我们通过ORU系统的角度来探索ETH2.0的一些设计决定：数据吞吐量
在当前设计中，系统的数据吞吐量与分片机制紧密耦合。这里可以采用的一种方法是，将数据可用性检查视为协议中的头等公民。这样可以对数据层进行独立优化，执行层也可以更细的粒度控制硬件要求。例如，ETH2.0可以提供64个数据中心和一个在信标链上的ORU合约，以此代替分片链。ORU合约可以让rollup决定领导者选举机制，它们想要将数据发送到多少个数据中心上，以及它们是否想与其它rollup绑定。使用的数据中心越多，验证rollup所需的硬件要求就越高。严格来说，上述系统是当前分片设计的超集。除了由协议定义的64个分片之外，还会有其它具有自己特征的rollup构建在安全数据层上，并且独立于协议分片。回滚最小化
在简单的ORU中，当选的领导者有权提交无效状态转换。虽然这不会影响系统的安全性，因为无效状态转换是可以通过欺诈证明撤销的，但这确实会破坏rollup的进程。单独来看，这种破坏对作恶者来说通常是不划算的。然而，在ETH2.0中，跨分片通信让这个问题变得特别棘手。处于slotN的分片预期自己可以获得其它分片在slotN-1时的状态。假设分片Si提交了一个无效的状态转换，除了单方面发起回滚之外没有其它合理的方法来撤销该状态对分片Sj的负面影响。为避免灾难性事件，必须有适当的机制来防止这类回滚。其中最明显的两个机制是分片委员会和托管比特检查。正如“从数学角度证明分片的安全性”一节中所述，即使考虑到各种攻击向量，贿赂分片委员会中2/3以上成员的概率也很低。托管比特可以确保诚实的验证者不会因为懒惰而被签署无效的状态转换。如果我们认为这些机制的目的是防止无效状态转换，而非维护系统安全，就能选择既有实用价值，又能实现相同效果的参数。例如，将分片委员会的规模减少到64人，随机组成恶意委员会的概率依然低至3.1×10-8。但是从网络和签名聚合的角度来看，这样能够极大减轻负担。以rollup为中心的以太坊路线图
本文最初撰写于斯坦福区块链大会2020期间。那时，我开始充分领会到ETH2.0和ORU之间的相似性。在看过Vitalik的文章后，我决定发布这篇文章，来表示对以太坊将来采用以rollup为中心的扩容方案的支持。但是，如本文所述，“以rollup为中心”的扩容方案没有让我们偏离方向，而是一个超集。我们在分片设计中遇到的问题与我们在整合跨rollup通信时遇到的问题是同构的。这就意味着，已经开展的大部分工作都可以继续进行，不会被中断。以rollup为中心的路线图会降低分片执行所必需的协议复杂性。这使得我们能够不断迭代类似分片的复杂的rollup机制。这样可以让更多开发者为不同的rollup格式做贡献，让现有核心开发者和研究者可以专注于构建一个健壮的数据可用性层。可以说，通往功能完善的ETH2.0的道路从未如此清晰。如果你对文中所述内容感兴趣，想要进行深入讨论，请在推特上联系我@lightclients。我也在帮助各种有影响力的项目寻找优秀的研究者和工程师。如果你需要帮助，请私信我。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。