Standards Track: ERC

ERC-7588: Blob 交易元数据 JSON 模式

将元数据附加到由 Blob 交易携带的 Blob

Authors	Gavin Fu (@gavfu), Leo Wang (@wanglie1986), Bova Chen (@appoipp), Aiden X (@4ever9)
Created	2024-01-01
Requires	EIP-4844

摘要
动机
规范
- 元数据 JSON 模式
- Blob 交易信封
理由
安全考虑
版权

摘要

本 EIP 介绍了一种将元数据附加到由 blob 交易携带的 blob 的标准，如 EIP-4844 中所述。元数据表示为符合预定义模式的 JSON 对象，其字符串表示形式放置在 blob 交易的数据字段中。

动机

EIP-4844 定义了一种新型的交易，称为“blob 交易”。这些交易包含一系列 blob 及其 KZG 承诺和证明。 Blob 交易是 rollup 将其 layer 2 交易数据发布到以太坊 layer 1 的一种机制。

虽然 rollup 通常管理自己发布的 blob 交易，但第三方解决方案（如 Portal Network 和 blobscan）也可以索引所有发布到以太坊的 blob，并为 blob 提供查询服务。通过将元数据附加到 blob，例如有关发起者、描述或内容类型的信息，我们可以显著增强这些数据结构的可见性和可审计性。

此外，去中心化存储应用程序可以使用 blob 交易将用户数据发布到以太坊，同步并离线存储 blob 以供将来检索。元数据的包含为新颖的应用程序开辟了可能性，包括铭文和其他创造性用例。

规范

元数据 JSON 模式

元数据表示为符合以下 JSON Schema 的 JSON 对象：

{
    "title": "Blobs Metadata",
    "type": "object",
    "properties": {
        "originator": {
            "type": "string",
            "description": "Identifies the originator of the carried blobs" // 标识携带的 Blob 的发起者
        },
        "description": {
            "type": "string",
            "description": "Describes the contents of the blobs" // 描述 Blob 的内容
        },
        "content_type": {
            "type": "string",
            "description": "Describes the MIME type of the blobs. The MIME type should be defined in RFC 2046 (https://www.rfc-editor.org/rfc/rfc2046)" // 描述 Blob 的 MIME 类型。 MIME 类型应在 RFC 2046 (https://www.rfc-editor.org/rfc/rfc2046) 中定义
        },
        "extras": {
            "type": "string",
            "description": "Dynamic extra information related to the blobs" // 与 Blob 相关的动态额外信息
        },
        "blobs": {
            "type": "array",
            "description": "Metadata of the i'th blob. This is optional and overlays the upper level properties if provided", // 第 i 个 Blob 的元数据。 这是可选的，如果提供，则会覆盖上层属性
            "items": {
                "description": {
                    "type": "string",
                    "description": "Describes the content of the i'th blob" // 描述第 i 个 Blob 的内容
                },
                "content_type": {
                    "type": "string",
                    "description": "Describes the MIME type of the i'th blob. The MIME type should be defined in RFC 2046 (https://www.rfc-editor.org/rfc/rfc2046)" // 描述第 i 个 Blob 的 MIME 类型。 MIME 类型应在 RFC 2046 (https://www.rfc-editor.org/rfc/rfc2046) 中定义
                },
                "extras": {
                    "type": "string",
                    "description": "Dynamic extra information related to the i'th blob" // 与第 i 个 Blob 相关的动态额外信息
                },
            }
        }
    }
}

例如，假设 Vitalik 想要发送一个 blob 交易，其中包含两个解释“数据可用性抽样”的 blob。他可以在第一个 blob 中包含一段文字解释，在第二个 blob 中包含一个插图图像。相应的元数据 JSON 对象如下所示：

