以太坊生态的最大挑战之一是如何在资源有限（例如，CPU、带宽、内存、磁盘空间）的前提下实现低延迟和高吞吐量。
系统的去中心化程度取决于网络中最弱的节点验证系统规则的能力。可以在低资源硬件上运行的高性能协议被称为 “可伸缩的（scalable）”。
在本文中，我们将深入探究现代 “Layer 2 方案” 的原则，这些方案的安全模型，及其在解决以太坊可扩展性问题上采取的策略。
本文的预设读者是那些对密码学技术感兴趣的人。如果你想要深入了解以太坊前沿可扩展性技术，以及如何设计并构建这类系统，千万不要错过这篇文章。
在本文中，重要的关键词和概念都已加粗，因为这些都是你在了解密码学货币技术时经常遇到的术语。本文涉及的概念比较复杂。如果你在阅读中遇到困惑，请不要放弃，守得云开见月明。
在比特币和以太坊等去中心化网络中，运行节点的资源要求主要有三种：
带宽：下载并广播区块链相关数据的成本。
计算：在脚本或智能合约中运行计算的成本。
存储：出于索引目的存储事务数据的成本，以及为了继续处理新的事务块而存储 “状态” 的成本 。
影响性能的因素有：
吞吐量：系统每秒可处理事务（transaction）的数量
延迟：处理一笔事务所需的时间
比特币和以太坊等新兴密码学货币网络的理想特性是去中心化。那么问题来了，网络是如何实现去中心化的呢？
低信任：有了这个特性，任何人都能自主验证比特币的总供应量永远不会超过 2100 万个，及其持有的比特币不是伪造的。运行节点软件的人可以独立计算最新状态，并验证出块流程是否遵循所有规则。
低成本：如果节点软件的运行成本很高，人们就会选择依靠可信第三方来验证状态。成本高意味着信任要求也高，这是我们极力想要避免的。
另一个理想特性是可扩展性：吞吐量（和延迟）能够随运行节点的成本增加呈超线性增长（减少）。这个定义很棒，但是并未指明与 “信任” 惯性。因此，我们另外定义了“去中心化可扩展性”：在几乎不会提高系统信任假设的情况下实现可扩展性。
以太坊的运行时环境是 EVM（以太坊虚拟机）。在 EVM 中，事务在执行不同操作时需要承担的成本不同（例如，存储操作的成本大于添加操作）。事务的计算单位叫做 “gas”。在以太坊系统中，每个区块的 gas 上限被设为 1250 万 gas。平均每 12.5 秒可以挖出一个区块。由此可得，以太坊的延迟是 12.5 秒，吞吐量是每秒 100 万 gas。
你可能会问一个问题：每秒 100 万 gas 能做什么？
每秒可完成大约 47 笔 “简单转账” 事务。所谓 “简单转账” 事务，就是指 “A 向 B 转了一笔 ETH” 这样最基础的事务。每笔事务需要 2.1 万 gas。
每秒可完成大约 16 笔 ERC20 代币转账。这类事务相比 ETH 转账事务需要执行更多存储操作，因此每笔事务需要约 6 万 gas。
每秒可完成大约 10 笔 Uniswap 资产交换操作。代币对事务的平均成本约为 10.2 万 gas。
……选择你感兴趣的事务，用 100 万 gas 除以其 gas消耗量（1250 万/12.5/gas）。
请注意，随着事务的执行复杂度提高，系统的吞吐量急剧下降。还有很大的提升空间！
方案 1：使用中间方
我们可以使用大家都信任的第三方来达成所有事务。这样一来，我们就可以得到很高的吞吐量，并将延迟降至亚秒级。简直太棒了！这样也不会改变任何系统参数，但是我们需要参与一个由第三方单方面设置的信任模型。第三方可能会对我们进行审查，甚至夺走我们的资产，这就不妙了。
方案 2：扩大区块容量并提高出块频率
我们可以通过减少出块时间来降低时延，我们还可以通过提高区块 gas 上限来提高吞吐量。这一改变可能会导致节点运营成本提高，从而阻碍人们运行节点（就像 EOS、Solana 和 Ripple 那样）。
方案 1 会提高对信任的需求，方案 2 会增加成本。因此，二者都不是理想的可扩展性方案。
接下来会涉及一些关于哈希函数和默克尔树的知识。
了解了这么多之后，我们来模拟一段苏格拉底式对话，看看能否找到一个既能提高以太坊的实际吞吐量，又不会增加用户和节点运营者负担的协议。
问：我们想要提高以太坊的可扩展性，又不想改变其信任和成本假设。我们该怎么做？
答：可以尝试降低现有操作的成本（参见上述三类操作）。不过，说起来容易做起来难，我们先来看一下以太坊的架构：
以太坊网络中的每个节点目前都存储并执行来自用户的每笔事务。事务是在 EVM 中执行的，并与 EVM 的状态（例如，合约存储项、余额等）进行交互（这一成本很高）。常见的智能合约优化技术主要聚焦于在最大程度上减少与状态交互的次数，但是它们起到的作用很有限。
问：是否存在不与状态交互就能达成交互的方法，以此降低资源成本？
答：在极端情况下，我们是否可以将所有执行都转移到链下，并将数据保存在链上？我们可以引入第三方，即，排序者（sequencer），来做到这点。排序者负责在本地存储并执行用户提交的事务。为了保持系统的活性（liveness），排序者会定期将它们收到的事务的默克尔根以及状态根提交到以太坊上。这个思路是正确的，因为O(N) 笔链下事务只需在以太坊上存储 O(1) 的状态数据。
问：通过使用排序者执行链下计算，只将默克尔根发布到链上，我们就能增强以太坊的可扩展性了是吗？
答：是的。
问：也就是说，只要我们选择了排序者，就能大幅降低转账成本。那用户怎么存钱进去呢？
答：你在以太坊区块链上把钱存进某个合约，就能加入这样的系统了。排序者会将相应的存款记在你的名下。用户只需要发送一笔事务称 “我想要取出 3 ETH，我当前的账户余额大于 3 ETH，这是证明”，就可以取出资金。即使 L1 上没有该用户的实际状态，该用户也可以提供默克尔证明并引用排序者发布的状态根来证明自己在当前状态下拥有足够多的资金。
问：我们已经确定用户需要提供默克尔证明才能取出资金。用户如何获得构建默克尔证明所需的数据？
答：用户可以要求排序者来提供数据！
问：如果总是联系不上排序者，该怎么办？
答：这种情况可能是因为排序者作恶，或因技术问题掉线，这会导致性能退化（甚至盗窃）。因此，我们必须要求排序者将完整的事务数据提交到链上，只用于存储，不用于执行。这里的目的是实现数据可得性。由于所有数据都永久存储在以太坊上，即使一个排序者倒下了，新的排序者也可以从以太坊上重新找回所有与 Layer2 相关的数据，重新构建最新的 L2 状态，并接替上一个排序者的工作。
问：如果排序者在线却拒绝向我提供默克尔证明数据，我可以从以太坊上下载这些数据对吗？
答：对的，你可以自己同步一个以太坊节点，也可以从众多节点托管服务提供商中选择一家。
问：我还有个不明白的地方……如何将数据存储在以太坊上却不执行它？难道不是每笔事务都要经过 EVM 执行的吗？
答：假设你提交了 10 笔 A 向 B 转 ETH 的事务。执行每笔事务需要执行以下操作：增加 A 的 nonce，减少 A 的余额，并增加 B 的余额。这需要多次写入和读取世界状态。你可以将所有事务的编码发送至智能合约的publish(bytes _transactions) public { }函数。请注意，这个函数的函数体是空的！也就是说，如此发布的事务数据是不会被解释、执行或访问的。它只存储在区块链的历史日志中（写入日志的成本很低）。
问：我们能信任排序者吗？如果排序者发布非法的状态转换怎么办？
答：无论排序者何时发布一批状态转换，都会有 “争议期”。在 “争议期” 内，任何人都可以发布 “欺诈证明” 来证明其中某个状态转换是无效的。欺诈证明就是通过重放导致链上发生状态转换的事务，并将得到的状态根与排序者发布的状态根进行对比。如果两个状态根不同，则欺诈证明成功，状态转换被取消。跟在该无效状态转换后面的状态转换也会被取消。争议期一过，就无法再对事务提出争议，即，事务被敲定。
问：等等！你之前明明说过，只要（a）会增加成本，或（b）引入新的信任假设，就是不可行的可扩展性方案。你这里提到的方案不是要假设时刻有人会报告欺诈吗？
答：没错。我们假设有一组被称为 “验证者” 的实体负责监控欺诈行为。如果 Layer 1 和 Layer 2 之间出现状态不匹配的情况，验证者就会发布欺诈证明。我们还假设验证者能够在争议期内将其欺诈证明发布到以太坊区块链上。我们认为，验证者的存在是一个弱假设。想象一下，如果有数万名用户采用该方案，你只需要 1 个人来担任验证者的角色。听起来不是那么不切实际吧！另外，改变以太坊的信任模型，或增加运行以太坊节点的成本是一个强假设，会做出我们不想要的改变。这就是我们的中心化可扩展性定义中的 “几乎不会改变底层系统的设想” 的意思。
问：我同意会有人担任验证者的角色，因为这个新的解决方案牵涉到很多人的利益。但是，具体怎样还得取决于实际成本。那么，运行验证者和排序者需要消耗多少资源？
答：排序者和验证者必须运行一个以太坊全节点（而非归档节点），以及一个 L2 全节点来生成 L2 状态。验证者运行创建欺诈证明的软件，排序者运行打包并发布用户事务的软件。
问：就这些吗？
答：没错！恭喜！你已经重新发现了?Optimistic Rollup ，这个 2019 至 2021 年最有前景的可扩展性方案。我可没有在说大话，这是以太坊社区经过多年研究得出的成果。也就是你在这段简短的对话中听到的。
：我们建议读者阅读 Vitalik 的雄文《区块链资源定价》。
：请注意，存储 “状态（账户余额、合约字节码和 nonce）” 的成本比存储原始事务数据的更高。
：Optimistic Rollup 就是 “optimistic contract（乐观合约）” 和 “on chain data availability（链上数据可得性，又称 “数据汇总”）” 的合体。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。