Base-Solana 桥梁工程

TL;DR(太长不看): 新的 Base-Solana 桥是一个为链之间直接资产和消息传输而定制设计的解决方案。它代表了我们朝互联的多链全球经济迈出的第一个重要步骤。

我们最近启动了 Base 和 Solana 之间的桥，实现了链之间的 Token 转移和任意消息传递。这篇文章详细介绍了架构、影响我们设计选择的工程约束，以及我们未来改进和去中心化的路线图。

为什么构建桥？

为了建立一个全球经济，我们需要让人们能够以互联网的速度轻松地转移资产，并利用每个链上的流动性。虽然以太坊生态系统已经是一个高度互联的 L2 网络，但缺少与该生态系统之外的链的规范连接。

我们的第一步是解锁对 Solana 的访问，Solana 是一个拥有 超过 80 亿美元 TVL 和 50 亿美元日交易量 的网络。Base <> Solana 之间已经存在由非附属第三方运营的桥接选项，那么为什么还要投资构建一座桥呢？

我们认为在 Base 的协议层面上解决这个问题是有价值的。现有的第三方协议在公共 mempool 中竞争区块空间，使它们受到可变成本和延迟约束的影响。在 Base 中添加原生互操作性使我们能够：

• 在 Base 中引入规范的 Solana 资产表示，并在 Solana 上引入规范的 Base 资产表示。

• 降低成本，因为原生桥不需要收取协议费用，只需支付现有的 gas 成本即可。

• 实时索引最终确定的 Solana 状态，以降低延迟。

• 拥有影响跨链资产的安全属性。

桥的设计

我们将桥设计为一个低级原语，其灵感来自 Base 和以太坊之间的原生桥。由于必要性，它是非对称的，利用了两个链的独特优势，并克服了它们的约束。支持的操作包括 Token 转移、任意函数调用以及两者的组合。

系统属性

Token 桥接

在桥接源链资产之前，必须在目标链上创建相应的 Token 包装器。这些包装器是由桥拥有的 Token，赋予桥独家权限，可以随着资产在网络中移动而铸造和销毁它们。

这种机制创建了一个“锁定和铸造”的概念。首先，源链资产被锁定在桥拥有的保险库中；然后，桥在目标链上为用户铸造等量的包装 Token。然后，要桥接回来，目标链包装 Token 被销毁，这会触发从源保险库中解锁原始资产。

延迟

端到端延迟严格受源链最终性和 oracle 验证开销的限制。

• Solana → Base： 延迟由 Solana 的 finalized 承诺级别决定。在验证器集的绝大多数（66%+）确认该插槽之前，不会处理消息，从而确保重组保护（大约 15 秒）。

• Base → Solana： 延迟受以太坊 L1 最终性的限制。状态更新仅在定序器批量发布到以太坊后，并且 L1 区块达到 finalized 状态后才会传播（大约 15 分钟）。

费用

跨链桥接提出了一个基本的资源定价挑战：在目标链上执行交易需要以该链的原生资产支付区块空间费用，但用户在源链上启动该操作。

在我们现有的规范系统中，从以太坊到 Base 的存款由定序器自动包含，而从 Base 到以太坊的提款需要用户手动证明并在 L1 上执行交易。

我们将 Solana 桥设计为遵循完全相同的模式：

• Solana → Base： 此路径的功能类似于存款。该协议通过预先验证交易来保证在 Base 上执行的能力。桥收取费用以支付此提交的成本。用户还可以选择通过指定 gas 限制来支付自动中继的费用。收取的具体费用是通过从以太坊的 EIP-1559 改编的机制以算法方式得出的。

• Base → Solana： 此路径的功能类似于提款。该协议传播状态根，但不执行执行。用户或第三方求解器负责提交包含证明，并直接在 Solana 上支付必要的 SOL gas 费用。不需要协议内费用。

架构

该桥依赖于两个主要的链上部署：Solana 上的一个整体 Anchor 程序和 Base 上的一组模块化智能合约。它还依赖于 Coinbase 和 Chainlink 运营的链下验证器。

Solana 架构

在 Solana 上，我们部署了一个基于 Anchor 的 桥程序 作为所有跨链活动的网关。该程序处理三个关键功能。

• 消息出口：为每个以 Base 为目标的操作创建离散的 OutgoingMessage 帐户。

