使用 Base Appchains 进行扩展

Base 正在推出 Appchains - 应用程序的专用 rollup

要点： Base Appchains 是特定于应用程序的 rollup，旨在实现独立扩展、自定义以及通过近乎即时的桥接与 Base 无缝集成。它们提供专用的区块空间、可预测的性能，并能访问 Base 的用户和流动性。非常适合游戏平台、社交网络或发布可验证、可审计和可组合数据等高吞吐量应用。

通过经由 Appchain 汇总到 Base，应用程序可以构建满足其特定需求的解决方案。无论是需要扩展到自己的费用市场的游戏，还是需要在链上以低成本发布可审计、可组合数据的应用程序，Appchains 都能让构建者在 Base 生态系统中构建他们所需的东西。

专用区块空间的力量

Base Appchains 的核心价值主张之一是提供加粗专用区块空间加粗。每个 Appchain 都有自己独立的执行环境，而不是在共享链（如 Base 本身或 Ethereum 主网）上竞争资源。这提供了几个关键优势：

• 性能和可预测性：你的应用程序的性能不再受其他应用程序活动的影响。无论整体网络拥塞情况如何，你都可以获得一致、可预测的交易速度和 gas 成本。这对于需要高吞吐量和低延迟的应用程序至关重要，例如游戏、高频交易平台或社交媒体应用程序。

• 按需扩展：你的 Appchain 可以独立扩展其资源，以满足你的应用程序的特定需求。随着用户群的增长，你可以增加你链的容量，而不会影响 Base 或其他 Appchains 的性能。

• 自定义：你可以更好地控制 Appchain 的配置，包括自定义 gas 代币和权限。尽管当前的自定义受到限制，但我们计划探索许多不同的自定义。

可组合性和 Base 生态系统

Base Appchains 在专用资源与紧密集成的 Base 生态系统之间取得平衡，从而提供关键优势：

• 无缝集成：Appchains 被设计为 Base 的自然扩展，可实现 Base 和你的链之间快速、无摩擦的资产转移，从而确保有凝聚力的用户体验。

• 访问 Base 流动性：你的 Appchain 可以利用 Base 现有的流动性和用户群。

• Coinbase Onboarding：利用 Coinbase 的基础设施，Appchains 简化了用户 onboarding 流程。Coinbase Smart Wallet 和 Onchain Kit 等工具（包含桥接等预构建组件）可在任何 Appchain 上运行。

快速提款的关键需求

在 Base 之间快速无缝地转移资产的能力，提供了一种统一的体验。 现有的 rollup 解决方案尚未实现这种体验所需的即时提款。

• Optimistic Rollups：这些 rollup 依赖于一个挑战期（通常为 7 天）来验证状态转换，从而延迟了提款。

• ZK Rollups：ZK rollup 承诺在没有挑战期的情况下实现快速 finality 和提款。但是，为 EVM 生成 ZK 证明在计算上既密集又昂贵。虽然 ZK rollup 代表了一种有前途的长期解决方案，但当前的实现方式的性能还不足以满足需要加粗立即加粗提款的高吞吐量、低延迟应用程序的需求。

Base Appchains 及其 TEE 驱动的证明系统提供了一种弥合这一差距的解决方案，在保持高水平的安全性和性能的同时，提供近乎即时的提款。下一节将深入探讨实现此目标的加粗技术细节。

OP Stack 和 TEE 证明

Base Appchains 为开发人员提供专用的区块空间，同时保持无缝的用户体验。 其中的核心是能够在 Appchain 和 Base 之间快速有效地转移资产，这是传统的桥接解决方案由于固有的延迟而难以实现的壮举。 Base Appchains 通过构建与 Base 相同的技术，并通过可信执行环境 (TEE) 增强来实现快速提款证明，从而克服了这一问题。

TEE 驱动的 OP Stack 分叉

