Blob聚合 -迈向更高效Blob的一步-Layer 2

Blob 聚合 - 迈向更高效的 Blob

本研究由 @artificialquant, @projectHodl 和 @Alpinex_ 合作完成。

TL;DR:

• 问题：Blob 空间有限且未得到充分利用。
• 解决方案：将多个 rollup 的 blob 组合成一个，有效地共享 blob 空间。

问题

每天都有新的 rollup 被创建，但并非所有都像 Arbitrum、Base 和 Optimism 那样被广泛使用。通过数据可用性（DA），rollup 向所有网络参与者提供交易数据，以便他们可以独立验证它。该数据被发布到 DA 层，例如 Ethereum（或其他 DA 链，例如 Celestia），可以使用 calldata（成本高）或 blob（成本较低）。这些 rollup 竞争有限的 128KB blob 空间（现在每个区块 6 个 blob，在 2025 年 3 月的 Pectra 升级后增加到 9 个）。随着对 blob 空间的需求增长，费用可能会呈指数级增长。

由于 blob 的数量有限，并且每个 blob 无论填充多少都会被全额支付，因此导致较小的 rollup（具有空 blob）与较大的 rollup（具有完整 blob）为每个 blob 交易支付相同的费用。因此，有限的 DA 空间被浪费，并且由于包含更多的 blob，所有人的费用都会上涨。

根据 @hyeonleee 的研究 rollup 的 blob 共享的潜在影响，我们看到 blob 利用率不足不仅是较小 rollup 的问题，也是较大 rollup 的问题（尽管它们受到的影响较小），因为 blob 费用增加。

\ rollup-blob-utilization552×808 68.1 KB

解决方案

我们建议通过将多个 rollup 的 blob 组合成一个，来扩展区块构建过程，使其支持“blob 构建”。这将允许 rollup 共享 blob 空间，降低成本，提高 blob 效率，减少网络拥塞，并使所有人都能更负担得起 blob 空间。

所提出的解决方案建立在现有基础设施和概念之上，例如 MEV-boost 和 Flashbots bundles。它旨在是无需许可的，因此任何人都可以开始提供 blob 聚合服务。通过密码学确保防止 blob 操纵的安全性。

技术细节

所提出的实现的规范与堆栈无关，甚至可以用于非 rollup 的 blob 数据。

我们还介绍了一些新术语：

• Blob shard：包含在聚合 blob 中的签名 blob。
• Aggregated blob：blob shard 的组，以标头为前缀。
• Blob Aggregator：服务提供商，收集 blob shard，将它们分组到聚合 blob 中，并通过 flashbots bundles 发布它们。
• Shared Blob Registry：ETH 主网上的合约，blob 交易发布到该合约。它包含 blob shard 验证逻辑和费用收集机制。

一般流程

\ blob-sharing-flow2899×1379 150 KB

1. Rollup 生成 blob shard 并将其发送到 Blob Aggregator RPC。
2. Blob Aggregator 连接到多个 Blob Aggregator RPC 流以接收 blob shard。
3. Blob Aggregator 将 blob shard 组合成单个 blob，并将其作为 blob 交易发送，该交易与执行层上的 Shared Blob Registry 交互。
4. Shared Blob Registry 合约验证 blob shard，计算费用，并奖励 Blob Aggregator。
5. 区块构建器将 blob 包含在下一个 L1 区块中。

Blob Shards

每个 blob shard 都有一个特定的结构。实际的 blob 数据在包含在聚合 blob 中之前，会以标头作为前缀。这由聚合器完成。

Chain ID
Signature (v, r, s)
Blob Data Length
    |
    |
    |   Blob Data
    |
    |

标头包含：

• Chain ID：blob 源链
• Signature：用于派生 blob 发送者。与 Chain ID 一起，它表示一个元组，用于唯一标识 blob shard 所属的对象。
• Blob Data Length：此 shard 中的 blob 数据字节数。

Blob Aggregator RPC

类似于 MEV 搜索者如何使用 eth_sendBundle 将一个或多个交易作为 bundle 发送，我们建议将此概念扩展到 blob。

通过使用 eth_sendBlob，rollup 可以将其 rollup blob 发送到聚合器 RPC，后者将尝试将它们组合成单个 blob 并将其发布到 L1。blob 的排序方式与交易类似——按每个 blob 字节的 gas 价格，如果 gas 价格相等，则按提交时间。

