最佳汇总指南：以下是您应该知道的一切

注：原文作者是Paradigm基金研究者Georgios Konstantopoulos。 以太坊 生态系统所面临的**挑战之一，是在严格的资源约束（例如CPU、带宽、内存以及磁盘空间）下具有低延迟和高吞吐量。而一个系统的去中心化程度，取决于网络中最弱节点验证系统规则的能力。我们认为，可以在低资源硬件上运行的高性能协议才是“可扩展”的。在本文中，我们将深入探讨现代“Layer 2解决方案”的原理，其相应的安全模以及它们如何解决 以太坊 的可扩展性问题。这篇文章的目标读者是有好奇心的个人，他们有兴趣了解更多有关先进的 以太坊 扩容技术，以及有动机构建和架构此类系统的人群。

有三个因素会影响在去中心化网络（例如 比特币 和 以太坊 ）中运行节点的资源需求：而性能则是通过两种方式衡量： 比特币 和 以太坊 等新兴加密网络的理想特性是去中心化。但是，是什么让网络变得去中心化呢？另一个需要的特性是就是可扩展性：能够将吞吐量和延迟超线性地扩展到运行系统的成本。这一定义很好，但没有包含“信任”。因此，我们指定了“去中心化可扩展性”：也就是说，可以在不显著增加系统信任假设的情况下实现可伸缩性。放大来看， 以太坊 的runtime环境是 以太坊 虚拟机（EVM）。通过EVM运行的交易以不同的成本执行各种操作（例如，存储操作的成本高于添加操作的成本）。交易中的计算单位称为“gas”，系统参数化为每个区块最多处理1250万 Gas，其中平均每12.5秒生成一个交易区块。因此， 以太坊 的延迟时间约为12.5秒，吞吐量为每秒100万 gas。你可能会遇到这样一个问题：每秒100万gas，你能够用来做什么？请注意，随着交易执行复杂度的增加，系统的吞吐量会降低到非常低的值。还有改进的空间！解决方案1：使用中介我们可以利用一个可信赖的第三方来促进我们的所有交易。这样，我们就能够得到非常高的吞吐量以及可能的二级延迟，这太棒了！这不会改变任何系统范围的参数，但我们会选择进入一个由第三方单方面设置的信任模。他们可能会选择审查我们，甚至扣押我们的资产，而这是不可取的。解决方案二：把区块做大，缩短区块之间的区间时间我们可以通过缩短两个区块之间的时间来减少延迟，并且可以通过增加区块gas限制来增加吞吐量。但这种变化将使节点运营的成本变高，从而阻止个人运行节点（例如EOS、Solana、Ripple等就是使用的这种方法）。我们可以发现，解决方案1中增加了信任要求，而解决方案2则是增加了成本。这使得这两种方案，都无法成为可扩展性的好选择。

在这部分内容中，我们假设读者了解了哈希和merkle树的概念。根据我们目前学到的知识，让我们模拟一些苏格拉底式的对话，目的是发现一个协议，它可以提高 以太坊 的有效吞吐量，而不会增加用户和节点运营者的负担。因此，我们希望在不改变信任和成本假设的情况下扩展以太坊。我们该怎么办？Q： 你的意思是有一种交易方式可以在不影响状态的情况下降低资源成本吗？Q： 所以我们要让你序列器计算链外所有内容，只发布Merkle root实现扩展？Q： 好吧，一旦你加入，序列器这将保证你的转帐是便宜的。存取款是如何运作的？
Q： 我们确信用户需要一个Merkle证书来提取他们的资金。用户如何获取数据来构造Merkle证书？Q： 但如果序列器暂时或**不可用？Q： 所以如果序列器网上，但拒绝提供梅克尔证明我的数据，我可以通过以太坊下载吗？Q： 所以我还是不明白你怎么能在以太坊上存储一些东西而不执行它呢？不是每笔交易都要通过EVM吗？Q： 我们能相信吗序列器如果他们发布了一个无效的状态转换呢？Q： 等等！正如您之前所说，如果a）增加了成本，或者b）引入了新的信任假设，您就无法真正实现可伸缩性。在你描述的计划中，我们假设总有人举报欺诈？Q： 我同意有人将运行验证器，因为许多参与者都对这个新解决方案的成功感兴趣。但可以肯定的是，这还取决于实际成本。所以运行验证器序列器对资源的需求是什么？问：就是这样的吗？

