Standards Track: ERC

ERC-7588: Blob Transactions Metadata JSON Schema

Attaching metadata to blobs carried by blob transactions

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

Abstract
Motivation
Specification
- Metadata JSON Schema
- Blob Transaction Envelope
Rationale
Security Considerations
Copyright

Abstract

This EIP introduces a standard for attaching metadata to blobs carried by blob transactions, as outlined in EIP-4844. The metadata is represented as a JSON object adhering to a predefined schema, and its string representation is placed in the data field of the blob transaction.

Motivation

EIP-4844 defines a new type of transaction known as a “blob transaction.” These transactions contain a list of blobs along with their KZG commitments and proofs. Blob transactions serve as a mechanism for rollups to post their layer 2 transaction data to Ethereum layer 1.

While rollups typically manage their own posted blob transactions, third-party solutions (such as Portal Network and blobscan) may also index all blobs ever posted to Ethereum, and provide querying services for blobs. By attaching metadata to blobs, such as information about the originator, a description, or content type, we can significantly enhance the visibility and auditability of these data structures.

Furthermore, decentralized storage applications may utilize blob transactions to post user data to Ethereum, sync and store the blobs off-chain for future retrieval. The inclusion of metadata opens up possibilities for novel applications, including inscriptions and other creative use cases.

Specification

Metadata JSON Schema

The metadata is represented as a JSON object adhering to the following JSON Schema:

{
    "title": "Blobs Metadata",
    "type": "object",
    "properties": {
        "originator": {
            "type": "string",
            "description": "Identifies the originator of the carried blobs"
        },
        "description": {
            "type": "string",
            "description": "Describes the contents of the blobs"
        },
        "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)"
        },
        "extras": {
            "type": "string",
            "description": "Dynamic extra information related to the blobs"
        },
        "blobs": {
            "type": "array",
            "description": "Metadata of the i'th blob. This is optional and overlays the upper level properties if provided",
            "items": {
                "description": {
                    "type": "string",
                    "description": "Describes the content of the i'th 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)"
                },
                "extras": {
                    "type": "string",
                    "description": "Dynamic extra information related to the i'th blob"
                },
            }
        }
    }
}

For example, suppose Vitalik wants to send a blob transaction carrying two blobs explaining “data availability sampling.” He could include a paragraph of textual explanation in the first blob and an illustration image in the second blob. The corresponding metadata JSON object would look like this:

{
    "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."
      },
      {
        "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."
      },
    ]
  }

The complete blob transaction would include this metadata in the data field, along with other relevant fields:

{
  "blobVersionedHashes": ["0x...", "0x..."],
  "chainId": 11155111, // Supposing the blob transaction is posted to Sepolia
  "type": "eip4844",
  "to": "0x0000000000000000000000000000000000000000",
  "gas": 28236,
  "data": "0x..", // String representation of the above metadata JSON object
  "nonce": 18,
  "maxFeePerBlobGas": 1073677089,
  "maxFeePerGas": 1213388073,
  "maxPriorityFeePerGas": 1165808679,
  "sidecars": [
    { "blob": "0x...", "commitment": "0x...", "proof": "0x..." },
    { "blob": "0x...", "commitment": "0x...", "proof": "0x..." }
  ]
}

Blob Transaction Envelope

The blob transaction’s calldata (i.e., the data field) should be set to the string representation of the metadata JSON object, encoded in UTF-8.

Rationale

In the Ethereum ecosystem, various types of transactions exist, each serving different purposes. The usage of the data field within these transactions varies:

Regular Funds Transfer Transactions: In these transactions, the data field is typically not used, and users may optionally include arbitrary data.
Smart Contract Deployment Transactions: For deploying smart contracts. The data field holds the contract bytecode and any encoded arguments required by the constructor.
Smart Contract Function Call Transactions: When invoking smart contract functions, the data field contains the function call data, including the function signature and any necessary parameters.

Blob transactions are specifically designed for posting blobs, and normally, the data field remains unused. This EIP proposes a novel approach: utilizing the data field to attach metadata to the carried blobs. By doing so, we can enhance the auditability and usability of blob transactions.

However, it’s essential to note that there are scenarios where blob transactions may also need to call smart contract functions. Consider a decentralized storage application that employs a smart contract to track blob versioned hashes and metadata like MIME types. In such cases, users could submit a blob transaction containing blobs while simultaneously using the data field to invoke smart contract functions to store versioned hashes and MIME types of those blobs. It’s important to recognize that this EIP does not cover such specific use cases.

Backwards Compatibility

This EIP is backward compatible with EIP-4844, as it does not modify the structure or functionality of blob transactions, but only adds an optional metadata field to them.

Security Considerations

This EIP does not introduce any new security risks or vulnerabilities, as the metadata is only an informational field that does not affect the execution or validity of blob transactions. However, users and applications should be aware of the following potential issues:

The metadata is not verified or enforced by the consensus layer, and therefore it may not be accurate or trustworthy. Users and applications should not rely on the metadata for critical or sensitive operations, and should always verify the contents and sources of the blobs themselves.
The metadata may contain malicious or harmful data, such as spam, phishing, malware, etc. Users and applications should not blindly trust or execute the metadata, and should always scan and sanitize the metadata before using it.
The metadata may increase the gas cost of blob transactions, as more data is included in the data field. Users and applications should balance the benefits and costs of using the metadata, and should optimize the size and format of the metadata to reduce the gas cost.

Copyright

Citation

Please cite this document as:

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