blob bundle 请求的结构是（以 JSON 编码）：

Blob Shard: {
    Chain ID
    Gas Price Per Byte
    Block Deadline
    Nonce
    Blob Data Hash
    Blob Data Length
}
Signature
Blob Data

Blob Shard 结构为给定的 blob shard 提供元数据，允许对其进行唯一标识，防止重复发布，并根据可用 blob 空间的每个 shard 利用率计算费用。所提出的结构不限制或将用户绑定到其 shard 中的特定 blob 数据布局。这使得用户可以针对其特定用例优化其 blob 数据结构。

Signature 字段将 blob shard 绑定到特定用户，确保请求未被篡改。它还用作链上身份验证机制，用于收取 blob 的费用，并确保聚合器收取的费用不超过 blob shard 支付的费用金额。

Block Deadline 的作用类似于 flashbots bundles 中的目标区块参数。这确保了 shard 可以包含到截止区块。包含在晚于区块截止时间的 blob 中的 shard 无效。这使得 blob shard 的包含更具可预测性，并简化了例如 rollup 批处理的后备机制，它们可以自己发布 blob 交易。

Blob Aggregator

Blob Aggregator 负责从不同用户那里收集 blob shard，将它们组合成单个 blob，并将其提交到 DA 层的 Blob Shard Registry，最好是在一个 flashbots bundle 中，如果 TX 失败，则回滚。聚合器是一个无需许可的实体，任何人都可以运行。

他们通过从每个 shard realized 的 blob 成本节省中收取少量费用来激励他们运行其服务。因此，他们的目标是用尽可能多的数据填充 blob。

聚合的 blob 布局包含 blob 标头，后跟包含 shard 的 blob 主体。主体的布局可能因聚合的 blob 版本而异（存储在标头中），甚至可以额外压缩。

标头还包含一个查找表，以加快 shard 发送者的处理速度，其布局如下：chain ID → shard sender → [shard1 idx, shard2 idx, …]。这使得可以直接跳转到特定 shard 发送者的 blob shard 数据的开头，而无需逐个处理字节。查找表可能会从 blob 标头移动到 Blob Shard Registry 合约 calldata，甚至可以通过事件发出，但这待定。

完整的聚合 blob 结构：

Aggregation Version
Blob Compression
Lookup Table
    |   Blob Shard 1
    |   Blob Shard 2
    |   Blob Shard 3
    |   ...
    |   Blob Shard N

一旦 blob 被聚合，聚合器就会准备 blob 交易，该交易调用 SharedBlobRegistry 合约上的 recordSharedBlob() 函数，以注册 blob 并正确收取费用和奖励。

Shared Blob Registry

Shared Blob Registry 是一个负责验证 blob shard 并补偿 blob 聚合器服务的合约。

我们为 Shared Blob Registry 合约提出以下结构：

/**
 *  @title Shared Blob Registry
 *  @notice 管理给定 blob 中使用的 blob shard 的存储、验证和正确处理。
 *          保证 blob 发布者支付正确的费用，并为 blob shard 聚合器提供公平的奖励。
 */
interface SharedBlobRegistry {

    /**
    *  @notice Blob shard 结构体，存储 blob 元数据信息。
    *
    *  @param chainId shard 所属链的 ID。
    *  @param gasPricePerByte shard 预期使用的每个字节的 gas 价格。用于根据利用的 blob 空间计算费用。
    *  @param blockDeadline shard 保持有效的块号。
    *  @param nonce (blobPoster, shard) 对的 nonce，用于防止重放攻击。
    *  @param dataHash shard 数据的哈希。
    *  @param dataLength shard 数据的长度。
    */
    struct BlobShard {
        uint256 chainId;
        uint256 gasPricePerByte;
        uint256 blockDeadline;
        uint256 nonce;
        bytes32 dataHash;
        uint256 dataLength;
    }

    /**
     *  @notice 存入抵押品以支付 blob 费用。
     */
    function depositFeeCollateral(uint256 amount) external;

    /**
     *  @notice 提取抵押品以支付 blob 费用。
     *
     *  @dev 如果 @param amount > 余额，则提取全部余额。
     */
    function withdrawFeeCollateral(uint256 amount) external;

