# [ERC7588] Blobトランザクションにメタデータを付与するJSON Schema標準化の仕組みを理解しよう！

> ERC7588 とは、EIP4844のBlobトランザクションにメタデータを付与するためのJSON Schema標準を定義した提案です。

- URL: https://cardene.dev/articles/b465e0b4671fd620de44
- 公開日: 2026-03-06
- 更新日: 2026-03-06
- トピック: Blockchain
- タグ: ethereum, smartcontract, ブロックチェーン, erc

## はじめに

初めまして。
『DApps開発入門』という本や色々記事を書いているかるでねです。

https://amzn.asia/d/gxvJ0Pw

以下でも情報発信しているので、興味ある記事があればぜひ読んでみてください！

https://cardene.notion.site/EIP-2a03fa3ea33d43baa9ed82288f98d4a9

https://twitter.com/cardene777

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

今回は、**EIP4844**のBlobトランザクションのdataフィールドにJSON形式でメタデータを格納し、Blobの内容や作成者情報を管理できるようにする仕組みを提案している**ERC7588**についてまとめていきます。

:::message
以下にまとめられているものを解説しながらまとめていきます。
:::

https://eips.ethereum.org/EIPS/eip-7588

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

**ERC7588** とは、**EIP4844**のBlobトランザクションにメタデータを付与するためのJSON Schema標準を定義した提案です。

:::message
**EIP4844**については以下の記事を参考にしてください。
:::

https://qiita.com/cardene/items/f40df7c30a3ad5e20a71

この提案により、Blobトランザクションのdataフィールドに構造化されたメタデータを格納することで、Blobの内容や作成者、MIME型などの情報を統一されたフォーマットで管理できるようになります。
従来、Blobトランザクションのdataフィールドは未使用でしたが、**ERC7588**はこの領域を活用してBlob自体に関する重要な情報を記録する方法を標準化しています。

![Blobトランザクションの構造](/images/qiita-83ad061a-2deb-4b1b-9742-c9909bd7e5e9.webp)

## 動機

この提案が生まれた背景には以下のような課題がありました。

**EIP4844**で定義されたBlobトランザクションは、ロールアップがレイヤー2のトランザクションデータをEthereumのレイヤー1に投稿するためのメカニズムです。これらのトランザクションにはBlobのリストとともに、KZGコミットメントと証明が含まれています。通常、ロールアップは自身が投稿したBlobトランザクションを独自に管理していますが、Portal NetworkやBlobscanなどのサードパーティサービスがEthereumに投稿されたすべてのBlobを索引化し、クエリサービスを提供することもあります。

### Blobの可視性と監査性の不足

**EIP4844**で導入されたBlobトランザクションには、KZGコミットメントと証明は含まれていますが、Blobの内容や作成者に関する情報が不足していました。
Portal NetworkやBlobscanなどのサードパーティサービスがBlobを索引化してクエリサービスを提供する時に、作成者情報、説明、コンテンツタイプなどのメタデータがないため、Blobの可視性と監査性が制限されていました。

### 分散ストレージアプリケーションでの課題

分散ストレージアプリケーションがBlobトランザクションを使用してユーザーデータをEthereumに投稿し、オフチェーンで同期・保存する場合、Blobの内容を特定するための標準的な方法がありませんでした。
これにより、将来的な検索や管理が困難になっていました。

### Inscriptionや創造的ユースケースの制約

メタデータの標準化がないことで、NFTのInscriptionや他の創造的なアプリケーションでBlobを活用する時の互換性や相互運用性が制限されていました。
メタデータを付与することで、Inscriptionやその他の創造的なユースケースへの新たな可能性が開かれます。

## 仕様

### メタデータJSON Schema

メタデータは以下のJSON Schemaに準拠したJSONオブジェクトとして表現されます。

```javascript
{
    "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"
                },
            }
        }
    }
}
```

#### プロパティ詳細

以下の表は、メタデータJSONオブジェクトの各プロパティの詳細な説明です。

