Gwyneth 技术设计

作者：Brecht。感谢 Cecilia 和 Dani 的审阅。

本文旨在更详细地解释 Gwyneth 的工作原理，或者至少是 Gwyneth 仍在大力开发中可能的工作方式。如需更通俗的介绍，请参阅 Gwyneth 介绍 文章。如需更深入的解释，请参阅 设计文档（不过该文档常常过时！）。

让我们先从列出核心属性/功能开始，然后展开讨论。

• 基本设置
• 同步可组合性 - ULTRA TX
• L2 <> L2
• L2 <> L1
• Booster Rollup
• 实时多证明者
• Based 预确认

我们还会提供一些关于实际操作的更多细节：

• A. 区块提议与证明
• B. 价值捕获
• C. 基础设施
• D. 与其他（Based）Rollup 的互操作性

1. 基本设置

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

在本文的其余部分，当我们提到 L2 时，指的是 Gwyneth 网络中的这些 L2 之一。

2. 同步可组合性 - ULTRA TX

所有 Gwyneth L2 可以同步直接访问彼此。如果 L1 提议者支持，它们也可以同步访问 L1。这里的“访问”是指读取和写入所有状态，就像它们在同一条链上一样。从用户的角度来看，交易就像在单条链上运行。用户创建一笔独立的交易，并按通常方式支付费用。Gas 价格会根据交易当前部分运行所在的特定 L2 而改变。

L1 可组合性通过 ULTRA TX 实现。你可以在 这篇 ethreserch 文章 中了解更多信息。

L2 <> L2

我们通过一个新的预编译合约 XCALLOPTIONS 引入了 L2 同步可组合性。该预编译允许智能合约定义紧随其后的第一个 (DELEGATE)CALL 的目标链。该预编译将执行环境切换到特定链的状态，包括基础费用。

对于无状态证明者来证明这一行为，所需的输入是所有被访问链的状态承诺。我们使用 Merkle 证明验证不同的链状态，并在验证后更新状态。输出则是更新后的状态承诺。

对于构建者来说，要执行这些跨链交易，需要知道每条链的最新状态。用户将访问的链作为交易的一部分指定，这告知了构建者所需的链状态。如果使用了未指定的链，交易将回滚，用户仍需为已执行的部分付费。这防止了对构建者的 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 预编译从 L2 调用 L1。

3. Booster 功能

Booster Rollup 是那些执行交易的 Rollup，仿佛它们在 L1 上执行一样，拥有对全部 L1 状态的访问权限，但它们也有自己的存储。这样，执行和存储都在 L2 上进行扩展，而 L1 环境作为共享基础。换句话说，每个 L2 都是 L1 的镜像，L2 通过分片交易执行和存储，直接为部署在 L1 上的所有应用扩展 L1 的区块空间。

水平可扩展性

Gwyneth 的一部分源于 Booster Rollup。Booster 功能使得水平可扩展性更易实现，且碎片化更少。L1 状态可以在任何 L2 上以与原生 L2 状态相同的成本访问。

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

随着不同 L2 上的活动增长，由于 EIP-1559，拥堵可能导致基础费用增加，从而使用户费用更高。通常，活动会被激励在基础费用较低的 L2 上进行，因此当需要额外容量时，可以部署额外的 L2。DApp 可以根据其用例和限制选择策略。

一个应用可以通过在所有 L2 上并行化其状态和执行来支持全面扩展。智能合约可以一次性部署到 L1，然后通过向 L1 实例进行 DELEGATECALL，DApp 的功能可以在每条链上并行发生。仅在进行跨链调用时会引入同步点。一个跨不同 Gwyneth L2 的可并行化 DApp 可以显著受益于此设置。例如，部署在 L1 上的 Uniswap 池可以允许用户同时在 L2 上通过 DELEGATECALL 进行交易，多个池的状态分布在不同的 L2 上。由于池是独立的，Uniswap 受益于并行执行。用户还可以使用跨链调用与不同链上的池进行交互。

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

针对同步可组合性的优化

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

然而，使用状态增量进行更新会引入额外的安全风险。L1 智能合约的安全现在将依赖于 Gwyneth 区块被正确证明。原本在 L1 上引起智能合约状态更新的原始逻辑现在被跳过了。

L1 状态更新的另一种优化方式是通过批处理，例如将 L2 上的多次交换合并为 L1 上的单次交换。

4. 实时多证明者

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

