Vitalik：The Surge阶段以太坊协议应该怎么发展

按：本文为以太坊创始人Vitalik近期发表的“以太坊协议的未来发展”系列文章的第二部分“Possible futures for the Ethereum protocol, part 2: The Surge”，第一部分见此前报道“以太坊PoS还有哪些可以改进”。由邓通编译，以下为第二部分全文：

一开始，以太坊的路线图中有两种扩展策略。

其中之一是“分片（sharding）”：每个节点只需要验证和存储一小部分交易，而不是验证和存储链中的所有交易。这也是任何其他点对点网络（例如 BitTorrent）的工作原理，因此我们当然可以使区块链以同样的方式工作。

另一个是 2 层协议：网络将位于以太坊之上，使它们能够充分受益于其安全性，同时使大多数数据和计算远离主链。 “2 层协议”指的是 2015 年的状态通道、2017 年的 Plasma，以及 2019 年的 Rollups。Rollup 比状态通道或 Plasma 更强大，但它们需要大量的链上数据带宽。

幸运的是，到 2019 年，分片研究已经解决了大规模验证“数据可用性”的问题。结果，两条路径融合了，我们得到了以Rollup为中心的路线图，这仍然是以太坊今天的扩展策略。

The Surge，2023 年路线图版。

以Rollup为中心的路线图提出了一个简单的分工：以太坊 L1 专注于成为一个强大且去中心化的基础层，而 L2 则承担帮助生态系统扩展的任务。这是社会各处反复出现的模式：法院系统（L1）并不是为了超快速和高效，而是为了保护合同和财产权，而企业家（L2）则需要在此基础上进行构建坚固的基础层并将人类带到（隐喻和字面上的）火星。

今年，以Rollup为中心的路线图取得了重要成功：以太坊 L1 数据带宽通过 EIP-4844 blob 大幅增加，并且多个 EVM Rollup现在处于第一阶段。分片的非常异构和多元化的实现，其中每个 L2 充当具有自己的内部规则和逻辑的“碎片”现在已成为现实。但正如我们所看到的，走这条路有其自身的一些独特的挑战。因此，现在我们的任务是完成以 Rollup 为中心的路线图，并解决这些问题，同时保留使以太坊 L1 与众不同的稳健性和去中心化性。

Surge：关键目标

L1+L2 上 100,000+ TPS

保持 L1 的去中心化和稳健性

至少一些 L2 完全继承了以太坊的核心属性（去信任、开放、抗审查）

L2 之间的最大互操作性。以太坊应该感觉像是一个生态系统，而不是 34 个不同的区块链。

可扩展性的三难困境

可扩展性不可能三角是 2017 年提出的一个想法，它认为区块链的三个属性之间存在紧张关系：去中心化（更具体地说：运行节点的低成本）、可扩展性（更具体地说：处理大量交易）和安全性（更具体地说：攻击者需要破坏整个网络中的大部分节点才能使单个交易失败）。

值得注意的是，三难困境不是定理，介绍三难困境的帖子没有附带数学证明。它给出了一个启发式的数学论证：如果一个去中心化友好的节点（例如消费者笔记本电脑）每秒可以验证 N 个交易，并且您有一个每秒处理 k*N 个交易的链，那么（i）每个交易只能被看到1/k 的节点，这意味着攻击者只需破坏几个节点即可推动不良交易，或者 (ii) 您的节点将变得强大并且您的链不是去中心化的。这篇文章的目的从来不是为了表明打破三难困境是不可能的；相反，它是为了表明打破三难困境是困难的——它需要以某种方式跳出论证所暗示的框框进行思考。

多年来，一些高性能链经常声称他们解决了三难困境，而没有在基础架构层面采取任何巧妙的措施，通常是通过使用软件工程技巧来优化节点。这总是具有误导性，并且在此类链中运行节点总是比在以太坊中困难得多。这篇文章探讨了为什么会出现这种情况的许多微妙之处（以及为什么 L1 客户端软件工程无法单独扩展以太坊本身）。

然而，数据可用性采样（DAS）和 SNARK 的结合确实解决了三难困境：它允许客户端验证一定数量的数据是否可用，以及是否正确执行了一定数量的计算步骤，同时仅下载该数据的一小部分并且运行的计算量要小得多。 SNARK 是不可信的。数据可用性采样具有微妙的少数 N 信任模型，但它保留了不可扩展链所具有的基本属性，即使 51% 攻击也无法迫使网络接受坏块。