Layer 2 扩容基于以下事实：我们试图最小化链上执行交易的数量。我们使用欺诈证明来取消可能发生的任何无效状态转换。由于欺诈证明是链上交易，因此我们也希望尽量减少在 以太坊 上发布的欺诈证明的数量。在理想的情况下，欺诈永远不会发生，因此欺诈证明也就不需要发布。我们通过引入忠诚保证来消除欺诈行为。为了使用户能够建立序列器，他们必须先在 以太坊 上发布一份保证金，如果欺诈行为被证实，则这些资金会被没收。为了激励个人寻找欺诈行为，序列器的保证金会被削减，并分发给找到欺诈行为的验证者。在设计欺诈证明的激励措施时，需要调整两个参数：在我们看来，这两个参数都没有正确的静态值，也许10 ETH保证金和1天的争议期就足够了。也许1 ETH保证金和7天争议期也是可以的。真正的答案是，这取决于作为验证者的动机（取决于运行验证器的成本）以及发布欺诈证明的容易程度（这取决于L1的拥堵程度）。这两项都应该是可调整的，无论是手动还是自动。值得一提的是，EIP1559为 以太坊 引入了一个新的BASEFEE操作码，可用于估计链上拥堵情况，并因此以编程方式调整争议期的持续时间。这一惩罚机制的正确实施是至关重要的，否则将在实践过程中被利用。下面就是一个无**常工作的简单实现示例：Alice可以通过“抢先交易”发起攻击，即广播与Bob相同的交易，但支付更高的gas费用，这导致Alice的交易先于Bob的交易执行。这意味着Alice可始终尝试以最小的成本（仅 以太坊 交易费）进行欺诈。解决这个问题的方法是简单的：不将全部保证金授予争议挑战方，而是燃烧掉其中的X%。在上面的例子中，如果我们燃烧掉50%，Alice将收到0.5 ETH的回报，这将是一个足够的抑制措施，导致她不会尝试第二次作弊。当然，这种烧制机制会降低用户运行验证器的动机（因为奖励变少了），因此燃烧后的保证金奖励，应该足够多以吸引到验证者。

现在，我们已经完成了乐观汇总的基础构建块，让我们探讨并解决针对该机制的一些批评问题。上面我们提到，长期的争议期对安全而言是有很大好处的，但这里似乎有一个内在的权衡问题：长时间的争议期不利于采用，因为任何想要从中提取资金的用户都需要等待很长的时间，比如说7天。而较短的争议期，尽管对用户来说可以有更流畅的体验，但这样就需要冒着欺诈发生的风险，没有争议会被及时包含进来。我们不认为这是一个问题，由于这一潜在的大规模退市延迟，我们预计做市商将介入并提供更快的退市服务。这是可能的，因为验证L2状态的人，可以正确判断取款是否属于欺诈，从而以小折扣购买他们的服务。下面就是一个例子：参与者：步骤：（2）Bob的验证器提醒他这笔交易是无效的，Bob对该交易引起的状态转换提出异议，取消了交易并赢得了允许恶意交易发生的序列器保证金。Alice要么很老实，立即拿出她的资金，要么不老实，然后受到惩罚。如果有这项服务的需求，我们预计向这些做市商支付的费用，会随着时间的推移而压缩，最终使该程序对用户完全不可见。这个功能最重要的含义是，它可以与L1合约实现组合，而不必等待整个争议期。请注意，这项技术首先在“简单快速取款”中进行了介绍。在“乐观汇总近乎零成本攻击场景”中，有人会认为，矿工的激励机制如此之大，以至于序列器与 以太坊 矿工合谋审查任何争议交易都是微不足道的。考虑到对安全性的依赖，这对任何乐观系统来说都是致命的。我们不同意这个观点，我们认为，诚实的一方将总是愿意贿赂矿工，甚至要比恶意方更多。此外，矿工每次通过帮助恶意一方获胜而背离“诚实”行为，都要付出额外的代价。这种行为会破坏 以太坊 的价值，这可能会增加矿工参与 以太坊 的成本。事实上，学术文献中已经研究过这种情况，证明了“这种反击的威胁导致了一个子博弈完美均衡，在这种均衡中，不会有人先去进行攻击。”我们要感谢Hasu提供的论文证据。Ed Felten为验证者的困境撰写了一些出色的分析和解决方法，我们总结如下：听起来这很重要，而且几乎是自相矛盾的！假设奖励的大小是固定的，更多的验证者会减少单个验证者的预期支付。此外，更多的验证者似乎缩小了奖励大小，因为欺诈发生较少，这进一步加剧了问题。在后续的分析中，Felten还提供了一种解决验证者困境的方法。我想站在相反的立场说这件事，验证者的困境并不像批评者说的那么重要。在实践当中，作为验证者存在着与金钱无关的激励。例如，如果你是一个建立在rollup之上的大应用商，或者你是代币持有者，如果系统发生故障，那么你的应用将无法工作，或者你的代币价值将会变少。除此之外，快速取款的需求为做市商验证者的存在创造了动力（如上一节所述），而与欺诈行为无关。为了更具体地说明这一点， 比特币 没有提供存储整个区块链历史记录或将你的本地数据提供给对等节点的激励，但是人们还是会无私地这样做。即使在真空中运行验证器与激励机制不兼容，它也能保证系统的安全，这对于投资于系统成功的实体来说是最重要的。因此，我们认为没有必要设计机制来解决乐观Layer2系统中验证者的困境。

与文章的标题一致，我们分析了 以太坊 在2021年最重要的技术方案之一：乐观汇总（Optimistic Rollup）。总结一下这种方案的好处：OR作为一种 以太坊 扩容方案，它继承了 以太坊 主网的安全性、可组合性以及开发人员的护城河，同时提高了性能，并且没有对 以太坊 用户的成本或信任要求产生实质性影响。我们探索了使乐观汇总起作用的激励结构，并对常见批评进行了回应。作为补充阅读，我们推荐大家阅读Vitalik的《Rollup和信任模的不完整指南》这篇文章，我们还建议大家研究下OR的近亲ZK Rollup，我们在StarkWare的朋友就是构建的这类方案。**，还有其他方法可以实现去中心化的可扩展性，例如分片和状态通道，它们也都有各自的优缺点。我们要感谢Hasu，Patrick McCorry，Liam Horne，Ben Jones，Kobi Gurkan和Dave White为本文提供的宝贵反馈意见。