内嵌原生L2和无状态区块构建-分片

通过内嵌原生 L2 和无状态区块构建来扩展以太坊

简介

以太坊的可扩展性之路一直在探索 Layer 2 (L2) 解决方案，以提高吞吐量，同时保持去中心化。一个有希望的方向——建立在之前诸如Based Rollup的研究之上——是内嵌原生 L2 的概念。在这篇文章中，我认为我们可以通过创建深度集成到以太坊协议中的 L2 系统来扩展以太坊，共享其验证器集合以并行处理交易。这并不是一个新颖的发明，而是对现有想法的改进，利用通过诸如 Orbit 等概念未参与 Layer 1 (L1) 职责的验证器来水平扩展吞吐量。通过在 L1 和多个 L2 之间循环验证器，我们可以解锁额外的真正原生的区块空间，增加交易容量，并引入本地费用市场——所有这些都无需要求使用越来越重的节点硬件。每个 L2 都将具有与 L1 相同的 gas 限制和其他配置。我不认为这些内嵌原生 L2 能够与非内嵌 L2 具有高度竞争力。 显然，后者能够更有效地垂直扩展吞吐量，并创建可以容忍不同程度审查的社区，而内嵌原生 rollup 则无法做到这一点。

我认为，如果没有可行的内嵌回退方案，将会导致吞吐量大幅降低，我们就无法安全地外包区块构建。将区块构建外包给复杂的参与者将不可避免地产生对它们的依赖。随着 MEV 随着时间的推移而减少（应用程序有动力自行捕获 MEV），区块构建者的收入越来越少。随着吞吐量的增加，构建区块的成本变得越来越高。因此，盈利能力取决于复杂的、专有的知识，这大大增加了新参与者在区块构建方面的竞争力。当拍卖是赢者通吃时，没有竞争力的构建者无法生存，最终会导致高度中心化（双头垄断或垄断对我来说并不奇怪）。你可以在这里阅读一些关于我的观点的帖子：捍卫本地区块构建。

本文将探讨可用的设计空间，重点关注权衡以及无状态区块构建对于水平扩展的关键作用，这使我们能够保持本地区块构建，并保持以太坊的可分叉性。

核心概念：具有共享验证器的内嵌原生 L2

内嵌原生 L2 将以太坊的验证器集合扩展到 L1 职责之外。目前，31/32 的验证器对于以太坊来说并不是真正有用的。理想情况下，我们希望有一个系统可以确保尽可能多地生产性地利用网络。我们可以将未在 L1 上进行提议或证明的验证器（例如，由于在诸如 Orbit 等系统中的轮换）转移到 L2，形成委员会来处理交易排序和区块生产。例如，我们可以拥有每个 L2 由 96 个验证器组成的委员会，其中 16 个验证器分配给 FOCIL/提议职责，其余的进行证明。就像 L1 一样，我们希望 L2 的大多数 stake 来证明新区块，以便其被接受和最终确定。每个 slot 我们可以从他们当前所在的 L2 轮换 4 个验证器（我说的是好像所有验证器都有 32 个 eth 的 stake，但我知道情况并非如此，验证器选择等方面存在一些复杂性，但我认为这是我们可以解决的问题，并且希望现在保持简单），并将它们转换回 L1 或另一个 L2，确保持续的生产力。

• 共享安全性：这些 L2 通过零知识 (zk) 证明继承了以太坊的安全性，由相同的共识机制验证，并具有几乎等同的审查阻力保证（目前基本上没有 L2 具有这种保证）。

• 水平扩展：添加更多 L2 可以提高吞吐量，而无需垂直扩展硬件，这与传统的节点升级形成对比。

这利用了这样一个事实，即在诸如 Orbit 等系统中，大约 80% 的验证器 stake 可能在 L1 上处于活动状态，留下大约 20% 可用于 L2，从而放大了原生区块空间。

无状态区块构建的必要性

为了使这一目标实现，无状态区块构建 是理想的。验证器无法存储完整的状态，因为即使在 L1 上，存储需求也在持续增长，更不用说包括所有 L2 了。因此：

• 工作原理：用户或状态提供者提供带有交易的见证（状态数据 + 证明）。验证器使用 Verkle 树来验证这些针对状态根的紧凑证明（约 150 字节），从而构建不依赖于本地状态的区块。你或许可以进行某些优化，从而允许将 ZkEVM 执行证明作为有效交易提交，并且 gas 成本更低，这些证明与其他状态变化不冲突。

• 重要原因：无状态性保持了较低的硬件要求，从而实现了 L1 和 L2 职责之间的快速转换。它是水平扩展的支柱，确保验证器可以处理任何 L2，而无需同步大量数据集。

如果没有无状态性，内嵌 L2 的优势——灵活性、可扩展性和广泛参与——将在不切实际的存储和同步时间需求下崩溃。

设计空间中的权衡

以下是一些需要权衡的实际问题：平衡验证器角色、状态管理和带宽，以使此方案可行。

1. 验证器委员会规模 vs. 吞吐量

• 权衡：较小的委员会（例如，几十个验证器）简化了协调和转换，但存在安全风险。较大的委员会（例如，数百个验证器）以开销为代价提高了去中心化程度。