解决三难困境的另一种方法是 Plasma 架构，它使用巧妙的技术以激励兼容的方式将监视数据可用性的责任推给用户。早在 2017-2019 年，当我们扩展计算所需的只是欺诈证明时，Plasma 的安全功能非常有限，但 SNARK 的主流化使得 Plasma 架构比以前更适用于更广泛的用例。

DAS的进一步进展

我们要解决什么问题？

截至 2024 年 3 月 13 日，当 Dencun 升级上线时，以太坊区块链每 12 秒时段有 3 个约 125 kB 的“blob”，或者每个时段约 375 kB 的数据可用带宽。假设交易数据直接发布到链上，ERC20传输约为180字节，因此以太坊上rollups的最大TPS为：

375000 / 12 / 180 = 173.6 TPS

如果我们添加以太坊的 calldata（理论最大值：每个插槽 3000 万个 Gas / 每字节 16 个 Gas = 每个插槽 1,875,000 字节），这将变为 607 TPS。对于 PeerDAS，计划将 blob 计数目标增加到 8-16，这将为我们提供 463-926 TPS 的 calldata。

这相对于以太坊 L1 来说是一个重大的提升，但这还不够。我们想要更多的可扩展性。我们的中期目标是每个插槽 16 MB，如果与汇数据压缩的改进相结合，将为我们提供约 58,000 TPS。

PeerDAS是什么以及它是如何工作的？

PeerDAS 是“一维采样”的相对简单的实现。以太坊中的每个 blob 都是 253 位素数域上的 4096 次多项式。我们广播多项式的“份额”，其中每个份额由从总共 8192 个坐标集中获取的相邻 16 个坐标处的 16 个评估组成。 8192 次评估中的任意 4096 次（使用当前建议的参数：128 个可能样本中的任意 64 个）都可以恢复该 blob。

PeerDAS 的工作原理是让每个客户端侦听少量子网，其中第 i 个子网广播任何 Blob 的第 i 个样本，并另外通过询问全球 p2p 网络中的对等方来请求其他子网上所需的 Blob （谁会监听不同的子网）。更保守的版本 SubnetDAS 仅使用子网机制，没有额外的请求对等层。当前的建议是参与权益证明的节点使用 SubnetDAS，其他节点（即“客户端”）使用 PeerDAS。

理论上，我们可以将 1D 采样扩展得相当远：如果我们将 blob 计数最大值增加到 256（因此，目标为 128），那么我们将达到 16 MB 目标，而数据可用性采样只需每个节点花费 16 个样本 * 128 blobs * 每个 blob 每个样本 512 字节 = 每个槽 1 MB 的数据带宽。这刚好在我们的容忍范围之内：它是可行的，但这意味着带宽受限的客户端无法采样。我们可以通过减少 blob 数量和增加 blob 大小来对此进行优化，但这会使重建更加昂贵。

因此最终我们想要更进一步，进行 2D 采样，它不仅通过在blob内进行随机采样，而且还在blob之间进行随机采样。 KZG 承诺的线性属性用于通过对相同信息进行冗余编码的新“虚拟 blob”列表来“扩展”区块中的 blob 集。

2D sampling.来源：a16z 

至关重要的是，计算承诺的扩展不需要 blob，因此该方案从根本上对分布式块构建是友好的。实际构建区块的节点只需要有 Blob KZG 承诺，并且自己可以依赖 DAS 来验证 Blob 的可用性。 1D DAS 本质上对分布式区块构建也很友好。

与现有研究有哪些联系？

介绍数据可用性的原始文章（2018）：https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding

后续论文：https://arxiv.org/abs/1809.09044

DAS 的解释者帖子，范式：https://www.paradigm.xyz/2022/08/das

KZG 承诺的 2D 可用性：https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081

ethresear.ch 上的 PeerDAS： https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541 和论文：https://eprint.iacr.org/2024/1362

EIP-7594：https://eips.ethereum.org/EIPS/eip-7594

ethresear.ch 上的 SubnetDAS：https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169

2D 采样中可恢复性的细微差别：https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256

还需要做什么，需要权衡什么？