| プロパティ | 型 | 説明 |
|-----------|-----|------|
| `originator` | `string` | Blobの作成者を特定する文字列。個人名、組織名、またはサービス名を記録できる。 |
| `description` | `string` | Blob全体の内容を説明する文字列。目的や概要を自由に記述できる。 |
| `content_type` | `string` | BlobのMIMEタイプ。RFC 2046で定義された標準的なMIME型を使用する（`text/plain`、`image/png` など）。 |
| `extras` | `string` | Blobに関連する動的な追加情報。アプリケーション固有のメタデータを格納する時に使用する。 |
| `blobs` | `array` | 個別Blobのメタデータ配列。省略可能で、提供された場合は上位レベルのプロパティを上書きする。 |

#### `blobs`配列内の各項目

| プロパティ | 型 | 説明 |
|-----------|-----|------|
| `description` | `string` | i番目のblobの内容を説明する文字列。全体レベルの`description`を個別blob単位で上書きする時に使用する。 |
| `content_type` | `string` | i番目のblobのMIMEタイプ。RFC 2046で定義された値を使用する（`text/plain`、`image/png` など）。 |
| `extras` | `string` | i番目のblobに関連する追加情報。アプリケーション固有のメタデータを自由に格納できる。 |

### 実装例

Vitalikが「Data Availability Sampling」に関する2つのBlobを含むトランザクションを送信する場合を考えてみます。
最初のBlobにテキスト説明の段落、2番目のBlobにイラスト画像を含める場合のメタデータは以下のようになります。

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

#### 完全なBlobトランザクション例

上記メタデータを含む完全なBlobトランザクションは以下のような構造になります。

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

この例では、`data`フィールドに上記のメタデータJSONオブジェクトの文字列表現がUTF-8エンコードされて格納されています。

### Blobトランザクションエンベロープ

Blobトランザクションのcalldata（dataフィールド）は、メタデータJSONオブジェクトの文字列表現をUTF-8エンコードしたものに設定する必要があります。

#### エンコーディング手順

以下は理解を助けるための補足です。

1. **JSON構築**
   上記スキーマに従ってメタデータJSONを構築する。

2. **文字列化**
   JSONオブジェクトを文字列に変換する。

3. **UTF-8エンコーディング**
   JSON文字列をUTF-8でエンコードしてバイト配列に変換する。

4. **dataフィールドへの設定**
   エンコードしたバイト配列をトランザクションのdataフィールドに設定する。

## 設計理由

この提案のコアアイデアは、通常未使用のdataフィールドをBlobメタデータの格納に活用するという新しいアプローチです。これにより、Blobトランザクションの監査性と使いやすさが向上します。

### dataフィールドの用途比較

Ethereumエコシステムでは、異なるタイプのトランザクションでdataフィールドの使用方法が異なります。

| トランザクション種類 | dataフィールドの用途 |
|-------------------|-------------------|
| 通常の送金トランザクション | 通常は未使用。オプションで任意のデータを含めることが可能。 |
| スマートコントラクトデプロイ | コントラクトのバイトコードとコンストラクタの引数を格納。 |
| スマートコントラクト関数呼び出し | 関数シグネチャとパラメータを含む関数呼び出しデータを格納。 |
| Blobトランザクション | 通常は未使用。**ERC7588**によりメタデータ格納領域として活用。 |

### スマートコントラクト呼び出しとの併用について

Blobトランザクションは本来Blobの投稿専用に設計されており、通常はdataフィールドが使用されていません。**ERC7588**はdataフィールドを活用してBlobにメタデータを付与するという新しいアプローチを提案しており、これによりBlobトランザクションの監査性と使いやすさが向上します。

重要な注意点として、Blobトランザクションがスマートコントラクト関数を呼び出す必要がある場合があります。
例えば、分散ストレージアプリケーションが、Blobのバージョンハッシュやメタデータをトラッキングするスマートコントラクトを使用する場合です。

このような場合、ユーザーはBlobを含むトランザクションを送信すると同時に、dataフィールドを使用してスマートコントラクト関数を呼び出してバージョンハッシュやMIME型を保存できます。

**ERC7588**はこのような特定のユースケースは対象外としており、純粋にメタデータ格納に特化した標準を定義しています。

### ガス費用への影響