Base Appchains 的核心创新在于 op-enclave，它是 OP Stack 的修改版本，它利用可信执行环境 (TEE) 进行状态转换证明。 这取代了传统的 optimistic rollup 挑战期，取而代之的是基于 TEE 的可信证明安全模型，从而实现了近乎即时的提款。 你可以在 https://github.com/base/op-enclave 查看它。

可信执行环境 (TEE)

Base Appchains 利用可信执行环境 (TEE) 来实现安全性和性能。 我们的首选是 AWS Nitro Enclaves，它提供强大的安全性和标准的 AWS 集成，尽管模块化设计支持未来采用 Intel SGX 等替代方案。

什么是 TEE？

TEE 可以被看作是处理器中的一个安全的、隔离的“金库”。它是 CPU 和内存中受保护的区域，为代码和它处理的数据提供硬件强制的保密性和完整性。TEE 的主要特性包括：

• 隔离： Enclave 与系统的其余部分隔离，包括操作系统、虚拟机监控程序和其他应用程序。这种隔离由 CPU 本身强制执行。

• 保密性： Enclave 中的数据和代码会被加密，并受到保护，防止未经授权的访问，即使是像操作系统这样的特权软件也无法访问。

• 完整性： Enclave 的代码和数据不能被篡改。硬件机制会检测并阻止任何未经授权的修改尝试。

• 证明： Enclave 可以生成密码学签名的证明，证明：

  • 在 enclave 内部运行的代码（由加密哈希表示，例如 Nitro Enclaves 中的 PCR0）。

  • 该代码在真正的 TEE 中运行（由 TEE 提供商的签名密钥验证）。

在 AWS Nitro Enclaves 中，代码被捆绑到一个 Enclave Image File (EIF) 中。在启动期间，Nitro 虚拟机监控程序会测量 EIF，生成一个加密哈希 - PCR0（平台配置寄存器 0）- 唯一标识 enclave 的代码和配置。任何更改都会产生一个新的 PCR0。Base Appchains 还利用 Nitro Secure Module (NSM)，这是一个硬件组件，提供加密服务，例如为 enclave 密钥对生成安全的随机数。

信任假设

虽然 TEE 提供了显著的安全优势，但重要的是要理解底层信任假设：

• 硬件完整性： 我们依赖于 AWS Nitro 系统的硬件完整性。这包括信任 AWS 的设计和制造过程，以及不存在未被发现的漏洞。硬件的物理安全也至关重要。

• 证明过程： 我们信任 Nitro 证明证书密钥的完整性。

• AWS 作为一个受信任的第三方： 我们依赖 AWS 来维护其 Nitro Enclave 基础设施的安全性和完整性。

• PCR0 完整性： 我们假设 PCR0 测量是准确且防篡改的。

op-enclave 的工作原理

无状态

Base Appchains 由 op-enclave 提供支持，它利用我们上面概述的所有属性来构建一个安全高效的提款证明系统，从 Appchain 到 Base。

为了使提款能够正常工作，我们需要证明 rollup 的状态。 在 OP Stack 中，这是通过输出根来完成的，它封装了有关 rollup 状态的关键信息。 这包括所有执行层帐户的 Merkle-Patricia-Trie (MPT)的状态根，Message Passer 合约的存储状态根以及最新的块哈希。 借助已发布和经过验证的输出根，钱包中包含该输出中的提款将能够提交提款证明并将资金提取到 Base 上。

我们可以使用 enclave 来执行与通常相同的 OP Stack 代码，因此它将准备好要证明的输出根。 问题是，这意味着要在 enclave 中运行一个完整的节点。 我们的目标是为成百上千个 Appchains 提供证明，因此这是不可扩展的。

相反，我们以无状态方式运行 enclave，因此我们会传递 OP Stack 执行给定块所需的所有信息。 这包括每个链的配置，执行期间读取的所有状态，先前的输出根，排序的交易，Base 交易，将要执行的代码，Merkle 证明和消息合约状态。 由于这是无状态的，并且只是在给定数据上重新执行交易，因此它可以与单个 enclave 一起用于任意数量的链。 此信息是使用 debug_executionWitness rpc 方法从正在运行的排序器中获取的。

