Gwyneth：技术设计

Gwyneth: 技术设计

Gwyneth

作者：Brecht。感谢 Cecilia 和 Dani 的评论。

在本文中，我们旨在更详细地解释 Gwyneth 的工作原理，或者至少是 Gwyneth 可能的工作原理，因为 Gwyneth 仍在大量开发中。如需不太技术化的介绍，请参阅 Gwyneth 介绍 文章。如需更深入的解释，请参阅 设计文档（尽管此文档经常过时！）。

让我们首先再次列出核心属性/功能，然后从那里开始。

1. 基本设置

2. 同步可组合性

   • L2 <> L2
   • L2 <> L1

3. Booster rollup

4. 实时多证明器

5. 基于预确认

我们还提供了一些关于实用性的更多细节：

A. 区块提议和证明

B. 价值捕获

C. 基础设施

D. 与其他（基于）rollup 的互操作性

E. 改进 L1 同步可组合性的暂定 EIP 想法

1. 基本设置

最基本层面的 Gwyneth 是以太坊的水平扩展解决方案。 Gwyneth 是一个由多个相同的以太坊等效 L2 组成的网络，具有一些额外的功能，可以轻松地进行跨链调用。 这样，开发人员仍然可以轻松地使事情看起来像一条单一链。 每个 L2 的功能是为 Gwyneth 网络增加额外的并行处理和存储容量。 这使得单个 L2 的硬件要求保持较低水平，而整个网络的吞吐量在理论上没有任何限制。

在本文的其余部分中，当我们谈论 L2 时，我们指的是 Gwyneth 网络中的其中一个 L2。

2. 同步可组合性

所有 Gwyneth L2 都可以同步直接访问彼此。 如果 L1 提议者支持，他们也可以同步访问 L1。 我们所说的“访问”是指读取和写入所有状态，就好像它们是同一链的一部分一样。 从用户的角度来看，这看起来就像交易在一条链上运行。 用户创建一个交易并像往常一样支付费用。 gas 价格随着交易的当前部分运行所在的特定 L2 而变化。

L2 <> L2

我们通过一个新的 precompile 引入 L2 同步可组合性，该 precompile 称为 XCALLOPTIONS。 这个 precompile 允许智能合约定义第一个以下 (DELEGATE)CALL 的目标链。 该 precompile 将执行环境切换到特定链的状态，包括 basefee。

对于一个无状态的证明器来说，要证明这种行为，所需的输入是所有被访问链的状态承诺。 我们使用 Merkle Proof 验证不同的链状态，并在验证后更新状态。 那么输出就是更新后的状态承诺。

对于构建者来说，要执行这些跨链交易，需要知道每个链的最新状态。 用户将访问的链指定为交易的一部分，这会告知构建者所需的链状态。 如果使用了未指定的链，交易将回滚，但用户仍然需要支付已执行部分的费用。 这可以防止对构建者的 DOS 攻击，因为他们必须模拟每个交易才能知道所需的链状态。

可扩展性

如果对于构建者来说，Gwyneth 看起来像一条由多条链组成的单一链，那么它如何提高可扩展性呢？ 尽管 Gwyneth 包含多个 L2，节点可以同步 L1 旁边的任意 L2 列表，而不是同步 Gwyneth 的全部状态。

由于每个 L2 都可以独立同步，因此构建者可以轻松挑选和匹配他们想要同步的链，从而选择可以为其构建区块的链。 我们假设构建者是有经验的行为者，他们拥有必要的硬件来对他们选择的链进行排序。

一个节点可以独立同步每个 L2，因为每个 L2 的数据可用性都由 L1 保证。 当一个节点同步时，跨链执行通过证明来验证，因此它可以信任跨链调用的输出并推进 EVM 执行。 具体来说，我们发布调用的 CALLDATA 和相应的 RETURNDATA。 当调用导致状态变化时，会从 CALLDATA 生成目标 L2 的新交易并将其插入区块。