• 状态验证：维护有效 Base 根的注册表，并验证传入消息的包含证明。

• 资产托管：管理 程序派生地址 (PDA)，这些地址充当锁定的 SPL Token 的保险库，并持有包装的 Base 资产的铸币权限。

Base 架构

在 Base 上，我们选择了一个模块化系统来处理 EVM 状态管理和执行复杂性：

• Bridge：中心枢纽。处理消息入口/出口，持有锁定的资产（ETH 和 ERC20），并控制包装的 Solana 资产的铸造/销毁。

• BridgeValidator：在执行之前验证来自 Solana 的消息批次。

• Twin：Solana 用户的确定性执行上下文，允许与 Base dApp 交互，而无需管理单独的 EVM 密钥。

• CrossChainERC20Factory：部署和管理 Solana Token 的规范包装表示。

链下架构

我们运营一个自定义索引器，将链上组件连接在一起。此服务监控 Solana 程序和 Base 合约的状态。当发生状态转换时（例如，发出一条传出消息），oracle：

1. 索引来自源链的事件数据。

2. 从 Chainlink 去中心化 Oracle 网络 (DON) 和我们的内部验证器请求签名。

3. 将签名的状态中继到目标链。

流程图

Solana → Base 桥接

1. 用户调用 Solana 上的 Bridge 程序。

   • 请注意，由于 EVM 交易所需的 calldata 很容易超过 Solana 上的交易大小限制（1232 字节），因此可以选择将其分解为多个步骤，在启动桥接流程之前，将 calldata 加载到临时缓冲区帐户中。

2. 该程序将资金锁定在 PDA 保险库中，并初始化一个包含执行 Payload 的 OutgoingMessage 帐户。

3. Base oracle 索引新的 OutgoingMessage 帐户。

4. oracle 计算消息哈希，并从 Base 和 Chainlink 验证器请求 ECDSA签名。

5. oracle 将消息和验证器签名提交到 Base 上的 BridgeValidator 合约。

6. 中继器或用户调用 Bridge 合约以执行消息。

7. Bridge 合约验证 BridgeValidator 中的预验证并执行 Payload。

Base → Solana 桥接

1. 用户调用 Base 上的 Bridge 合约。

2. 该合约将编码的消息附加到链上 Merkle 山脉范围 (MMR) 数据结构。

   • 我们选择 MMR 是因为它生成紧凑的包含证明，可以轻松地适应 Solana 的交易大小限制。它也很容易维护；在 Base 上附加到结构的成本不到 1/10 美分，并且在我们达到大约 170 亿个节点之前，我们不会遇到 Solana 的大小限制。

3. Base oracle 在最终确定的区块高度检测到新的 MMR 根。

4. oracle 从 Base 和 Chainlink 验证器请求新根的 ECDSA 签名。

5. oracle 将签名的根提交到 Solana 上的bridge程序。

6. 中继器或用户根据更新的根生成包含证明（通过 Bridge.generateProof）。

7. 中继器或用户将包含证明提交给 Solana。

8. 该程序验证证明并执行消息。

安全

该桥的设计以安全为首要任务，以确保偿付能力和安全的桥接。在构建桥时，我们认为以下几个不变因素是基础：

• Solana → Base： 在 Base 上执行的交易与 Solana 上的存款相匹配

• Base → Solana：

  • 发布在 Solana 上的状态根与在 Base 上导出的状态根相匹配
  • 针对状态根证明的提款与 Base 上的交易相匹配

• 任何链上铸造的包装 Token 数量不得超过另一条链上锁定的 Token 数量

为了增加我们对桥安全性的信心，我们进行了：

• 对代码库进行内部审计，范围从设计阶段到部署
• 威胁建模并评估设计权衡
• 对基础设施进行渗透测试
• 由以下机构进行广泛的外部审计
  • Cantina 负责智能合约
  • Trail of Bits 负责 oracle
• 所有重要工作流程的单元测试和端到端测试

由于当前设计涉及一个中心化 oracle，因此我们努力降低该组件产生的风险，直到实现去中心化。

正如在设计中解释的那样，此桥的一个新颖之处在于使用 Merkle 山脉范围来表示状态根，而不是传统的 Merkle 树。我们自己的密码学团队与我们的内部审计师合作，找到了哈希冲突，并编写了一个证明，证明当前实现的合理性。

