# [ERC7829] クリエイターのデータを守りながら共有できるNFTの仕組みを理解しよう！

> ERC7829は、既存のトークン規格であるERC721を拡張し、「データ資産」を扱えるようにします。ここでいうデータ資産とは、クリエイターが作ったブログ記事、動画、ミニゲーム、音楽などのデジタル作品のことです。提案の中核は二つあります。

- URL: https://cardene.dev/articles/11ac63fce535f2e8d2cc
- 公開日: 2025-10-31
- 更新日: 2025-10-31
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

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

https://amzn.asia/d/gxvJ0Pw

今回は、データ作品（ブログ・音楽・動画など）を安全に管理しながら、複数人が閲覧・利用できるようにする新しいNFTの仕組みを提案している**ERC7829**についてまとめていきます！

:::message
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

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

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

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

## 概要

**ERC7829**は、既存のトークン規格である**ERC721**を拡張し、「**データ資産**」を扱えるようにします。
ここでいうデータ資産とは、クリエイターが作ったブログ記事、動画、ミニゲーム、音楽などのデジタル作品のことです。
提案の中核は二つあります。
1つは、オンチェーン上のデータ整合性を守るための「**モジュール式データ可用性（Data Availability, DA）レイヤー**」を導入することです。
もう1つは、新しい権限定義として「**リーダー（Reader）**」を追加することです。
1つのトークンに対して複数のリーダーを設定できるため、データが複製され、多くの利用者が同じデータにアクセスできるというデータ資産の性質をそのまま表現できます。

下表は、**ERC7829**で登場する専門用語をあらかじめ整理したものです。

| 用語  | わかりやすい説明   |
| ---------- | ---------- |
| **ERC721**  | EthereumのNFT標準です。各トークンが一意で、同じものと交換できない性質を持ちます。      |
| メタデータ（metadata）   | NFTが指すコンテンツを説明する情報です。ファイルのURL、タイトル、作者などを含みます。     |
| データ可用性（Data Availability, DA） | データが「**存在し、完全で、誰でも検証できる状態**」にあることを保証する仕組みです。ここでは、オンチェーン上でデータの欠損・改ざん・期限切れを検知可能にする役割を指します。 |
| リーダー（Reader） | 作品の「**閲覧権限**」を持つ主体です。所有者（オーナー）とは別に、ひとつのトークンに複数設定できます。        |

この拡張により、オフチェーン保存に起因するデータ消失や改ざん、期限切れによってNFTの実体価値がずれる問題を抑えつつ、データ資産の「**複製しやすさ・多人数が同時に読む**」という性質を価格や権限設計に反映できるようにします。

簡単な構成イメージは以下のとおりです。

```mermaid
flowchart LR
    Creator[クリエイター] -->|発行| NFT[ERC-721拡張トークン]
    NFT -->|参照| DA[モジュール式DAレイヤー]
    DA -->|状態検証: 消失/改ざん/期限| OnChain[スマートコントラクト]
    NFT -->|権限付与| Readers[複数リーダー]
    Readers -->|アクセス| Content[ブログ/動画/音楽などのデータ資産]
```

## 動機

これまでのNFTでは、所有権そのものの希少性が価値の源泉でした。
メタデータに記載されたリンク先のコンテンツがNFTの中身とみなされ、所有者は所有権を第三者へ移転することで価値を換金してきました。
しかし、ガス代（取引手数料）や保管コストが高いため、オンチェーンで扱うには高価値な資産に限られやすく、クリエイターのデータ資産の多くは範囲外になっていました。
特に、ブログや動画、ミニゲーム、音楽といった作品は、品質や作者の知名度、話題性などで価値が決まる一方、単体の取引で高額化しにくいため、既存のNFTには乗りにくかったのです。

さらに、保管コストを抑えるためにコンテンツ本体はオフチェーンや別チェーンに置き、オンチェーンにはリンクだけを保存する運用が一般的でした。
この方式だと、スマートコントラクト側からはリンク先の状態を直接確かめられません。
例えば、データが消えていないか、書き換えられていないか、閲覧期限が切れていないかを判断できないまま、NFT自体はブロックチェーン上に残り、著作権的な権利の売買が市場で続いてしまいます。
結果として、「**実物（データ）の価値**」と「**オンチェーンで取引されるNFTの価値**」にズレが生まれます。