我们可以仅为节点发布状态增量，或者发布跨链交易的完整主体。 前一种方法的缺点是透明度较低，尽管它可以节省数据可用性成本。 目前，我们计划仅使用第一种方法。

L2 <> L1

L2 构建者需要与当前的插槽 L1 构建者是同一个实体，才能同步地组合两条链。 如果不是这种情况，我们需要执行预确认来保证预期的 L1 状态。 为了验证 L2 跨链读取和写入 L1，我们需要 L2 区块有效性证明与 L2 提议交易一起包含在 L1 区块中的预期位置。

鉴于目前正在为预确认构建的基础设施，这种类型的可组合性应该很快就能实现。 然而，L1 验证器的选择加入率和经济激励措施对于这个系统的可用性至关重要。 目前还不清楚生态系统将如何发展。

对于实现，我们使用相同的 XCALLOPTIONS precompile 从 L2 调用到 L1。

3. Booster 功能

Booster rollups 是一种 rollup，它执行交易，就好像它们是在 L1 上执行的一样，可以访问所有 L1 状态，但它们也有自己的存储。 这样，执行和存储都在 L2 上扩展，L1 环境作为一个共享的基础。 换句话说，每个 L2 都是 L1 的反映，其中 L2 通过分片交易的执行和存储，直接扩展了 L1 上部署的所有应用程序的区块空间。

水平可扩展性

Gwyneth 的一部分起源于 booster rollups。 Booster 功能允许更容易的水平可扩展性，同时减少碎片化。 在任何 L2 上访问 L1 状态的成本与访问本地 L2 状态的成本相同。

为了防止碎片化，使用 L1 作为全局状态来存储大多数 Dapp 是有效的，因为 L1 在设计上始终可用于跨链读取。 如果部署了一个新的 L2，可以直接访问和使用 L1 上的现有合约，这意味着 L2 用户可以例如使用 Uniswap 的 L1 部署在 L2 上进行交易，而无需额外的设置。

随着不同 L2 上的活动增加，由于 EIP-1559，拥塞可能会触发基本费用增加，从而导致用户费用增加。 一般来说，活动会被激励发生在基本费用较低的 L2 上，因此当需要额外容量时，可以部署额外的 L2。 Dapp 可以根据其用例和限制选择其策略。

一个应用程序可以通过在所有 L2 上并行化其状态和执行来支持完全扩展。 智能合约可以部署到 L1 一次，然后 Dapp 的功能可以通过对 L1 实例进行 DELEGATECALL，在每个链上并行发生。 仅在进行跨链调用时才会引入同步点。 一个跨越不同 Gwyneth L2 的可并行化 Dapp 可以从这种设置中获得显著的好处。 例如，部署在 L1 上的 Uniswap 池可以允许用户通过 DELEGATECALL 与 L2 上的交易同时进行，并在不同的 L2 上具有多个池的状态。 由于池是独立的，Uniswap 可以从并行执行中受益。 用户还可以使用跨链调用来与不同链上的池进行交互。

对于本质上不可并行化的用例，例如，一个部署在 L1 上的单一 AMM 池，将其状态存储在一个 Gwyneth L2 上仍然允许姊妹 L2 进行跨链调用以进行交换。 然而，这可能会在这个 L2 上造成拥塞，从而增加费用。 因此，Dapp 被激励遵循一种可并行化的设计模式以节省费用。 也可以将智能合约部署到特定的 L2，避免昂贵的 L1 部署。

同步可组合性优化

Booster 功能可以使与 L1 的同步可组合性更有效。 因为可以直接从 L2 访问 L1，所以不需要在 L1 上执行智能合约。 取而代之的是，使用 L2 区块空间，使得 L1 执行和状态读取与 L2 上一样便宜。 可以通过仅在 L1 上应用最终状态增量来部分优化 L1 状态写入，但这需要在智能合约上实现一个额外的接口。

然而，使用状态增量的更新引入了额外的安全风险。 L1 智能合约的安全性现在将取决于 Gwyneth 区块是否被正确证明。 现在跳过了导致 L1 智能合约中状态更新的原始逻辑。