メタデータをdataフィールドに含めることで、Blobトランザクションのガス費用が増加する可能性があります。
これは、より多くのデータがdataフィールドに含まれるためです。

ユーザーとアプリケーションは、メタデータ使用の利益とコストのバランスを考慮し、ガス費用を削減するためにメタデータのサイズと形式を最適化する必要があります。

### 実用的なユースケース

**ERC7588**により可能になる具体的なユースケースには以下があります。

- **Blob検索サービスの向上** BlobscanやPortal Networkなどのサービスが、作成者名やコンテンツタイプでBlobを検索できるようになります。
- **分散ストレージの管理** IPFSやArweaveと連携する時に、Blobの内容や形式を事前に特定できます。
- **NFT Inscription** NFTデータをBlobに格納し、メタデータでアートワークの情報を記録できます。
- **データアーカイブ** 学術論文、画像、動画などの大容量データをBlobに保存し、検索可能なメタデータを付与できます。

## 互換性

#### 既存規格との関係

**ERC7588**は**EIP4844**と後方互換性があります。
Blobトランザクションの構造や機能を変更せず、オプションのメタデータフィールドを追加するだけです。
メタデータが存在しないBlobトランザクションも引き続き正常に処理されます。

## セキュリティ

この提案はBlobトランザクションの実行や有効性に影響しない情報フィールドであるため、新たなセキュリティリスクや脆弱性を導入しません。ただし、ユーザーとアプリケーションは以下の点に注意する必要があります。

#### メタデータの信頼性

メタデータはコンセンサスレイヤーで検証や強制されないため、正確性や信頼性が保証されません。

ユーザーとアプリケーションは、重要または機密性の高い操作でメタデータに依存すべきではなく、常にBlob自体の内容とソースを検証する必要があります。
メタデータは補助的な情報として扱い、実際の処理では Blob の内容を直接検証することが重要です。

#### 悪意のあるデータ

メタデータには、スパム、フィッシング、マルウェアなどの悪意のあるまたは有害なデータが含まれる可能性があります。

ユーザーとアプリケーションはメタデータを盲目的に信頼したり実行したりしてはならず、使用前に常にメタデータをスキャンし、サニタイズする必要があります。
特に、`extras`フィールドには任意のデータが格納できるため、適切なバリデーションとサニタイゼーション処理の実装が必要です。

#### ガス費用の増加

メタデータの使用により、dataフィールドにより多くのデータが含まれるため、Blobトランザクションのガス費用が増加する可能性があります。

ユーザーとアプリケーションは、メタデータ使用の利益とコストのバランスを考慮し、ガス費用を削減するためにメタデータのサイズと形式を最適化することが重要です。

#### プライバシーの考慮事項

メタデータはBlobトランザクションとともにオンチェーンに永続的に保存されるため、プライベートまたは機密情報を含めるべきではありません。

`originator`フィールドに個人を特定できる情報を記録する場合は、プライバシーへの影響を慎重に検討する必要があります。

## 引用

https://eips.ethereum.org/EIPS/eip-7588

https://ethereum-magicians.org/t/erc7588-attaching-metadata-to-blobs-carried-by-blob-transactions/17873

https://www.rfc-editor.org/rfc/rfc2046

https://www.rfc-editor.org/rfc/rfc2397

## 最後に

今回は「**ERC7588**によるBlobトランザクションへのメタデータ付与標準化」についてまとめてきました。

この提案は、**EIP4844**のBlobトランザクションの未使用領域を活用して構造化されたメタデータを格納し、Blobの可視性と管理性を大幅に向上させる重要な標準です。
Portal NetworkやBlobscanなどのサービスでの検索機能強化、分散ストレージアプリケーションでのデータ管理、NFT Inscriptionなど、多様なユースケースでの活用が期待されます。

他でも色々記事を書いているのでぜひよろしければ読んでいってください！

https://amzn.asia/d/gxvJ0Pw

https://cardene.notion.site/EIP-2a03fa3ea33d43baa9ed82288f98d4a9

https://zenn.dev/heku

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://twitter.com/cardene777

https://cardene.substack.com/