可用的证明者类型包括：

• TEE（例如 SGX、TDX、Nitro Enclave、AMD SEV）：证明可以以接近原生的性能完成，生成这些证明的硬件通常广泛可用，并且生成成本低廉。缺点是它们具有额外的信任假设，并且已被不同程度地利用。
• AVS（或多签）：也是一个提供原生证明性能的选项。可以选择一大组去中心化验证者或一小组合格的验证者，质押确保加密经济安全。然而，这个选项本身并不理想，因为 L1 并不直接验证状态转换。
• ZKP：理论上是理想的证明方式，因为没有增加额外的信任假设（除了密码学）。然而，目前证明生成的延迟对于实时用例来说太高了。ZK 仍在快速发展，预计在未来一两年内可以实现实时 ZK 证明。

目前，我们将使用 TEE 和 AVS/多签证明者。ZK 证明仍然可以间接用于加强我们协议的安全性，通过在证明其他证明者有故障时使用它们。更多细节见下文。

安全性

多证明者

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

• 需要为所有受支持的 TEE 提供证明：单一 TEE 的安全性不够，因为有时会针对特定 TEE 发现漏洞。但多种不同类型 TEE 的证明提供了非常强的安全性，因为同时发现所有 TEE 漏洞的可能性非常低。链上 TEE 证明验证成本低廉，因此同时验证多个不会显著增加成本。
• 某种 AVS/多签证明，以提供具有完全不同安全概况的额外层级。要求具有非常不同安全假设的证明类型，使得单个实体更难同时攻破所有证明者。

证明者取消智能合约

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

• 如果同一个证明者被用于证明两件不同的事情，则该证明者应被禁用
• 如果证明者被证明输出了与其他两个达成一致的证明者不同的输出，则该证明者应被禁用

该合约独立于 Gwyneth 主智能合约运行，它只拥有在验证器注册中禁用证明者的权力。任何有效的输入和输出对都可以用来证明证明者存在故障，该系统不限于只能证明属于 Gwyneth 链的区块。

该智能合约将作为链上漏洞奖励。任何能证明证明者存在故障的人将自动获得奖励。如果公开了允许证明者被利用的根本问题，将提供额外奖励。

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

桥配额

虽然 Gwyneth 没有传统的桥（跨链功能内置于协议中），但合约可以设置配额，限制在一定时间内可以提取到 L1 的价值量。这限制了在某种安全机制启动之前可能被盗的资金量。

质押验证者

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

5. Based 预确认

Gwyneth 将支持 based 预确认。由于 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 区块并检测所有 L2 区块提议，递归地独立验证每个 L2 区块。这允许 L2 区块在到达时就被证明，然后针对正在证明的整个 L1 区块窗口进行聚合。（注意，此设置有一个限制：正在提议区块的 L1 区块在 EVM 中尚不可用，在某些情况下可以解决。更多内容见下文）。

费用支付

费用支付很简单：

• 提议者收集所有交易费用/MEV（当然，实践中可能使用 PBS 风格的区块构建）
• 提议者必须证明其提议的所有区块。假设证明生成成本低廉（对于某些证明类型已经是这样），我们可以允许提议者不证明其区块。这样效率更高，因为可以聚合更多的区块验证。或者，如果证明区块所需的链下工作量仍然很大，我们仍然可以强制提议者证明其所有区块。对于预确认，预确认者已经质押，如果能够证明提议者在其区块范围结束时没有这样做，我们可以简单地罚没提议者。

L2 上可用的最新 L1 状态

到目前为止，我们忽略了如何在 L2 上实际获取最新的 L1 状态。在 EVM 中，只有前 256 个区块的区块哈希可用，因此我们可以轻松地将它们插入 L2 并了解最新状态。然而，如果我们真的需要最新的 L1 状态（为了实现与 L1 的同步可组合性确实需要），我们需要在 L2 区块被提议时 L1 的准确状态。但是，EVM 不暴露当前区块中的任何变更信息。因此，我们有几种选择：

• 如果我们不需要写入 L1，我们不需要能够立即提供 L2 区块的证明。这允许我们在后续区块中重新执行 L1 区块而没有任何问题，使用 EVM 中可用的 L1 区块哈希。
• 如果我们只需要写入 L1 而不需要任何读取，也没有问题，因为我们不需要访问最新的 L1 状态，我们可以使用前一个 L1 区块的 L1 区块哈希。

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