// 图片，注释：用于证明 flow 的信息是如何传递到 enclave 的

执行 Appchain 块后，enclave 将创建一个提案对象，该对象包含对链特定配置、Base 块、Appchain 块号、先前的输出根和计算出的当前最终输出根的签名。 此签名证明该块已在安全 enclave 中正确执行，并且是在链上用作输出根证明的内容。

证明不需要每个块都提交，可以进行聚合，直到协议要求链上提交为止。 这可以通过将先前已证明但未提交的输出根传递给 enclave，然后保留返回的已证明输出以进一步聚合或由提议者提交来完成。

Enclave 密钥

正如我们上面提到的，一个 enclave 有一个签名密钥，该签名密钥用于链上验证提交的证明。 但是，签名如何证明它来自 enclave，并且它来自哪里？

Nitro Secure Module (NSM) 是 AWS Nitro Enclaves 中的一个硬件组件，提供了密码学上安全的 entropy。 启动时，enclave 会使用此随机性生成一个新的签名密钥。 证明将证明此密钥来自 enclave 内部。

扩展 - 密钥同步

我们如何扩展 enclave 的数量？ 如果所有 enclave 共享相同的密钥，则它们可以安全地相互通信，并且可以使用单个地址检查在链上信任任何 enclave。 因此，我们需要将密钥从一个 enclave 共享到另一个 enclave，而无需将该密钥暴露于 enclave 外部。 我们能够使用非对称加密和证明的组合来实现此目的。

该过程从一个 enclave（请求者）要求另一个 enclave（持有者）共享其签名密钥开始。 持有者验证请求者的证明，检查其 PCR0 以确认它是运行预期代码的受信任的隔离 enclave。 该证明中包含请求者的公共 RSA 密钥，持有者使用该密钥对签名密钥进行加密，然后再将其发送回去。 只有具有私有 RSA 密钥的请求者才能对其进行解密。 我们的 enclave 具有用于解密密钥共享消息的 RSA 解密密钥和用于签署输出根的 ECDSA 签名者密钥，该密钥在具有相同 PCR0 的所有 enclave 之间共享。

为何有效：

• 保密性： 只有请求 enclave（具有其私有 RSA 密钥）才能解密签名者密钥。 窃听者甚至任何一台机器上受到威胁的操作系统都无法访问该密钥。

• 完整性： 证明过程确保远程 enclave 与运行正确代码（由 PCR0 验证）的真正的 enclave 进行通信。 这可以防止恶意 enclave 模拟本地 enclave。

• 身份验证： 远程 enclave 知道它正在将密钥发送到正确的 enclave，因为它正在使用来自经过验证的证明的公钥。

链上

要使用签名密钥来证明输出根，我们需要从我们的 enclave 中获取一个证明文档，对其进行验证，并将 enclave 的公钥注册为 Base 上 SystemConfigGlobal 智能合约的有效签名者。 此合约用于所有 Appchains 的证明验证。

要信任证明文档，我们必须信任证明中使用的证书。 链上 CertificateManager 合约保留了专门用于 AWS Nitro enclave 的的经过验证的 X.509 证书的映射，其中 AWS Nitro 根证书充当信任根。 它通过验证签名、检查有效期限和强制执行基本约束来实现证书链验证。

一旦我们可以信任证书，我们就可以继续进行下一个问题，即可信任证明本身。 NitroValidator 合约通过验证其编码结构、检查签名和验证证明来自真正的 AWS Nitro Enclave 的的证书链，来验证来自 AWS Nitro Enclaves 的证明。

要添加签名者以用于输出根，我们现在只需要：

• 获取 enclave 的证明（包括其公钥）

• 确保证明中使用的所有证书已在 CertificateManager 中验证

• 在 SystemConfigGlobal 上注册 PCR0

• 调用 registerSigner，它将：

  • 验证证明

  • 验证证明中的 PCR0 是否已注册

  • 验证时间戳

  • 获取公钥并计算 enclave 的地址，该地址已注册为 accepted。

