Web3 R&D概念実証② URL所有×IPFS配信（Ethereum/NFT参照解決）

動画はこちら

これは何か

URLをキーにして「所有者アドレス → IPFS CID」を参照できる仕組みを作り、
ブラウザのようにサイトへアクセスしたときにオンチェーン参照（URL→CID） → IPFS取得 → 表示まで成立するかを検証したプロトタイプです。

発想としては「URL（ドメイン/ページ）を参照キーとして扱い、そこに紐づくコンテンツを分散ストレージで配信する」モデルの技術検証です。

目的（何を検証したかったか）

• 既存Webの入口（URL）をキーにして、分散ストレージ上のコンテンツへ参照解決できるか
• オンチェーンには最小のメタデータ（URL・所有者・CID）だけを置き、コンテンツ本体はIPFSに置くという 責務分離が成立するか
• URL単位で「所有者」を定義する制約（1 URL = 1 owner）をスマートコントラクトで表現できるか

全体の挙動（ユーザーフロー）

1. アプリ起動時にIPFSノードとしてネットワーク参加
2. 端末内にEthereumアドレスをロード（存在しなければ新規生成）
3. Google検索をアプリ内Viewに埋め込み、ブラウザのように検索・閲覧
4. 任意のサイトへアクセスすると、初期状態では表示は空（=オンチェーン参照が無い状態）
5. ユーザーがアップロード操作 → コンテンツをIPFSに保存しCIDを取得
6. スマートコントラクトへ URL / address / CID を送信して登録
7. • コントラクト側でURL→（owner address, CID）を保存
   • URLはNFT化（＝所有者が一意になる制約：1 URL = 1 owner）
7. 以後、そのURLへアクセスすると
8. • コントラクトからCIDを参照
   • CIDが存在する場合、IPFSからコンテンツをダウンロードして表示

設計上のポイント

1) オンチェーンは参照情報だけ、コンテンツ本体はIPFS（役割分離）

• オンチェーン：URL / owner address / CID（参照解決のための最小情報）
• IPFS：コンテンツ本体（サイズが大きい/更新頻度が高いデータ）

オンチェーンに大きいデータを載せずに、参照解決の役割に限定することで、設計を整理しました。

2) URLに対して所有者が一意になる制約

「誰でも好き勝手にCIDを上書きできる」状態にしないため、
スマートコントラクト側でURLごとに所有者アドレスを固定する制約を設けました（NFT化）。

この制約により「URLは参照キーであり、所有権はアドレスに紐づく」というモデルを表現しています。

3) ブラウザ体験の形で検証する

Google検索Viewを埋め込み、普段のWeb閲覧フローの中で

• URLにアクセスしたら参照解決して表示される
• 登録されていなければ空
• アップロードすれば登録されて表示される

という一連のUXが成立するかを重視してプロトタイピングしました。

スコープ / 位置づけ

• 技術検証（R&D）のプロトタイプで、一般公開・運用は想定していません
• 思考実験としては面白い一方、社会実装には運用面・悪用面の論点が多いと判断しています

得られたこと

• URL→CIDの参照解決をオンチェーンで担い、実データはIPFSで配信する構成の基本フローを実装
• 制約設計（1 URL = 1 owner）をスマートコントラクトで表現し、ブラウザ風UIで動作確認できた
• オンチェーン/オフチェーン分離設計と、参照キー（URL）を中心としたUXの論点を整理できた