我们还设置了几个监视器，以提醒我们注意异常行为或已破坏的不变因素，例如

• 意外的存款/取款
• 桥接 Token 的锁定金额和铸造金额之间的差异
• 任何特权函数调用
• oracle 延迟或失败的交易
• 对我们桥合作伙伴的智能合约或 API 可用性的更改

还创建了 Runbook，以帮助我们的团队做好事件响应的准备。这些 Runbook 涵盖了上报路径和针对特定场景的行动手册，例如从链上黑客攻击和交易差异到链下 oracle 中断和合作伙伴可用性。

密钥管理

桥漏洞通常由于密钥泄露而发生，因此我们为与桥运营相关的私钥实施了关注点分离：

• 配置密钥： 由多重签名控制，用于参数更改和紧急暂停

• 升级密钥： 具有不同所有者的单独多重签名，用于合约升级

• 签名密钥： 用于在 Base 和 Solana 之间对消息进行签名。这些密钥在 Coinbase 和 Chainlink 基础设施之间拆分，需要双方的签名

每个操作都有指定独立的至少具有 3/5 阈值的多重签名帐户。特别是，由于签名密钥对于桥运营至关重要，因此我们与 Chainlink 的合作确保了密钥分布在不同的基础设施中，因此仅泄露任何一方都无法转移资金。

为了降低这些密钥暴露的风险，我们的愿景是尽可能地去中心化，以便信任模型类似于我们当前以太坊和 Base 之间的桥，如下一节所述。

去中心化路线图

虽然分布式验证器集为我们提供了良好的安全属性，但我们更喜欢探索密码学解锁，从而支持未来仅由 Solana + 以太坊共识保护的系统。

向完全最小化信任的桥过渡，我们考虑分为三个阶段，从当前通过独立验证器证明来保护的权限证明模型开始。后续阶段将详细说明在协议中嵌入的努力，集成验证逻辑以提高效率，以及 ZK 证明架构的长期目标，该架构旨在通过用共识的密码学证明代替证明来实现完全的去中心化。

第 1 阶段：权限证明（当前状态）

我们使用需要双方独立证明的共享责任模型来保护第 1 阶段：由 Base 运行的 oracle 和 Chainlink DON。

Chainlink DON 证明当前使用 3/5 多重签名方案进行操作，我们的计划是在不久的将来将其提高到 9/16 阈值。Base oracle 和 Chainlink DON 都必须证明消息才能成功处理。

验证器运营商维护两个不同的 secp256k1 密钥对，以生成 ECDSA 签名 - 一个专用于 Base，另一个专用于 Solana。我们强制执行此密钥隔离，以确保一方链上验证器的密钥泄露不会使另一条链面临风险。为了跟踪这些地址，Chainlink 管理一个链上注册表（Base 上的智能合约和 Solana 上的程序），在其中注册这些特定于链的公钥。我们的桥合约动态查询这些注册表以验证签名。

Solana → Base 验证

对于从 Solana 转移到 Base 的交易，Base Oracle 和 Chainlink 验证器会在消息中继到我们的 BridgeValidator 合约之前验证消息批次。

1. Base oracle 使用与 Solana 上的 OutgoingMessage 帐户相对应的消息哈希数组调用 Chainlink API。

2. 验证器确认批次中的每个消息哈希都对应于 Solana 桥程序创建的有效 OutgoingMessage 帐户。

3. 验证后，验证器会根据消息哈希的紧密打包数组的 Keccak-256 哈希生成 ECDSA 签名（keccak256(abi.encodePacked(messageHashes))）。

4. Chainlink API 收集所需的签名阈值，并将其返回给 Base oracle，后者在单个交易中将该批次提交到链上。

Base → Solana 验证

如上所述，验证从 Base 到 Solana 的交易的过程使用 MMR 来表示桥的状态，这有助于将证明保持在 Solana 的交易大小限制之内。

1. Base oracle 从 Base 桥合约上的 getRoot 函数中获取最新的 MMR 根、相关的 Base 区块号和 MMR 叶子计数。

2. Chainlink 验证器验证提议的 Base 区块号是否已最终确定，并且 oracle 提议的输出根与链上状态是否匹配。