    /**
    *   @notice 记录由多个 shard 组成的共享 blob。
    *
    *   @param shards 要记录的 Blob shards。
    *   @param signatures 验证 blob shards 的签名。
    *
    *  @dev 此函数执行以下步骤：
    *       1. 验证 BlobShards 的签名并识别 blob 发布者地址。
    *       2. 计算每个 rollup 的空间利用率。
    *       3. 确定未使用的 blob 空间并相应地向 rollup 收费，包括执行交易的基本 gas 费用。
    *       4. 计算每个 rollup 的节省。
    *       5. 收取费用，分配部分节省，并持久化 blob shards。
    *
    *  @dev Shard nonce 应该只使用一次。必须以增量方式使用。
    */
    function recordSharedBlob(BlobShard[] memory shards, bytes[] memory signatures) external;

    /**
     *  @notice 通过验证其签名、识别 blob 发布者地址并确保有足够的抵押品来支付费用来验证 blob shard。
     *
     *  @param shard 要验证的 Bob shard。
     *  @param signature 验证 blob shard 的签名。
     *
     *  @return isValid 如果 shard 有效，则为 True；否则为 False。
     *  @return blobPosterAddress 负责支付 shard 费用的 blob 发布者地址。
     *
     * @dev 使用 @openzeppelin/contracts/utils/cryptography/ECDSA.sol 中的 tryRecover，因为它具有额外的安全检查。
     */
    function verifyBlobShard(BlobShard memory shard, bytes memory signature) external view returns (bool, address);

    /**
    *   @notice 获取给定区块号和链 ID 的 blob shard。
    */
    function getBlobShards(uint256 blockNumber, uint256 chainId) external view returns (BlobShard[] memory);

    /**
    *   @notice 获取给定 blobPoster 和 chain ID 的下一个 nonce。
    */
    function nextNonce(address blobPoster, uint256 chainId) external view returns (uint256);

}

优点

• 成本节省：用户可以共享 blob 空间，从而降低成本并使每个人都能负担得起。
• 提高效率：blob 空间得到更有效的利用，从而减少网络开销。
• 更快的最终性：Rollup 可以更频繁地发布 blob，从而缩短了最终性时间。

开放性问题

• 激励措施：是否应由每个 rollup 决定与 Blob Aggregator 分享的节省百分比？还是应该由 Blob Aggregator 设置服务费？或者，费用是否应由 Shared Blob Registry 合约确定？最佳方法仍不清楚，因为每个选项都有其自身的优点和缺点。
• Blob Shard 冲突：如果 blob A 包含 blob shards 1、2、3，而 blob B 包含 blob shards 2、4、5，并且 blob A 已成功发布在链上，该怎么办？是否仍应在链上提交 blob B，还是应将其丢弃？这是否会导致 blob shard 提交的无限期延迟，因为 blob shard 2 也会影响 blob shards 4 和 5？
• 潜在漏洞：目前，不能保证 Blob Aggregator 实际上将 blob shard 包含在 blob 中，因为执行客户端无法读取有关 blob 内容的详细数据。我们如何确保 Blob Aggregator 是诚实的，并且不会在仍然收取奖励的同时提交空 blob？一种可能的解决方案是依靠 Blob Aggregator 的声誉和激励措施，例如未来的 blob 聚合奖励，以阻止此类行为。另一种选择是使用 restaking 机制。第三种选择是将 Blob Shard 支持直接实施到 Ethereum 中，可能作为一种新的交易类型。

结论

所提出的 Blob Sharing 概念旨在通过允许 rollup 共享 blob 空间来提高 rollup 效率。预计这种方法将降低 rollup 的成本，提高 blob 空间利用率，并使其更实惠。它还为 Blob Aggregator 提供了试验 blob shard 组合并准备发展成为 Based Sequencer 的机会。

其他资源

• Spire Labs：共享 Blob 压缩
• Suhyeon - Tokamak Network：rollup 的 blob 共享的潜在影响

反馈邀请

本提案旨在在投入开发之前收集其他社区成员的反馈。我们邀请所有人分享他们的想法、建议和潜在的担忧，以改进和完善这一概念。

• 动态 Blob 大小调整：减少小型 Rollup 中的零填充开销
• rollup 的 blob 共享的潜在影响
• Based Rollup 的 Blob 共享

• 原文链接： ethresear.ch/t/blob-aggr...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～