**ERC7829**は、こうしたジレンマを解消するために「**モジュール式のDAレイヤー**」を組み込み、オンチェーンからデータの健全性を扱えるようにします。
あわせて「**リーダー**」という閲覧権限の概念を導入し、1つのトークンに対して複数人が同時にアクセスできる状態を設計に取り込みます。
これは、データ資産が複製可能であるという現実を前提に、所有権と利用権（閲覧権）を分けて価値を広げる発想です。
結果的に、クリエイターは従来の「**所有権の単発売買**」に閉じない収益化パターンを設計でき、利用者は正しく保全されたデータに安心してアクセスできるようになります。

## 関連研究

NFTの完全性を高める既存の提案はいくつもありますが、以下のような限界がありました。
1つは、コンテンツをすべてオンチェーンに保存する方式です。
これは確かに完全性を高めますが、保存コストが非常に高く、結果として「**投機的価値が十分にある高額なデータ**」しか対象にしづらくなります。
もう1つは、信頼できる第三者の「**お墨付き（アテステーション）**」に依存する方式です。
この場合、第三者を信頼しなければならず、中央集権的な信頼の問題が残ります。

**ERC7829**は、データを丸ごとチェーンに載せるのでも、第三者の保証に寄せるのでもなく、モジュール式DAレイヤーで「**データが存在して改ざんされていないか、期限切れではないか**」をチェーンから検知できるようにする点が違いです。
これにより、高コスト化と中央集権的依存の両方を避けつつ、データ資産の実体価値とオンチェーン上の価値を近づけることを狙います。

## 仕様

### 用語

**ERC7829**では、データ資産を以下の3つの要素に分けています。

| 区分   | 内容   | 保存場所       |
| -------------- | -------------- | ----------------------- |
| **ストレージメタデータ（Storage Metadata）**      | コミット情報、サイズ、期限、アップローダーのアドレスを含む。 | ブロックチェーン上のストレージコントラクト   |
| **パーミッションメタデータ（Permission Metadata）** | 所有権・閲覧権（リーダー）・変更可能なアドレスの情報を含む。 | ブロックチェーン上のパーミッションコントラクト |
| **データコンテンツ（Data Content）**  | 実際のアップロードデータ。          | オフチェーンストレージノード       |

これにより、オンチェーンではメタ情報の整合性と権限管理を保証し、オフチェーンでは実際のデータを低コストで保存できます。

### インターフェース

以下は**ERC7829**のインターフェース定義です。

```javascript
interface IERC7829 is IERC721 {
    event UpdateReader(uint256 indexed tokenId, address indexed reader, bool valid);
    
    function setReader(uint256 tokenId, address reader, bool valid) external;
    
    function isReader(uint256 tokenId, address reader) external view returns (bool);
    
    function commitByTokenId(uint256 tokenId) external view returns (bytes);
    
    function sizeByTokenId(uint256 tokenId) external view returns (uint256);
    
    function expireByTokenId(uint256 tokenId) external view returns (uint64);
}
```

#### `UpdateReader`

```javascript
event UpdateReader(uint256 indexed tokenId, address indexed reader, bool valid);
```

NFTのリーダー（閲覧者）が追加・削除された時に発行されるイベント。
このイベントは、特定のNFT（`tokenId`）に対してリーダー（`reader`）が有効化または無効化された時に発行されます。
これにより、閲覧権限の変更をオンチェーンで追跡できます。

**パラメータ**

* `tokenId`
  　対象のデータ資産NFTのID。
* `reader`
  　変更対象のリーダーのアドレス。
* `valid`
  　リーダーの有効・無効状態（true＝有効、false＝無効）。

#### `setReader`

```javascript
function setReader(uint256 tokenId, address reader, bool valid) external;
```

NFTに紐づくリーダーを追加または削除する関数。
指定された`tokenId`に対して、`reader`として指定されたアドレスに閲覧権限を付与（`true`）または削除（`false`）します。
リーダーは読み取りのみ可能で、所有権や転送権限には影響しません。

**引数**

* `tokenId`
  　対象のデータ資産NFTのID。
* `reader`
  　閲覧権限を与える（または削除する）アドレス。
* `valid`
  　リーダーを有効化（true）または無効化（false）するフラグ。

#### `isReader`

```javascript
function isReader(uint256 tokenId, address reader) external view returns (bool);
```

指定したアドレスがリーダーかどうかを確認する関数。
NFTのIDとアドレスを指定して、そのアドレスが閲覧権限を持つかどうかを確認できます。

**引数**

* `tokenId`
  　確認対象のNFTのID。
* `reader`
  　確認対象のアドレス。

**戻り値**

* `bool`
  　リーダーであればtrue、そうでなければfalse。

#### `commitByTokenId`

```javascript
function commitByTokenId(uint256 tokenId) external view returns (bytes);
```

