ERC-7588 Blob Transaction Metadata Standard (Blob Transactions Metadata JSON Schema)
Final · Other · created 2024-01-01
Defines a way to write information such as the blob's author, description, and file format as JSON in the data field of a blob transaction. Blob lookup services and storage apps can then easily understand the contents of a blob.
Why it is needed
A blob is a large bundle of data introduced by EIP-4844, used mainly by rollups to post layer 2 transaction records to Ethereum. However, a blob itself has no place to describe what its contents are. This is not a problem for rollups, which manage the blobs they post themselves, but for third parties such as the Portal Network or blobscan, which collect and index every blob posted so far and provide search services, it is hard to tell who posted what. Distributed storage apps that post user data through blob transactions, keep it off-chain, and retrieve it later also need a way to mark the type of the data. If information such as author, description, and file format can be attached to a blob, the visibility and auditability of blobs improve greatly, and the way opens for new uses such as inscriptions.
In depth
Metadata JSON schema
The metadata is an object that follows a defined JSON schema. originator is a string identifying the entity that created the blob, and description is a description of the blob's contents. content_type is the MIME type of the blob and must use the format defined in RFC 2046. extras holds dynamic additional information related to the blob. blobs is an array holding the metadata of the i-th blob. It is optional, and if provided it overlays the parent properties. Each entry in the array can hold the description, content_type, and extras of that blob, so a different description and format can be marked for each blob.
Two-blob example
The original text gives an example of posting two blobs that explain data availability sampling. In the metadata, originator is Vitalik Buterin, the overall description describes the picture, and in the blobs array the first blob is marked as a descriptive text with content_type text/plain, and the second blob as an image with content_type image/png. It explains that the image data of the second blob is carried as a base64 RFC 2397 data URL. When blobs of different natures are mixed in one transaction like this, the blobs array describes each of them.
Encoding of the data field
The string representation of the metadata JSON object is encoded as UTF-8 and put in the blob transaction's calldata, that is, the data field. The rest of the transaction structure stays exactly as in EIP-4844. In the example transaction in the original text, type is eip4844, blobVersionedHashes holds the versioned hash of each blob, sidecars holds the blob body (blob), the KZG commitment, and the proof, and blob fee fields such as maxFeePerBlobGas are also included. This standard uses only the data field, which is normally empty.
Why use the data field
The use of the data field differs by Ethereum transaction type. A plain transfer usually does not use data, a contract deployment transaction carries bytecode and constructor arguments, and a function call transaction carries the function signature and parameters. Because a blob transaction is for posting blobs, its data field is normally empty, and this proposal puts metadata in that empty space. However, there are cases where a blob transaction must call a contract function. For example, a distributed storage app may call a function through the data field to record a blob's versioned hash and MIME type in a contract, and this EIP does not cover that kind of usage.
Compatibility with EIP-4844
This standard does not change the structure or function of blob transactions and only adds an optional metadata field, so it is backward compatible with EIP-4844. The metadata is a purely informational field that does not affect transaction execution or validity, and the consensus layer neither verifies nor enforces its contents. Therefore existing blob transactions that do not follow this standard remain valid, and tools that do not read the metadata are unaffected. The status of this proposal is finalized as Final.
Things to watch out for
- Metadata is not verified: The consensus layer neither checks nor enforces the metadata, so its contents may be inaccurate or false. Do not rely on metadata for important or sensitive operations, and always check the contents and origin of the blob yourself.
- Malicious content may come in: Metadata can carry harmful data such as spam, phishing, or malware. Do not trust or execute metadata as is, and inspect and sanitize it before use.
- Gas costs may increase: As the amount of data in the data field grows, the gas cost of a blob transaction can grow. Weigh the benefit against the cost and optimize the size and format of the metadata.