// 图片，注释：Enclave 注册如何工作

我们可以使用来自这些已注册地址的签名作为计算来自 enclave 加粗内部加粗的证明。 然后，所有 Appchain OutputOracle 合约都调用 GlobalSystemConfig 来检查输出提案是否包含有效的签名者，从而为任意数量的链提供快速提款。 将其保持为简单的签名检查还可以降低提议者的 gas 成本！

OP Stack 修改

OP Stack 的模块化设计使得构建 rollup 变得容易，并且 op-enclave 使用其模块化来换入一些新组件，同时保留现有的经过战斗测试的代码。

由于我们使用 op-enclave 的主要目标是实现快速提款，因此我们需要修改几个你熟悉的典型 OP Stack 实体。 为了启用提款，必须由提议者发布输出根。 让我们首先探讨这些更改

提议者

提议者现在与运行 op-enclave 的 AWS Nitro TEE 交互。 它维护最新的经过验证的状态，并且在检测到提款时，会确保该证明包含在提交给 Base 的提案中的块。 提议者仅提议安全块（提交后批处理），并且如果没有发生提款，它会每 15 分钟提交一次证明以保持状态最新。

批处理器

批处理器发布交易批处理以用于派生 Appchain 状态，并且必须以相同的高度提交输出提案。 修改批处理器，以便如果一个块包含提款事件，则批处理器会立即将当前通道视为已满，并将该批处理提交给 L2。 这优先处理提款交易以进行快速处理。 如果没有看到提款，批处理器还将每 15 分钟提交一次批处理。

数据可用性

OP Stack 还支持替代数据可用性（“altDA”）解决方案。 Base Appchains 利用 Amazon S3 存储批量数据，只有该数据的标识符记录在链上。 通过减少存储在区块链上的数据量，我们可以为 Appchain 用户节省大量 gas 费用。 由于链状态是通过 enclave 独立验证的，因此减少了对高度去中心化数据可用性的依赖，而这通常是支持构建故障证明挑战所必需的。 外部各方仍然可以验证链状态，但不是通过完全去中心化的方式。

展望未来，我们将在启动后探索为其他 altDA 解决方案（例如 EigenDA 和 Celestia）提供支持。

权限

虽然不是 op-enclave 功能，但 Appchains 允许链所有者设置可以通过标准 RPC 调用的合约的权限。 此功能允许链所有者有效地管理其区块空间，并确保链资源按预期使用。 通过能够通过桥的存款调用强制包含交易，链用户始终受到审查的保护。 这有效地充当了两个通道 - 一个所有者控制的高吞吐量通道和一个没有高速通行证的所有流量通道。

现在一起

将所有这些放在一起，我们可以快速回顾一下证明流程。

交易和批处理： 用户将交易提交给 L3 Appchain。 批处理器收集这些交易，并将交易的标识符提交给 L2 (Base)，并将压缩的交易数据提交给 S3。

Enclave 执行： 提议者将所需的信息提交给 enclave，以使其加粗无状态地加粗执行交易，从而重新计算 Appchain 状态。

证明生成： 执行后，enclave 会生成一个证明，包括新的 Appchain 输出根和来自 enclave 私钥的签名。

提议者提交： 提议者从 enclave(s) 接收输出根和证明，并在发生提款或经过指定时间后将其提交给 Base 上的 OutputOracle 合约。

签名检查： OutputOracle 合约检查签名者是否在 SystemConfigGlobal 合约上注册。 如果是，则接受输出根，因为这意味着它来自运行正确代码的经过证明的 AWS Nitro enclave。

快速提款： 由于输出根是根据 TEE 证明（和受信任的签名者检查）接受的，因此可以几乎立即处理提款。

// 图片，注释：从 L3 到 L2 的快速提款流程

验证

你可以在链上自行验证 PCR0，以确保 Appchain 系统仅使用你期望的内容。 可以监视 GlobalSystemConfig 合约的任何更改，以确保仅运行受信任的镜像。