NFTに関連するデータ資産のコミット（ハッシュ）を取得する関数。
コミットは、データコンテンツの整合性を示す暗号的ハッシュ値で、ストレージに保存されるデータと一致していることを確認するために使われます。

**引数**

* `tokenId`
  　対象のNFTのID。

**戻り値**

* `bytes`
  　データ資産のコミット値。

#### `sizeByTokenId`

```javascript
function sizeByTokenId(uint256 tokenId) external view returns (uint256);
```

NFTが示すデータ資産のサイズを取得する関数。
この値は、ストレージにアップロードされたファイルの容量をバイト単位で示します。
データ整合性の検証や証明生成時に使用されます。

**引数**

* `tokenId`
  　対象のNFTのID。

**戻り値**

* `uint256`
  　データサイズ（バイト単位）。

#### `expireByTokenId`

```javascript
function expireByTokenId(uint256 tokenId) external view returns (uint64);
```

データ資産の有効期限を取得する関数。
データが有効である期間をブロックタイムで返します。
期限切れの場合、データ操作（transfer・承認・リーダー設定）はブロックされます。

**引数**

* `tokenId`
  　対象のNFTのID。

**戻り値**

* `uint64`
  　データの有効期限（ブロックタイムスタンプ）。

### メタデータスキーマ

以下は、データ資産NFTのメタデータJSONスキーマです。

```javascript
{
  "title": "Data Asset Metadata",
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "description": "このNFTが表す資産の名前"
    },
    "description": {
      "type": "string",
      "description": "このNFTが表す資産の説明"
    },
    "commit": {
      "type": "string",
      "description": "データリソースを指すコミットハッシュ"
    },
    "size": {
        "type": "integer",
        "description": "データリソースのサイズ"
    },
    "expire": {
        "type": "integer",
        "description": "データリソースの有効期限"
    }
  }
}
```

リーダー（Reader）は読み取り専用であり、transferや承認、リーダー設定の変更を行うことはできません。

NFTの所有者が`transfer`を使ってNFTを別のアドレスに送信した場合以下の処理が実行されます。

- 所有者アドレスは新しいアドレス（例：Bob）に更新されます。
- 承認アドレスは0にリセットされます。
- 既存のすべてのリーダー設定は保持されます。

### 拡張：ストレージコントラクト

**ERC7829**では、NFTメタデータを拡張し、ユーザーがアップロード時に証明書（ストレージノード署名）を付与できるようにしています。
NFTメタデータには、最低限以下を含める必要があります。

* `commit`
* `size`
* `expire`
* `uploader’s address`

実装者は信頼できるストレージシステムおよびモジュラー構造のDAレイヤーを選択するか、自前でデプロイします。

さらに、`transfer`、`approve`、`setReader`を呼び出す時には、現在のブロックタイム（`block.timestamp`）が`expire`より小さいことを確認しなければなりません。
期限が過ぎている場合は操作を中断し、エラーを返します。

### 拡張：ストレージ証明（Storage Proof）

**ERC7829**では、ストレージ証明を用いてデータコンテンツの可用性を保証し、NFTメタデータの正確性、特に`expire`の妥当性を検証します。
推奨技術として**KZG多項式コミットメント（Polynomial Commitment）**が挙げられています。

#### KZG多項式コミットメントの概要

* データを多項式として表現し、初期化時に2つの生成要素を作成。
* データ内容に基づいてコミットメント`C`を生成し、メタデータに記録。
* 検証時にランダム値を使い、証明者が生成する証明`π`を検証者が検証。

#### 複数証明の集約

KZGでは複数の証明を集約して1つの証明にまとめられます。
このとき、すべてのコミットメントを合算して集約コミットメントを作成し、集約証明`π`を検証します。

#### ランダムサンプリングと挑戦機構

証明生成の負荷を減らすため、ランダムにデータを抽出して検証を行います。
そのため、コントラクトは安全な疑似乱数生成機能を提供する必要があります。

#### 楽観的検証（Optimistic Proof）

ガスコスト削減のため、集約コミットメントの完全検証を省略し、`π`のみを検証します。
ただしこの場合、一定期間「**チャレンジ期間**」を設け、誰でも不正を指摘できるようにします。

* チャレンジ成功
    挑戦者に報酬、証明者はペナルティ。
* チャレンジ失敗
    挑戦者がペナルティ、証明者が報酬を得る。

## 補足

![スクリーンショット 2025-10-30 23.09.38.png](/images/qiita-d907f81a-9ec2-47c7-9027-f4c8ec6b9d2a.webp)
https://eips.ethereum.org/EIPS/eip-7829

#### データ資産NFTの整合性