4. 实时多证明器

为了实现与 L1 的同步可组合性，我们需要实时（或接近实时）的证明。 L2 区块需要立即验证，以便 L1 可以信任在 L2 上完成的工作。 这对我们可以直接依赖的证明器类型提出了限制，因为我们不能有任何安全延迟。

可用的证明器类型有：

• TEEs（例如 SGX、TDX、nitro enclave、AMD SEV）： 证明可以以接近本地的性能完成，生成这些证明的硬件通常广泛可用，并且这些类型的证明生成成本较低。 缺点是它们有额外的信任假设，并且已经被不同程度地利用。

• AVS（或多重签名）： 也是提供本地证明性能的一个选项。 可以选择一大组去中心化的验证器或一小组受信任的验证器，并且权益质押确保了密码经济安全性。 然而，这个选项本身并不理想，因为 L1 没有直接验证状态转换。

• ZKPs： 理论上是理想的证明方式，因为没有添加额外的信任假设（除了密码学）。 然而，证明生成的延迟目前太高，无法用于实时用例。 ZK 仍在快速发展，预计在未来一两年内可以使用 ZK 进行实时证明。

目前，我们将使用 TEE 和 AVS/多重签名证明器。 ZK 证明仍然可以通过使用它们来证明其他证明器是错误的，从而间接加强我们协议的安全性。 更多内容见下文。

安全性

多证明器

每个支持的证明器的验证器将存储在验证器注册表智能合约中。 Gwyneth 强制执行一组每个提议区块所需的证明。 这组证明将随着证明器的可用性而变化（例如，随着时间的推移会添加更多证明器，或者删除一些有缺陷的证明器）。 最初，Gwyneth 将要求每个区块提供以下证明：

• 需要为所有支持的 TEE 提供证明：单个 TEE 的安全性是不够的，因为有时会发现特定 TEE 的漏洞。 但是，许多不同类型的 TEE 证明提供了非常强大的安全性，因为不太可能同时发现所有 TEE 的漏洞。 链上 TEE 证明验证成本很低，因此验证多个 TEE 不会显著增加成本。

• 某种 AVS/多重签名证明，以具有一个完全不同的安全配置文件的额外级别。 需要具有非常不同的安全假设的证明类型使得单个实体很难同时破坏所有证明器。

证明器取消智能合约

除此之外，我们将有一个外部异步路径来加强 Gwyneth 的安全性。 当可以证明证明器有缺陷时，智能合约允许任何人无需许可地禁用验证器注册表智能合约中的证明。 任何人都可以通过两种方式证明证明器应该被禁用：

• 如果可以使用同一个证明器来证明两个不同的事物，则应该禁用该证明器。

• 如果一个证明器被证明与另外两个证明器（它们对单个输出达成一致）证明的输出不同，则应该禁用该证明器。

该合约独立于主要的 Gwyneth 智能合约发挥作用，它只具有禁用验证器注册表中的证明器的能力。 任何有效的输入和输出对都可以用于证明证明器有缺陷，该系统不限于仅能够证明属于 Gwyneth 链的区块。

该智能合约将作为 链上漏洞赏金发挥作用。 将自动向任何可以证明证明器有缺陷的人提供奖励。 当披露允许证明器被利用的根本问题时，将提供额外的奖励。

由于异步性质以及可以使用任何输入的事实，因此不需要实时证明，因此 ZK 证明仍然可以在此设置中使用。 这允许我们在 ZK 证明逐渐变得越来越快时使用 ZK 证明，并且可以将它们添加到所需的一种证明类型中。

桥接额度

虽然 Gwyneth 没有传统的桥接（跨链功能内置于协议中），但合约可以具有额度，限制在某个时间段内可以提取到 L1 的价值量。 这限制了在某些安全机制启动之前可以窃取多少资金。

质押的验证器

质押的验证器可以提供经济安全性。 如果验证器签署无效的状态转换，则可以被罚没。 罚没的金额可以用于完全（质押金额 ≥ 漏洞利用期间的桥接额度）或部分帮助恢复损失的资金（以防价值在某种程度上是可替代的）。