3. 验证器根据连接的 MMR 根、Base 区块号和 MMR 叶子计数的 Keccak-256 哈希提供 ECDSA 签名。

4. Base oracle 收集这些签名，并将其包含在提交给 Solana 桥程序的 register_output_root 交易中。

第 2 阶段：协议嵌入

第 2 阶段通过将验证逻辑移至协议层来提高成本和延迟。我们修改 Base 协议以原生索引 Solana 数据，而不是通过智能合约验证 Solana 消息。

我们计划利用类似于 Optimism Superchain 的 op-supervisor 的组件。此服务从 Solana 提取 OutgoingMessage 帐户并将其转发到执行引擎，从而使节点能够原生验证跨链交易。

但是，原生索引引入了安全悖论。Base 通过 乐观容错证明系统 从以太坊获得其安全性。此系统能够验证状态转换，因为它具有对 L1 上所有所需输入的访问权限（存款和 blob）。由于 L1 无法了解 Solana 的状态，因此它无法验证来自原生索引 Solana 数据的交易的有效性。

为了解决这个问题，我们必须使 Solana 状态在以太坊上可用。我们引入一个 State Prover 服务，该服务将 Solana 状态表示发布到 L1，从而使容错证明系统能够根据受信任的根验证包含证明。

Solana 的架构使此过程复杂化。与 EVM 链不同，Solana 不在其区块头中包含全局状态根。为了弥合这一差距，我们运行一个 Solana 验证器节点的 sidecar，该 sidecar 会计算桥状态的 Merkle 化的根。在第 2 阶段，Chainlink 和 Base 验证器会证明此派生的根。

对于 Base → Solana 路径，我们集成了 op-enclave，这是对 op-stack 的一个相对较小的修改，用于证明 AWS Nitro Enclave 中的状态转换并输出生成的状态根。这消除了对 7 天挑战期的需求，并允许立即取款。State Prover 将这些根中继到 Solana，并附带 TEE 证明，从而消除了在此方向上进行验证器证明的需求。

我们打算修改 op-enclave 以直接证明桥 MMR 根，而不是整个 Base 状态根，从而保留现有的客户端证明接口。

第 3 阶段：ZK 证明

我们正在分享我们当前的思路，以提高我们对完全最小化信任架构的长期路线图的透明度，尽管我们尚未承诺特定的设计选择。我们欢迎对以下任何和所有反馈。

第 3 阶段的目标是完全消除对验证器证明的需求。相反，我们的目标是仅依赖于共识的密码学证明。

主要的工程约束是在 EVM 的资源限制范围内验证 Solana 的共识规则。Solana 目前以 400 毫秒的插槽时间和大量验证器集运行，需要验证每个区块数千个 Ed25519 签名。由于缺乏廉价的 Ed25519 预编译以及签名的 calldata 的高昂成本，因此直接在 solidity 智能合约中复制此逻辑会耗费大量 gas。

我们正在研究一种基于 ZK 的方法来压缩此验证。提议的系统将利用 ZK 电路来提取 Solana 区块头并聚合签名，从而输出有效状态根的简洁证明。

对于 Base → Solana 路径，我们建议利用 Base 已经发布到以太坊的输出根。由于通过 ZK 验证以太坊共识是一个众所周知的问题空间，因此我们的目标是将 Base 根提交给 Solana，并附带两个证明：

1. 共识证明： 验证以太坊状态根。

2. 存储证明： 证明以太坊状态中包含 Base 输出根。

一个关键的未决问题是该路径的延迟。在当前的乐观容错证明系统下，以太坊上的 Base 输出根受到 7 天挑战期的限制。等待此最终确认会大大降低桥的体验（15 分钟 → 7 天）。因此，此设计假定 Base 未来会成为 zk-rollup，最终确认的时间会短得多。

展望未来

Base-Solana 桥今天已在主网上线。我们邀请你在我们的 文档 和 Github 代码仓库 中了解更多信息，并分享你的反馈。

我们将继续突破可能的极限。我们设想 Base 成为全球经济的中心枢纽，并具有与所有主要链进行互操作的原生能力 - Solana 仅仅是一个开始。如果你有兴趣从事业界最困难的问题，我们正在招聘，我们很乐意收到你的来信。

在社交媒体上关注我们，以获取最新信息：X (X 上的 Base 团队) | Farcaster | Discord

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