データ資産NFTの整合性を保証するために、**DAレイヤー（Data Availability Layer）**が導入されています。
DAレイヤーは、データの実体（Data Content）をオフチェーンに保管しつつ、その整合性を示すメタデータ（Storage Metadata）をオンチェーンに保存します。
この仕組みにより、データが消失・改ざん・期限切れになっていないかをブロックチェーン上で追跡・検証できます。

DAレイヤーは定期的に「**ストレージ証明（Storage Proof）**」を生成・提出・検証することで、データ資産の健全性を保ちます。

##### ガスコスト最適化のための設計

通常、すべてのデータを厳密に検証すると高額なガスコストが発生します。
そのため本提案では、**楽観的証明（Optimistic Proof）**方式を採用しています。
この方式では、「**すべての証明をその場で完全に検証する**」のではなく、「**一旦正しいと仮定して承認し、後から不正があればチャレンジできる**」ようにします。
これにより、ガス消費を大幅に削減しつつ、データ整合性を維持します。

#### 証明サイクルのワークフロー

DAレイヤーにおける証明（Proof）は、以下の流れで行われます。

```mermaid
sequenceDiagram
    participant Provider as DAプロバイダー
    participant Contract as DAコントラクト
    participant Verifier as DA検証者

    Provider->>Provider: サンプルデータを選択し証明を生成
    Provider->>Provider: 複数の証明を集約し単一の集約証明にまとめる
    Provider->>Contract: 集約証明を提出
    Contract->>Contract: 集約証明を検証
    Verifier->>Verifier: オフチェーンで再検証
    Verifier->>Contract: 不正が見つかれば詐欺証明（Fraud Proof）を提出
    Contract->>Verifier: 不正が認められた場合、報酬を与えペナルティを実行
```

##### 証明生成と集約

1. **DAプロバイダー**は、オフチェーンのデータコンテンツから一部のデータをランダムに抽出して証明を生成します。
2. 生成した複数の証明を「**集約証明（Aggregated Proof）**」にまとめ、**DAコントラクト**へ提出します。
3. コントラクトは提出された集約証明の正当性を確認します。

この仕組みにより、データの可用性を効率的に確認できます。

##### 不正証明メカニズム

証明の検証は一部を「**信頼して先に通す**」方式ですが、不正防止のために詐欺証明（Fraud Proof）メカニズムが備わっています。

1. **DA検証者（Verifier）**は、オフチェーンで集約証明が正しく生成されたかを再検証します。
2. 不正な証明が見つかった場合、検証者は**詐欺証明（Fraud Proof）**を**DAコントラクト**へ提出します。
3. コントラクトは詐欺証明を検証し、問題が確認されれば不正なプロバイダーに罰を与え、検証者に報酬を支払います。

これにより、オンチェーン上の安全性と効率を両立させることができます。

#### リーダー（Reader）

**ERC7829**では、1つのデータ資産NFTに対して複数の「**リーダー（Reader）**」を設定できるようにしています。
リーダーは、所有者とは異なり、データ資産の閲覧権限のみを持つロールです。
これにより、NFTの所有権を移転せずにデータへのアクセスを複数人に開放することができます。

##### デザインの背景と目的

この設計は、データ資産の持つ本質的な特徴に基づいています。

| 特徴  | 説明  |
| --------- | ------- |
| **複製性（Replicability）** | データは品質を損なうことなく何度でも複製・共有が可能です。NFTのメカニズムでこれを管理することで、正規の閲覧者のみがアクセスできる環境を維持します。 |
| **価値増幅（Value Amplification）** | 所有権を保ちながら、複数人に閲覧権限を販売または貸与できるため、資産としての利用価値と市場価値が高まります。  |

これにより、クリエイターはデータ資産を単一販売するのではなく、「**閲覧権の共有**」や「**サブスクリプションモデル**」のような柔軟な収益構造を実現できます。

## 互換性

**ERC721**と互換性があります。

## セキュリティ

データ資産NFTのセキュリティは、ブロックチェーンだけでなくモジュラーデータ層DAにも依存します。
そのため、実施者はモジュラーデータ層DAを慎重に選定する必要があります。

## 引用

Allen Dong (@Allen2730), Lonika Zhang <lonika@memolabs.net>, Steven He <steven@memolabs.net>, "ERC-7829: Data Asset NFT [DRAFT]," Ethereum Improvement Proposals, no. 7829, November 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7829.

## 最後に

今回は「データ作品（ブログ・音楽・動画など）を安全に管理しながら、複数人が閲覧・利用できるようにする新しいNFTの仕組みを提案している**ERC7829**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://chaldene.net/

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

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