5. 基于预确认

Gwyneth 将支持 基于预确认。 由于 Gwyneth 增加了额外的功能，因此将适用一些额外的限制：

• 如果交易触及多个 L2 链，则预确认者需要能够为交易所需的所有链构建区块。

• 如果交易需要与 L1 交互，则只有当预确认者也是当前区块持续时间内（直接或间接）的 L1 提议者时，才能给出预确认。

在所有其他情况下，预确认的工作方式与普通Based Rollup 的情况相同。 随着越来越多的 L1 验证器选择加入成为 Gwyneth 的预确认者，用户将能够获得这些更棘手场景的预确认。

A. 区块提议和证明

所有区块都将发布到以太坊。 以太坊将用于数据可用性、对区块进行排序以及使用有效性证明来验证状态转换的正确性。 发布区块的主要方法是调用一个智能合约函数，该函数包含一个或多个超级区块的数据。 超级区块是一个包含 Gwyneth 中任何 L2 的交易的区块。 有两种可能的情况：

• 如果一个区块不需要任何 L1 写入，则不需要立即证明这些区块，因为 L1 此时不需要结果状态。 但是，需要信任为跨链调用发布的额外数据的同步节点无法在没有有效性证明的情况下这样做。

• 如果一个区块确实需要 L1 写入，则需要证明直到提议区块为止的所有区块，以便在正确的已知 L2 状态下完成 L1 工作。 提议者有责任提供这些证明以及区块。

区块数据是 Gwyneth 智能合约上的函数调用的一部分（以 calldata 或 blob 的形式）。 L2 链将 从 L1 区块派生，因此除了可能在需要时在提议时证明区块（包括与 L1 同步组合性所需的可能 L1 调用）之外，不需要其他 L1 工作来推进链，这使得它在 L1 成本方面非常有效。

为了证明区块，我们遍历从最后一个已证明的 L1 区块到指定的 L1 区块号的所有 L1 区块。 在此范围内，我们遍历 L1 区块并检测所有 L2 区块提议，递归地独立验证每个 L2 区块。 这允许 L2 区块在传入时被证明，然后将它们聚合为正在证明的整个 L1 区块窗口。（请注意，此设置有一个限制，因为提议区块所在的 L1 区块在 EVM 中尚不可用，在某些情况下可以解决此问题。 更多内容见下文）。

费用支付

费用支付很简单：

• 提议者收集所有交易费用/MEV（当然，实际上可以使用 PBS 风格的区块构建）。

• 提议者必须证明其提议的所有区块。 假设证明生成成本很低（对于某些证明类型来说已经是这种情况），我们可以允许提议者不证明其区块。 这是有效的，因为这允许聚合更多的区块验证。 或者，如果证明区块所需的链下工作仍然很大，我们仍然可以强制提议者证明其所有区块。 通过预确认，预确认者已经被质押，如果可以证明在其区块范围结束时没有完成此操作，我们可以简单地罚没提议者。

L2 上可用的最新 L1 状态

到目前为止，我们已经掩盖了我们实际上如何获得 L2 上的最新 L1 状态。 在 EVM 中，只有前 256 个区块的 blockhash 可用，因此我们可以轻松地将它们插入 L2 并知道最新状态。 但是，如果我们真的需要最新的 L1 状态（我们使用 L1 进行同步组合性时需要），我们需要在提议 L2 区块时准确地获取 L1 状态。 然而，EVM 不会公开有关当前区块中任何更改的任何信息。 所以我们有几个选择：

• 如果我们不需要写入 L1，我们不需要能够立即提供 L2 区块的证明。 这允许我们毫无问题地在接下来的区块之一中重新执行 L1 区块，使用 EVM 中可用的 L1 区块哈希。

• 如果我们只需要写入 L1 并且不需要任何读取，那么也没有问题，因为我们不需要访问最新的 L1 状态，我们可以使用前一个 L1 区块的 L1 blockhash。