• 示例转变：由于大约 20% 的验证器可以从 L1 中解放出来，一个 100 个验证器的委员会可能支持许多 L2，而每个 L2 200 个验证器会使该数字减半，但会增强弹性。

• 影响：更多的 L2 意味着更高的吞吐量，但委员会规模决定了有多少 L2 可以安全地并行运行。不仅如此，在一定程度上，L1 Gas 限制也限制了实际可以支持的 L2 数量。

2. 验证器存储的 Verkle 树（或等效树）级别

我们可以设置一个要求，即验证器存储 Verkle 树的根和所有中间节点，达到一定级别，而不仅仅是根。这使他们可以更有效地验证见证，而无需存储整个状态，还可以让我们减少为每个交易传输大型见证的带宽开销。存储根节点和上一个 slot 的树的差异可以帮助避免使本可以有效的 txs 失效，这些 txs 引用了先前的 slots 状态，但在 slot 中包含得太晚，会被其他修改其证明路径的交易使失效。

• 权衡：存储较高的 Verkle 树级别（例如，从根到中间节点）会减少见证大小，但会增加内存。不存储则可以保持验证器的精简，但会膨胀交易数据。

• 示例转变：对于 256 的分支因子，存储 0-3 级我认为大约为 ~1.7 GB，约有 40 亿个叶节点。如果分支为 512，则大约为 ~13 GB，但为我们提供了大约 ~690 亿个叶节点（我认为，对于 L1 和每个具有良好互操作性的 L2 来说，叶节点应该足够长一段时间）。

• 影响：存储更多级别可以抵消带宽增加，从而使吞吐量在不扼杀网络的情况下进行扩展。

3. 带宽 vs. 吞吐量收益

• 权衡：无状态性会增加每笔交易的带宽（见证），但内嵌 L2 会成倍增加原生区块空间，可能会使此成本相形见绌。

• 主要优势：如果切换到无状态区块构建会使带宽需求增加 5 倍，但使我们能够支持 500 个内嵌原生 L2，那么这可能是值得的。这还在每个 L2 中创建本地费用市场，因此，如果我们允许应用程序迁移，我们可能会看到经常交互的应用程序在 L2 内彼此相邻结算，以避免互操作开销，而大型应用程序会迁移到使用率较低的 L2，以避免因其他应用程序的需求而推高用户费用。所有这些都说明，从长远来看，我们可能会看到实现接近最佳的吞吐量。

4. 验证器转换速度

• 权衡：最小值状态(仅根)存储在内存中供验证器使用，可以实现近乎瞬时的转换，但需要更大的见证。存储中间级别会减慢转换速度，以节省 tx 的带宽。我们可以包含其他内容，例如所有智能合约代码预计都将由验证器存储，并且需要在他们能够参与 L2 职责（证明除外）之前进行同步。 即合约存储槽或 eoa 帐户等预计将具有用户提供的见证（状态提供者当然也可以向用户提供该数据，理想情况下，我们以 eLTS 作为备份——有关更多详细信息，请参阅我的 eth 研究帖子）。这意味着用户只需要为存储槽或帐户余额提供一些见证，并且所有验证器都能够始终执行所有交易。对此，还有一些替代方案，我们只在内存中保留一组活跃的合约，其余的则需要为它们提供见证。这篇最近的文章更详细地讨论了这一点（关于无状态性的协议设计）。

• 示例转变：仅根转换大约需要 1 秒钟，而 ~1.7 GB 的同步可能需要 ~5 分钟，具体取决于验证器的网络速度要求。

• 影响：更快的转换可以最大限度地提高验证器的效用，而更慢的转换可以优化交易效率。

为什么这很重要：吞吐量及其他

• 原生区块空间：内嵌 L2 大大增加了原生区块空间，从而使以太坊能够水平扩展。这是与其他依赖外部验证器的 L2 的关键区别。

• 带宽偏移：是的，无状态见证会增加带宽，但理想情况下，通过 L2 增加的原生区块空间可以远远超过这一增幅。

• 本地费用市场：借助内嵌 L2，我们可以创建本地费用市场，从而防止对一个应用程序的需求影响其他地方的简单支付。内嵌 L2 可以获得免费的 blobspace 分配，或者具有各种其他费用机制和/或发行机制，以找到这种工作方式的合理平衡。

结论

显然，要实现这一愿景需要大量工作，并且在某些权衡之间取得平衡方面存在许多未解决的问题。我认为，由无状态区块构建提供支持的内嵌原生 L2 提供了解锁以太坊水平扩展的最佳途径，并可以维持其长期的抗审查性。控制分叉选择具有严重的后果。当我们从实际角度限制谁有能力构建链时，我们就会放弃分叉选择，并使自己容易受到强大参与者的影响，从而损害所有人的利益。像 orbit 这样的 SSF 方法使任何人都可以参与对分叉进行投票，这是我们前进的最佳途径。它还使我们能够利用未参与 L1 职责的验证器来获得潜在的大规模吞吐量增益。我们_可以_在保持节点可访问性的同时提高容量，并且_不会_失去以太坊的去中心化精神。

• 将吞吐量与本地构建分离
• 关于无状态性的协议设计

• 原文链接： ethresear.ch/t/enshrined...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～