Arbitrum 定序器宕机

Arbitrum 排序器中断 | 根本原因分析

由于其排序器和 feed 出现问题，Arbitrum 网络在 12 月 15 日经历了严重的停机。网络瘫痪了近三个小时。主要中断始于美国东部时间上午 10:29，当时一种名为 Inscriptions 的网络流量大幅增加。Arbitrum 的 layer-2 网络已处理超过 2229 万笔交易，总锁定价值为 23 亿美元。尽管网络取得了成功，但当前的设计在将交易发布到 L1 时存在一个重要的瓶颈，导致排序器停止工作。虽然像 Arbitrum Nova 和 Proto-danksharding 这样的进步可能会缓解这些设计问题，但这并不是 Arbitrum 第一次遇到此类问题——排序器中的一个错误也在 2023 年 6 月导致网络停止。

Arbitrum 排序器中断 | 背景

Arbitrum 是一种 Layer-2 (L2) 解决方案，它在以太坊主网之外结算交易。L2 提供较低的 gas 费用，并减少主区块链（在本例中为以太坊，L1）上的拥塞。Arbitrum 的当前版本称为 Nitro。Arbitrum Nitro 分两个阶段处理交易：排序，即对交易进行排序并提交到此序列；以及确定性执行，即每笔交易都经过状态转换函数。Nitro 将以太坊仿真软件与跨链功能的扩展相结合，并使用基于交互式欺诈证明的乐观 Rollup 协议。排序器是 Nitro 架构中的一个关键组件。它的主要作用是以诚实的方式对传入的交易进行排序，通常遵循先到先得的原则。这是一个由 Offchain Labs 运营的中心化组件。排序器将其交易顺序发布为实时 feed 和以太坊，在“Inbox”智能合约的 calldata 中。此发布可确保最终和权威的交易排序。此外，还存在一种延迟 Inbox 机制，供 L1 以太坊合约提交交易，并作为排序器发生故障或审查时直接提交的备份。

Arbitrum 排序器中断 | 根本原因

在中断之前的两个小时内，超过 90% 的 Arbitrum 流量由 Ethscriptions 组成。Ethscriptions 是使用以太坊 calldata 创建的 EVM 链上的数字artifact。与由智能合约管理的传统 NFT 不同，Ethscriptions 使区块链数据本身成为一个独特的 NFT。它们受到比特币铭文（Ordinals）的启发，但功能不同。创建 Ethscription 涉及选择图像，将其转换为数据 URI 格式，然后转换为十六进制格式，最后将其嵌入到 0 ETH 交易的 Hex 数据字段中。每个 Ethscription 必须是唯一的；重复的数据提交将被忽略。所有者可以使用 Ethscriptions ID 来证明或转移所有权。实际上，calldata 或 Ethscriptions 看起来像下面的代码：

data: {"p":"fair-20","op":"mint","tick":"fair","amt":"1000"}

Ethscription 的 Calldata 示例。这表示一个 token mint。

由于 Ethscriptions 非常便宜，因此可以用相同的成本完成很多 Ethscriptions。事实上，链上发布的交易中高达 90% 是 Ethscriptions。此外，以相对较低的成本，需要提交到 L1 的交易熵量增加到 80MB/hr，而流量高峰之前通常为 3MB/hr。我们通过查看排序器的平均链上交易发布量来计算得出。

现在，看看下面的 Arbitrum 架构图。请注意，为了将交易序列提交到 L1，数据发布者需要通过更多数量的交易来发布增加的数据量。在中断之前，每小时发布的交易数量比 12 月的平均值高出约 10 - 20 倍。

但是，负责发布这些交易的代码具有内置的限制，该限制限制了发布 L1 批处理的速度。在中断之前，如果 L1 mempool 中仍有 10 个批次，则不会再将批次发送到 L1，从而导致排序器停止。中断后，此限制随后提高到 20 个批次。但这可能不是一个好的长期解决方案，因为它增加了由于交易 nonce 问题而需要重新发布批次的可能性。

// 检查发布新交易是否会超出mempool中的最大待处理交易数量。
if cfg.MaxMempoolTransactions > 0 {
  unconfirmedNonce, err := p.client.NonceAt(ctx, p.Sender(), nil)
  if err != nil {
    return fmt.Errorf("获取数据发布者发送方的nonce: %w", err)
  }
  if nextNonce >= cfg.MaxMempoolTransactions+unconfirmedNonce {
    return fmt.Errorf(
      "... nonce为: %d 的交易将超出最大mempool大小...",
      nextNonce, cfg.MaxMempoolTransactions, unconfirmedNonce
    )
  }
}
return nil

批处理发布者负责将排序后的交易序列作为以太坊 calldata 发布。

Arbitrum 排序器中断 | 建议

有几个迹象表明，排序器以及网络在现实环境或对抗性环境中没有经过足够的测试。但是，幸运的是，即将到来的 Proto-Danksharding 对以太坊的升级也应有助于减少 L1 引起的拥塞。无论如何，Arbitrum 工程师可以考虑以下建议：

• 与其他类型的操作相比，Arbitrum L2 calldata 的 gas 价格是否设置得太低。Gas 是一种反 DoS 机制，它与 L1 特性密切相关。如果 L2 calldatas 的增加导致批处理规模成比例地大幅增加，那么攻击者可以制作具有大型 calldatas 的 L2 交易，从而导致批处理在 Brotli 压缩下无法很好地压缩，从而导致对排序器的 DoS 攻击。请注意，Arbitrum Nova 不应受到此问题的影响，因为交易数据未存储在 L1 上，仅存储哈希。
• L1 批处理的大小（当前在 mempool 中）与 L2 gas 价格之间是否存在紧密的反馈循环。存在一个间接的反馈循环，通过 L1 上的 gas 价格和 backlog 大小，但这可能不太紧密。此外，由于排序器无论如何都是中心化的，因此可以将反 DoS 措施直接编码到其中以拒绝交易。（注意：未来正在考虑一个更去中心化的排序器，因此最后一个措施将不起作用）
• 从长远来看，工程师们应该更多地研究如何提高 Rollup 的效率，以减少提交给 L1 的批次的大小。这可能包括在某个时候使用 ZKP Rollup。
• 此外，对排序器的安全审计应考虑 DoS 情况，无论是通过模拟/模糊测试，还是通过让审计员根据他们对所涉及链的深入了解，通过对抗性思维来思考敌对情况。

最后，Arbitrum 团队对软提交交易的方式做了一个小小的改变。在这个改变中，无论排序器协调器是否正在运行，feed backlog 都会被填充，这带来了它自己的风险，但使得在 Arbitrum 上运行的 dApp 在某些时期更具响应性。

免责声明：Arbitrum 排序器由 Offchain labs 单独运营。因此，关于其运营问题的大部分信息（例如日志）都没有公开，因此很难全面了解该问题。Dedaub 没有审计 Arbitrum 或 Offchain labs 软件。但是，Dedaub 已经审计了在 Arbitrum 上运行的其他（非 Arbitrum）软件和项目，例如 GMX、Chainlink、Rysk 和 Stella。

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