要生成我们使用并在链上检查值的 PCR0，你可以在此处查看示例 https://github.com/base/op-enclave/tree/main/tools/pcr0-verifier

安全性

构建 TEE 证明系统意味着我们的确有一些受信任的各方，但是当我们等待 ZK 技术成熟时，可信环境提供了一个高性能且实用的解决方案。

op-enclave 系统当前依赖于 Amazon AWS 的公钥基础设施 (PKI) 来获取证书及其 enclave 硬件的完整性。 任何一方的妥协都可能导致无效的输出根传递到 rollup。 但是，额外的保障措施可以减轻此风险：由我们控制的提议者仅提交其在本地验证的输出根。 为了使攻击成功，AWS PKI 和我们的服务都需要同时受到攻击 - 任何一方都无法单独破坏该系统。 AWS 无法绕过提议者的验证，并且 Coinbase 无法伪造证明所需的 AWS Nitro 签名。

目前，Coinbase 拥有 SystemConfigGlobal 合约的升级密钥，而情况如此，Coinbase 仍然可以单方面行事。 我们计划通过将控制权长期转移到安全委员会或允许链所有者决定何时升级（或者是否升级）来逐步实现去中心化。

所有合约和系统都经过了审计，详细信息可在其各自的存储库中找到。

开放构建

Base 的开放构建方法建立了责任感，并实现了跨生态系统的有意义的协作。 通过从一开始就将 Op-enclave 开源，Base 建立了一个透明的开发环境，该环境加速了技术进步，同时通过社区审查和贡献确保了更高的安全性。 这种透明度充当了协作的催化剂，使开发人员可以利用并构建现有知识，同时提供有价值的社区反馈渠道。

我们已向 rollup-as-a-service 提供商（例如 Conduit 和 Caldera）提供了所有详细信息，以便为其客户运行 op-enclave，并将与他们以及像 Spire 这样的 rollup 研究团队合作。

除了 op-enclave repo，Nitro-Validator 可以用作任何想要使用 AWS Nitro 的人的通用链上验证器！ 向 Marlin Protocol 团队致敬，感谢他们的灵感以及他们在 Nitro Prover 上的工作。

Coinbase 支持

Base Appchains 旨在与 Base 无缝互操作。 目前，其中的关键组成部分是桥接机制，它允许用户在 Base 和他们选择的 Appchain 之间移动资产。

OnchainKit

使用 OnchainKit，桥接进出你的 Appchain 即可正常工作。 OnchainKit 提供了预构建的 React 组件，可处理与桥接合约交互的复杂性。 在许多其他组件中，OnchainKit 现在提供了一个 drop-in 桥接 UI，为你提供了一个功能齐全的样式化桥接，你可以将其放置在任何地方。

在此处查看 https://www.base.org/builders/onchainkit

扩展 Coinbase 产品集成

与 OnchainKit 和 Smart Wallet 的集成仅仅是个开始。 Base 正在积极致力于实现与更广泛的 Coinbase 产品和服务的无缝集成，从而使你的用户可以更轻松地发现你的 Appchain 并与之交互。

未来

Base Appchains 仅仅是个开始，有着令人惊叹的未来可以共同构建！ 我们设想了一个高度可定制的 Appchains 世界，在这个世界中，开发人员可以自由地创建他们需要的确切区块链环境——利用我们基于 TEE 的证明系统在今天实现快速 finality，同时保持与 ZK 证明集成的兼容性，因为该技术会不断成熟。 我们很高兴看到社区将构建哪些创新应用程序和协议，并且我们致力于根据真实世界的反馈和需求发展这项技术。 无论你是在重新构想游戏、DePIN、DeFi、社交平台，还是在探索全新的用例，我们都邀请你加入我们，通过开放协作来塑造 Base Appchains 的未来。

开始使用

要立即开始在你的 Base Appchain 上构建，请查看：

https://docs.cdp.coinbase.com/appchains/docs/welcome

• 原文链接： blog.base.dev/scaling-wi...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～