下一步是完成 PeerDAS 的实施和推出。从那时起，不断增加 PeerDAS 上的 blob 计数是一项渐进的工作，同时仔细观察网络并改进软件以确保安全。与此同时，我们希望开展更多关于 PeerDAS 和其他版本的 DAS 形式化及其与分叉选择规则安全性等问题的交互方面的学术工作。

展望未来，我们需要做更多的工作来找出 2D DAS 的理想版本并证明其安全特性。我们还希望最终从 KZG 迁移到抗量子、无需可信设置的替代方案。目前，我们不知道有哪些候选者对分布式区块构建友好。即使使用递归 STARK 来生成重建行和列的有效性证明的昂贵“强力”技术也不够，因为从技术上讲，STARK 的哈希值大小为 O(log(n) * log(log(n)) (与 STIR），实际上 STARK 几乎和整个斑点一样大。

从长远来看，我认为现实的路径是：

• 理想的 2D DAS 工具；

• 坚持使用 1D DAS，为了简单性和robustness而牺牲采样带宽效率并接受较低的数据上限；

• （硬枢轴）放弃 DA，并完全拥抱 Plasma 作为我们关注的主要第 2 层架构。

我们可以通过权衡范围来看待这些：

请注意，即使我们决定直接在 L1 上扩展执行，这种选择仍然存在。这是因为如果 L1 要处理大量 TPS，L1 块将变得非常大，客户将需要一种有效的方法来验证它们是否正确，因此我们必须使用支持Rollup的相同技术（ZK-EVM 和DAS）和 L1。

它如何与路线图的其他部分交互？

如果实施数据压缩（见下文），对 2D DAS 的需求会有所减少，或者至少会延迟，如果 Plasma 得到广泛使用，则对 2D DAS 的需求会进一步减少。 DAS 也对分布式区块构建协议和机制提出了挑战：虽然 DAS 理论上对分布式重构很友好，但在实践中需要与包含列表提案及其周围的分叉选择机制相结合。

数据压缩（Data compression）

我们要解决什么问题？

Rollup 中的每笔交易都会占用大量链上数据空间：ERC20 传输大约需要 180 个字节。即使采用理想的数据可用性采样，这也会限制第 2 层协议的可扩展性。每个插槽 16 MB，我们得到：

16000000 / 12 / 180 = 7407 TPS

如果除了解决分子之外，我们还可以解决分母，并使Rollup中的每个交易在链上占用更少的字节怎么办？

它是什么以及它是如何工作的？

我认为最好的解释是两年前的这张图：

最简单的增益就是零字节压缩：用两个表示零字节数量的字节替换每个长的零字节序列。更进一步，我们利用交易的特定属性：

• 签名聚合 - 我们从 ECDSA 签名切换到 BLS 签名，BLS 签名具有可以将许多签名组合在一起形成单个签名的属性，该签名可以证明所有原始签名的有效性。 L1 没有考虑这一点，因为验证的计算成本（即使使用聚合）也更高，但在像 L2 这样的数据稀缺环境中，它们可以说是有意义的。 ERC-4337 的聚合功能提供了实现此目的的一种途径。

• 用指针替换地址 - 如果以前使用过地址，我们可以用指向历史位置的 4 字节指针替换 20 字节地址。这是实现最大收益所必需的，尽管需要付出努力才能实现，因为它需要（至少一部分）区块链的历史才能有效地成为国家的一部分。

• 交易值的自定义序列化 - 大多数交易值只有很少的数字，例如。 0.25 ETH 表示为 250,000,000,000,000,000 wei。 Gas max-basefees 和优先级费用的工作原理类似。因此，我们可以使用自定义十进制浮点格式，甚至是特别常见值的字典，非常紧凑地表示大多数货币值。

与现有研究有哪些联系？

来自sequence.xyz的探索：https://sequence.xyz/blog/compressing-calldata

针对 L2 的 Calldata 优化合约，来自 ScopeLift：https://github.com/ScopeLift/l2-optimizoooors

另一种策略 - 基于有效性证明的Rollup（又名 ZKRollup）发布状态差异而不是交易：https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975 上的-l2-数据足迹

BLS 钱包 - 通过 ERC-4337 实现 BLS 聚合：https://github.com/getwax/bls-wallet

还需要做什么，需要权衡什么？

剩下要做的主要工作就是将上述方案落到实处。主要的权衡是：

• 切换到 BLS 签名需要付出巨大的努力，并且会降低与可提高安全性的可信硬件芯片的兼容性。可以使用其他签名方案的 ZK-SNARK 包装器来替代它。

• 动态压缩（例如用指针替换地址）使客户端代码变得复杂。

• 将状态差异发布到链而不是交易会降低可审计性，并使许多软件（例如区块浏览器）无法工作。

它如何与路线图的其他部分交互？

ERC-4337 的采用，以及最终将其部分内容纳入 L2 EVM 中，可以大大加快聚合技术的部署。将 ERC-4337 的部分内容纳入 L1 可以加速其在 L2 上的部署。

广义Plasma

我们要解决什么问题？

即使使用 16 MB blob 和数据压缩，58,000 TPS 也不一定足以完全接管消费者支付、去中心化社交或其他高带宽领域，如果我们开始考虑隐私，情况就尤其如此，这可能会使可扩展性下降 3 -8x。对于大容量、低价值的应用程序，当今的一个选择是 validium，它使数据处于链下状态，并具有有趣的安全模型，操作员无法窃取用户的资金，但它们可以消失并暂时或永久冻结所有用户的资金资金。但我们可以做得更好。

它是什么以及它是如何工作的？

Plasma 是一种扩展解决方案，涉及运营商在链外发布区块，并将这些区块的 Merkle 根放在链上（与 Rollups 不同，rollups 是将整个区块放在链上）。对于每个区块，运营商向每个用户发送一个 Merkle 分支，证明该用户的资产发生了什么或没有发生什么。用户可以通过提供Merkle分支来提取资产。重要的是，该分支不必扎根于最新状态 - 因此，即使数据可用性失败，用户仍然可以通过撤回可用的最新状态来恢复其资产。如果用户提交无效分支（例如，退出他们已经发送给其他人的资产，或者运营商自己凭空创建资产），链上挑战机制可以裁定该资产正确属于谁。

Plasma Cash 链图。花费币 i 的交易被放入树中的第 i 个位置。在这个例子中，假设所有之前的树都是有效的，我们知道 Eve 目前拥有硬币 1，David 拥有硬币 4，George 拥有硬币 6。

Plasma 的早期版本只能处理支付用例，无法有效地进一步推广。然而，如果我们要求每个根都用 SNARK 进行验证，那么 Plasma 就会变得更强大。每个挑战游戏都可以大大简化，因为我们消除了操作员作弊的大多数可能路径。新的路径也开辟了，使 Plasma 技术能够扩展到更广泛的资产类别。最后，在运营商不作弊的情况下，用户可以立即提取资金，无需等待一周的挑战期。

制作 EVM Plasma链的一种方法（不是唯一方法）：使用 ZK-SNARK 构建并行 UTXO 树，反映 EVM 所做的余额变化，并定义什么是“同币”的唯一映射历史上的不同点。然后可以在此基础上构建Plasma结构。

一个重要的见解是 Plasma 系统不需要完美。即使您只能保护一部分资产（例如，即使只是过去一周没有移动的代币），您也已经大大改善了超可扩展 EVM 的现状，这是一个验证。

另一类结构是混合Plasma/rollups结构，例如 Intmax。这些结构将每个用户的非常少量的数据放在链上（例如 5 字节），通过这样做，可以获得介于Plasma和Rollup之间的属性：在 Intmax 情况下，您可以获得非常高水平的可扩展性和隐私性，即使在 16 MB 世界中，理论上容量上限也约为 16,000,000 / 12 / 5 = 266,667 TPS。

与现有研究有哪些联系？

原始 Plasma 论文：https://plasma.io/plasma-deprecated.pdf

Plasma现金：https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298

Plasma现金流： https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#-Exit

Intmax（2023）：https://eprint.iacr.org/2023/1082

还需要做什么，需要权衡什么？

剩下的主要任务是将 Plasma 系统投入生产。如上所述，“plasma 与 validium”不是二元对立：任何 validium 都可以通过将 Plasma 功能添加到退出机制中来至少提高一点点安全性能。研究部分是为了获得 EVM 的最佳属性（在信任要求、最坏情况的 L1 Gas 成本和 DoS 脆弱性方面）以及替代的特定于应用程序的结构。此外，Plasma 相对于 rollups 的概念复杂性更大，需要通过研究和构建更好的通用框架来直接解决。

使用 Plasma 设计的主要缺点是它们更多地依赖于操作员并且更难“基于”，尽管混合 Plasma/rollup 设计通常可以避免这个弱点。

它如何与路线图的其他部分交互？

Plasma 解决方案越有效，L1 拥有高性能数据可用性功能的压力就越小。将活动移至 L2 还可减少 L1 上的 MEV 压力。

成熟的L2证明系统

我们要解决什么问题？

如今，大多数Rollup实际上还不是去信任的；有一个安全理事会有能力推翻（乐观或有效性）证明系统的行为。在某些情况下，证明系统甚至根本不存在，或者即使存在也仅具有“咨询”功能。最领先的是 (i) 一些特定于应用程序的Rollup，例如 Fuel，它们是去信任的，以及 (ii) 截至撰写本文时，Optimism 和 Arbitrum，这两个完整的 EVM Rolup已经实现了部分去信任里程碑称为“第一阶段”。 Rollups 没有进一步发展的原因是担心代码中的 bug。我们需要去信任的Rollup，因此我们需要正面解决这个问题。

它是什么以及它是如何工作的？

首先，让我们回顾一下本文最初介绍的“stage”系统。还有更详细的要求，但总结如下：

• 第 0 阶段：用户必须能够运行节点并同步链。如果验证是完全可信/集中的就可以了。

• 第一阶段：必须有一个（去信任的）证明系统，确保只接受有效的交易。允许存在一个可以推翻证明系统的安全委员会，但只有 75% 的投票门槛。此外，理事会的法定人数阻止部分（即 26% 以上）必须位于构建Rollup的主要公司之外。允许使用功能较弱的升级机制（例如 DAO），但必须有足够长的延迟，以便如果批准恶意升级，用户可以在升级上线之前退出资金。

• 第二阶段：必须有一个（不信任的）证明系统来确保只接受有效的交易。仅当代码中存在可证明的错误时，才允许安理会进行干预，例如。如果两个冗余证明系统彼此不一致，或者如果一个证明系统接受同一块的两个不同的后状态根（或者在足够长的时间内不接受任何内容，例如一周）。允许升级机制，但必须有很长的延迟。

我们的目标是达到第二阶段。达到第二阶段的主要挑战是获得足够的信心，证明证明系统实际上足够值得信赖。有两种主要方法可以做到这一点：

• 形式验证：我们可以使用现代数学和计算技术来证明（乐观或有效性）证明系统只接受通过 EVM 规范的区块。这些技术已经存在了几十年，但最近的进步（例如精益 4）使它们更加实用，而人工智能辅助证明的进步可能会进一步加速这一趋势。

• 多重证明者：制作多重证明系统，并将资金投入这些证明系统和安全委员会（和/或其他具有信任假设的小工具，例如 TEE）之间的 2-of-3（或更大）多重签名。如果证明系统同意，则安理会没有权力。如果他们不同意，安理会只能选择其中之一，而不能单方面强加自己的答案。

多证明者的程式化图，结合了一个乐观证明系统、一个有效性证明系统和一个安全委员会。

与现有研究有哪些联系？

EVM K Semantics（2017年起正式验证工作）：https://github.com/runtimeverification/evm-semantics

关于多证明者想法的演示（2022）： https://www.youtube.com/watch?v=6hfVzCWT6YI

Taiko 计划使用多重证明：https://docs.taiko.xyz/core-concepts/multi-proofs/

还需要做什么，需要权衡什么？

对于形式验证来说，有很多。我们需要创建 EVM 的整个 SNARK 证明者的正式验证版本。这是一个极其复杂的项目，尽管我们已经开始了。有一个技巧可以显著简化任务：我们可以为最小虚拟机制作一个正式验证的 SNARK 证明者，例如。 RISC-V 或 Cairo，然后在该最小 VM 中编写 EVM 的实现（并正式证明其与其他一些 EVM 规范的等效性）。

对于多重证明者来说，还有两个主要的剩余部分。首先，我们需要对至少两个不同的证明系统有足够的信心，它们各自都相当安全，并且如果它们崩溃，它们会因不同且不相关的原因而崩溃（因此它们不会同时崩溃）。其次，我们需要在合并证明系统的底层逻辑中获得非常高水平的保证。这是一小段代码。有多种方法可以使其变得非常小——只需将资金存储在安全多重签名合约中，其签名者是代表个人证明系统的合约——但这需要付出高昂的链上Gas成本的代价。需要在效率和安全之间找到某种平衡。

它如何与路线图的其他部分交互？

将活动移至 L2 可减少 L1 上的 MEV 压力。

跨L2互操作性改进

我们要解决什么问题？

如今 L2 生态系统的一大挑战是用户难以操纵。此外，最简单的方法通常会重新引入信任假设：集中式桥、RPC 客户端等等。如果我们认真对待 L2 是以太坊一部分的想法，我们需要让使用 L2 生态系统感觉就像使用统一的以太坊生态系统一样。

一个病态糟糕的例子（甚至是危险的：我个人因为这里的链选择错误而损失了 100 美元）跨 L2 UX - 虽然这不是 Polymarket 的错，但跨 L2 互操作性应该是钱包和以太坊标准的责任（ERC） ） 社区。在运行良好的以太坊生态系统中，从 L1 到 L2 或从一个 L2 到另一个 L2 发送代币应该就像在同一个 L1 中发送代币一样。

它是什么以及它是如何工作的？

跨 L2 互操作性改进有很多类别。一般来说，提出这些问题的方法是注意到理论上，以Rollup为中心的以太坊与 L1 执行分片是一样的，然后询问当前的以太坊 L2 版本在实践中在哪些方面与理想的差距。以下是一些：

• 链特定地址：链（L1、Optimism、Arbitrum...）应该是地址的一部分。一旦实现，只需将地址放入“发送”字段即可实现跨 L2 发送流程，此时钱包可以在后台弄清楚如何进行发送（包括使用桥接协议）。

• 特定于链的支付请求：制作“向我发送 Z 链上 Y 类型的 X 代币”形式的消息应该是简单且标准化的。这有两个主要用例：（i）支付，无论是个人对个人还是个人对商家的服务，以及（ii）请求资金的 dapp，例如。上面的 Polymarket 例子。

• 跨链交换和 Gas 支付：应该有一个标准化的开放协议来表达跨链操作，例如“我在 Optimism 上发送 1 ETH 给在 Arbitrum 上发送 0.9999 ETH 的人”，以及“我在 Optimism 上发送 0.0001 ETH”任何人在 Arbitrum 上包含此交易”。 ERC-7683 是对前者的尝试，而 RIP-7755 是对后者的尝试，尽管两者都比这些特定用例更通用。

• 轻客户端：用户应该能够实际验证他们正在交互的链，而不仅仅是信任 RPC 提供商。 A16z 加密货币的 Helios 为以太坊本身做到了这一点，但我们需要将这种去信任性扩展到 L2。 ERC-3668（CCIP-read）是实现此目的的一种策略。

轻客户端如何更新其以太坊标头链的视图。一旦有了标头链，您就可以使用 Merkle 证明来验证任何状态对象。一旦你拥有了正确的 L1 状态对象，你就可以使用 Merkle 证明（如果你想检查预先确认，还可能使用签名）来验证 L2 上的任何状态对象。Helios 已经做到了前者。扩展到后者是标准化的挑战。

• 密钥库钱包：如今，如果您想更新控制智能合约钱包的密钥，则必须在该钱包所在的所有 N 个链上执行此操作。密钥库钱包是一种技术，允许密钥存在于一个位置（无论是在 L1 上，还是稍后可能在 L2 上），然后从任何拥有钱包副本的 L2 中读取。这意味着更新只需要发生一次。为了提高效率，密钥库钱包要求 L2 有一种标准化的方式来无成本地读取 L1；对此的两个建议是 L1SLOAD 和 REMOTESTATICCALL。

密钥库钱包如何工作的程式化图表。

• 更激进的“共享代币桥”想法：想象一个所有 L2 都是有效性证明Rollup的世界，每个插槽都致力于以太坊。即使在这个世界上，“本地”将资产从一个 L2 转移到另一个 L2 也需要提取和存款，这需要支付大量的 L1 Gas。解决这个问题的一种方法是创建一个共享的最小Rollup，其唯一功能是维护哪个 L2 拥有多少种类型的代币的余额，并允许通过一系列交叉来集体更新这些余额。由任意 L2 发起的 L2 发送操作。这将允许跨 L2 传输发生，而无需每次传输支付 L1 Gas，也不需要基于流动性提供者的技术（如 ERC-7683）。

• 同步可组合性：允许在特定 L2 和 L1 之间或多个 L2 之间发生同步调用。这可能有助于提高 defi 协议的财务效率。前者可以在没有任何跨 L2 协调的情况下完成；后者需要共享测序。基于Rollup自动对所有这些技术友好。

与现有研究有哪些联系？

链特定地址：ERC-3770：https://eips.ethereum.org/EIPS/eip-3770

ERC-7683：https://eips.ethereum.org/EIPS/eip-7683

RIP-7755：https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md

滚动密钥库钱包设计：https://hackmd.io/@haichen/keystore

Helios: https://github.com/a16z/helios

ERC-3668（有时称为 CCIP-read）：https://eips.ethereum.org/EIPS/eip-3668

Justin Drake 提出的“基于（共享）预确认”的提案：https://ethresear.ch/t/based-preconfirmations/17353

L1SLOAD (RIP-7728):  https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388

乐观中的远程调用：https://github.com/ethereum-optimism/ecosystem-contributions/issues/76

AggLayer，其中包括共享令牌桥的想法：https://github.com/AggLayer

还需要做什么，需要权衡什么？

上面的许多例子都面临着何时标准化以及标准化哪些层的标准困境。如果标准化太早，您可能会面临劣质解决方案的风险。如果标准化得太晚，就有可能造成不必要的碎片化。在某些情况下，既有性能较弱但更容易实施的短期解决方案，也有“最终正确”但需要相当长的时间才能实现的长期解决方案。

本节的独特之处在于，这些任务不仅仅是技术问题：它们也是（也许主要是！）社会问题。他们需要 L2 和钱包以及 L1 进行合作。我们成功处理这个问题的能力是对我们作为一个社区团结在一起的能力的考验。

它如何与路线图的其他部分交互？

这些建议中的大多数都是“更高层”的结构，因此不会对 L1 考虑产生太大影响。一个例外是共享排序，它对 MEV 影响很大。

扩展 L1 上的执行

我们要解决什么问题？

如果 L2 变得非常可扩展且成功，但 L1 仍然只能处理非常少量的交易，那么以太坊可能会出现许多风险：

• ETH 资产的经济状况变得更加危险，进而影响网络的长期安全。

• 许多L2受益于与L1上高度发达的金融生态系统的紧密联系，如果这个生态系统大大削弱，成为L2（而不是独立的L1）的动力就会减弱。

• L2 需要很长时间才能拥有与 L1 完全相同的安全保证。

• 如果 L2 发生故障（例如，由于恶意操作或消失的运营商），用户仍然需要通过 L1 才能恢复其资产。因此，L1 需要足够强大，至少能够偶尔真正处理 L2 的高度复杂和混乱的结束。

出于这些原因，继续扩展 L1 本身并确保它能够继续适应越来越多的用途是很有价值的。

它是什么以及它是如何工作的？

最简单的扩展方法就是简单地增加 Gas 限制。然而，这存在中心化 L1 的风险，从而削弱了使以太坊 L1 如此强大的另一个重要属性：其作为强大基础层的可信度。关于简单 Gas 限制增加到什么程度是可持续的一直存在争论，并且这也会根据其他技术的实施而发生变化，以使更大的区块更容易验证（例如历史到期、无状态、L1 EVM 有效性证明）。另一个需要不断改进的重要事情就是以太坊客户端软件的效率，它今天比五年前更加优化。有效的 L1 Gas 限制增加策略将涉及加速这些验证技术。

另一种扩展策略涉及识别特定的功能和计算类型，这些功能和计算类型可以在不损害网络分散性或其安全属性的情况下变得更便宜。这方面的例子包括：

• EOF - 一种新的 EVM 字节码格式，对静态分析更加友好，可以实现更快的实现。考虑到这些效率，可以给予 EOF 字节码较低的 Gas 成本。

• 多维 Gas 定价 - 建立单独的基本费用以及计算、数据和存储的限制可以增加以太坊 L1 的平均容量，而不增加其最大容量（从而产生新的安全风险）。

• 降低特定操作码和预编译的 Gas 成本 - 从历史上看，我们已经对某些定价过低的操作进行了几轮 Gas 成本的增加，以避免拒绝服务攻击。我们已经做得较少但可以做更多的事情，那就是降低价格过高的运营的Gas 成本。例如，加法比乘法便宜得多，但 ADD 和 MUL 操作码的成本目前相同。我们可以使 ADD 更便宜，甚至更简单的操作码（例如 PUSH）更便宜。 EOF整体来说比较多。

• EVM-MAX 和 SIMD：EVM-MAX（“模块化算术扩展”）是一项提议，允许更高效的原生大数模块化数学作为 EVM 的单独模块。由 EVM-MAX 计算计算出的值只能由其他 EVM-MAX 操作码访问，除非故意导出；这允许有更大的空间以优化的格式存储这些值。 SIMD（“单指令多数据”）是一种允许在值数组上高效执行相同指令的提议。两者一起可以与 EVM 一起创建一个强大的协处理器，可用于更有效地实现加密操作。这对于隐私协议和 L2 证明系统特别有用，因此它将有助于 L1 和 L2 扩展。

这些改进将在以后关于 Splurge 的文章中更详细地讨论。

最后，第三种策略是原生Rollup（或“内置Rollup，enshrined rollups”）：本质上，创建并行运行的 EVM 的许多副本，从而形成一个与Rollup可以提供的模型等效的模型，但更原生地集成到协议中。

与现有研究有哪些联系？

Polynya 的以太坊 L1 扩容路线图：https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ

多维Gas定价：https://vitalik.eth.limo/general/2024/05/09/multidim.html

EIP-7706：https://eips.ethereum.org/EIPS/eip-7706

EOF：https://evmobjectformat.org/

EVM-MAX：https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168

SIMD：https://eips.ethereum.org/EIPS/eip-616

原生Rollup：https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE

采访 Max Resnick 关于扩展 L1 的价值：https://x.com/BanklessHQ/status/1831319419739361321

Justin Drake 关于使用 SNARK 和原生Rollup进行扩展：https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/

还需要做什么，需要权衡什么？

L1 扩展有三种策略，可以单独或并行执行：

• 改进技术（例如客户端代码、无状态客户端、历史过期）使 L1 更容易验证，然后提高 Gas 限制

• 降低特定操作的成本，在不增加最坏情况风险的情况下提高平均容量

• 原生Rollup（即“创建 EVM 的 N 个并行副本”，尽管可能为开发人员在部署副本的参数方面提供了很大的灵活性）

值得理解的是，这些是具有不同权衡的不同技术。例如，原生Rollup在可组合性方面与常规Rollup有许多相同的弱点：您无法发送单个事务来跨多个事务同步执行操作，就像您可以在同一 L1（或 L2）上处理合约一样。提高 Gas 限制会剥夺通过使 L1 更易于验证而可以实现的其他好处，例如增加运行验证节点的用户比例以及增加单独的抵押者。使 EVM 中的特定操作更便宜（具体取决于操作方式）可能会增加 EVM 的总体复杂性。

任何 L1 扩展路线图都需要回答的一个大问题是：L1 和 L2 的最终愿景是什么？显然，所有事情都在 L1 上进行是荒谬的：潜在的用例每秒有数十万个事务，这将使 L1 完全无法验证（除非我们采用原生Rollup路线）。但我们确实需要一些指导原则，这样我们才能确保我们不会造成这样的情况：我们将 Gas 限制提高 10 倍，严重损害以太坊 L1 的去中心化，并发现我们只是进入了一个世界，而不是99% 的活动都在 L2 上，90% 的活动都在 L2 上，因此结果看起来几乎相同，除了以太坊 L1 的特殊性的大部分不可逆转的损失。

一种关于 L1 和 L2 之间“分工”的提议观点

它如何与路线图的其他部分交互？

让更多用户进入 L1 意味着不仅要改善规模，还要改善 L1 的其他方面。这意味着更多的 MEV 将保留在 L1 上（而不是仅仅成为 L2 的问题），因此更迫切需要明确地处理它。它极大地增加了 L1 上快速时隙时间的价值。它还在很大程度上依赖于 L1（“The Verge”）的验证是否顺利。

特别感谢 Justin Drake、Francesco、Hsiao-wei Wang、@antonttc 和 Georgios Konstantopoulos