• 如果我们确实需要 L1 读取和写入：

  • 在 L1 上完成状态读取，并且将状态传递到 L2 中。 当然，这可能比在 L2 上进行读取要昂贵得多，并且获取所需状态可能很棘手（可能受到只有特定地址才能访问某些状态的保护，而 Gwyneth 合约可能不具有）。
  • 区块提议只能发生在 L1 区块的第一个交易中，但这大大限制了同步组合性可能发生的位置（并且区块顶部的区块空间可能更昂贵）。
  • EVM 扩展了额外的 opcode，这些 opcode 公开了有关当前点之前的 L1 区块的信息。 有关更多信息，请参见下面的 E 节。

B. 价值捕获

协议价值捕获

Gwyneth 协议可以通过几种方式捕获网络创造的一些价值。 虽然这在短期内可能不是很重要，但从长远来看，Gwyneth 需要具有可持续性。

• 通过捕获 basefee 来收集拥塞 MEV： 这需要在不同的 L2 上产生一定程度的拥塞，但如果存在严重的拥塞，则可能意味着 Gwyneth 或 Dapp 本身没有尽可能地扩展。 如果没有拥塞，协议也可以强制执行一个小的 basefee 以仍然捕获一些价值（尽管在这种情况下，这将是一种税）。

• 出售提议者权利： 我们可以潜在地出售 Gwyneth 区块提议插槽，类似于执行票，无论是对单个 L1 区块中的所有 Gwyneth L2 进行排序的权利，还是每个 Gwyneth L2 的单独提议权利。

Dapp 价值捕获

我们必须小心，任何价值捕获都不会影响可组合性，反而会（重新）引入碎片化。 理想情况下，任何构建者始终有权（或可以购买权利）为任何 L2 构建区块。 我们认为，Dapp 价值捕获应该在 Dapp 级别完成，而这些 Dapp 的排序应该保持无需许可。 Gwyneth 上的自排序 Dapp 将会降低抗审查性和可组合性。

C. 基础设施

对于围绕核心协议的必要基础设施（区块浏览器、RPC 节点、区块构建器等）存在两个理想的属性：

• 该网络最终是 自给自足的，这意味着网络创造的价值能够以某种方式支付这些服务的费用。
• 用户可以依赖 统一的体验。 围绕链的用户体验也不应该碎片化。

最终，围绕 Gwyneth 的生态系统有可能能够有机地维持下去。 但是，在协议中捕获价值，然后再用它来帮助实现这一点，似乎仍然是启动事情的重要手段。 如果捕获的价值超过了需要的价值，则可以将其重新分配给用户。

D. 与其他（基于）rollup 的互操作性

待定

E. 改进 L1 同步可组合性的暂定 EIP 想法

为了在 L1 区块中证明某些内容，我们需要对区块内的当前 L1 状态进行内省。 目前，EVM 公开了最后 256 个可以执行此操作的 blockhash，但是，它没有公开有关当前 L1 区块中的状态的任何信息。 当然，我们可以直接在 L1 上直接读取状态，但这既效率低下又不切实际。 下面我们解释了一种如何扩展 EVM 以最小的方式实现此目的的方法。

我们可以将当前的 tx trie 公开给 EVM。 虽然在区块中执行交易，但会增量更新 tx trie（而不是仅在最后一次为区块头一次性创建所有交易）并将此根公开给 EVM。 这样，我们可以查询之前的所有交易（包括当前 tx），因此可以计算出当前 tx 之前最新的 L1 状态证明。

然后，为了使其完全准确，EVM 还可以公开当前的 opcode 计数器（当前 tx 中已执行了多少个 opcode），以准确地知道在何处停止执行当前 tx。

这种方法只需要对 EVM 进行最小的更改，并且节点中没有任何昂贵的运营，这应该使这些 opcode 非常便宜。

也可以通过其他方式实现此目的，因为此方法也不是理想的。 欢迎任何评论/想法！

链接

你可以在 X 上关注 Gwyneth 以获取更新 @gwyneth_taiko，并在 GitHub 上关注进度。

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