{
    "originator": "Vitalik Buterin",
    "description": "An illustration of data availability sampling", // 数据可用性抽样的说明
    "blobs": [
      {
        "content_type": "text/plain",
        "description": "This blob contains a description text of the illustration." // 此 Blob 包含插图的描述性文本。
      },
      {
        "content_type": "image/png",
        "description": "This blob contains the illustration image data in base64 format. It's a RFC 2397 (https://www.rfc-editor.org/rfc/rfc2397) data URL." // 此 Blob 包含 base64 格式的插图图像数据。 这是一个 RFC 2397 (https://www.rfc-editor.org/rfc/rfc2397) 数据 URL。
      },
    ]
  }

完整的 blob 交易将在数据字段中包含此元数据以及其他相关字段：

{
  "blobVersionedHashes": ["0x...", "0x..."],
  "chainId": 11155111, // Supposing the blob transaction is posted to Sepolia // 假设 blob 交易发布到 Sepolia
  "type": "eip4844",
  "to": "0x0000000000000000000000000000000000000000",
  "gas": 28236,
  "data": "0x..", // String representation of the above metadata JSON object // 上述元数据 JSON 对象的字符串表示形式
  "nonce": 18,
  "maxFeePerBlobGas": 1073677089,
  "maxFeePerGas": 1213388073,
  "maxPriorityFeePerGas": 1165808679,
  "sidecars": [
    { "blob": "0x...", "commitment": "0x...", "proof": "0x..." },
    { "blob": "0x...", "commitment": "0x...", "proof": "0x..." }
  ]
}

Blob 交易信封

blob 交易的 calldata（即数据字段）应设置为以 UTF-8 编码的元数据 JSON 对象的字符串表示形式。

理由

在以太坊生态系统中，存在各种类型的交易，每种交易都有不同的用途。这些交易中数据字段的用法各不相同：

常规资金转移交易：在这些交易中，通常不使用数据字段，用户可以选择包含任意数据。
智能合约部署交易：用于部署智能合约。数据字段保存合约字节码以及构造函数所需的任何编码参数。
智能合约函数调用交易：当调用智能合约函数时，数据字段包含函数调用数据，包括函数签名和任何必要的参数。

Blob 交易专门用于发布 blob，通常，数据字段保持未使用状态。本 EIP 提出了一种新颖的方法：利用数据字段将元数据附加到携带的 blob。通过这样做，我们可以增强 blob 交易的可审计性和可用性。

但是，需要注意的是，在某些情况下，blob 交易可能还需要调用智能合约函数。考虑一个去中心化存储应用程序，该应用程序使用智能合约来跟踪 Blob 版本哈希和 MIME 类型等元数据。在这种情况下，用户可以提交一个包含 blob 的 blob 交易，同时使用数据字段来调用智能合约函数以存储这些 blob 的版本哈希和 MIME 类型。重要的是要认识到，本 EIP 不涵盖此类特定用例。

向后兼容性

本 EIP 与 EIP-4844 向后兼容，因为它不修改 blob 交易的结构或功能，而只是向其添加一个可选的元数据字段。

安全考虑

本 EIP 不会引入任何新的安全风险或漏洞，因为元数据只是一个信息字段，不会影响 blob 交易的执行或有效性。但是，用户和应用程序应注意以下潜在问题：

元数据未经过共识层的验证或强制执行，因此它可能不准确或不可信。用户和应用程序不应依赖元数据来进行关键或敏感操作，并且应始终验证 blob 本身的内容和来源。
元数据可能包含恶意或有害数据，例如垃圾邮件、网络钓鱼、恶意软件等。用户和应用程序不应盲目信任或执行元数据，并且应始终在使用元数据之前对其进行扫描和清理。
元数据可能会增加 blob 交易的 gas 成本，因为数据字段中包含更多数据。用户和应用程序应权衡使用元数据的益处和成本，并应优化元数据的大小和格式以降低 gas 成本。

版权

在 CC0 下放弃版权及相关权利。

Citation

Please cite this document as:

Gavin Fu (@gavfu), Leo Wang (@wanglie1986), Bova Chen (@appoipp), Aiden X (@4ever9), "ERC-7588: Blob 交易元数据 JSON 模式," Ethereum Improvement Proposals, no. 7588, January 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7588.