# [ERC1577] ENSドメインでIPFSやSwarmのコンテンツにアクセスする仕組みを理解しよう！ > ERC1577では、ENS（Ethereum Name Service）のリゾルバに新しいフィールド contenthash を導入することを提案しています。 - URL: https://cardene.dev/articles/4b0a25d33edd2f894259 - 公開日: 2025-06-01 - 更新日: 2025-06-01 - トピック: Blockchain - タグ: ethereum, solidity, smartcontract, ブロックチェーン ## はじめに 『DApps開発入門』という本や色々記事を書いているかるでねです。 https://amzn.asia/d/gxvJ0Pw 今回は、ENSリゾルバに新しい`contenthash`フィールドを導入し、IPFSやSwarmなどの分散型ストレージ上のコンテンツに対するアドレス指定を、統一された形式で行える仕組みを提案している**ERC1577**についてまとめていきます！ :::message 以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。 ::: https://eips.ethereum.org/EIPS/eip-1577 他にも様々なEIPについてまとめています。 https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4 ## 概要 **ERC1577**では、ENS（Ethereum Name Service）のリゾルバに新しいフィールド `contenthash` を導入することを提案しています。 これにより、ENSドメインをネットワーク上のコンテンツアドレスにより明確にマッピングできるようになります。 また、従来使用されていた `content` および `multihash` フィールドは非推奨（deprecated）とされます。 `contenthash` を用いることで、IPFSやSwarmといった分散型ストレージへのリンク情報を統一的な方法で記述できるようになります。 ## 動機 Metamask や Status などのウォレットやモバイルクライアントは、ENSドメインを使ってIPFSやSwarmなどの分散型ストレージ上のコンテンツにアクセスする機能を持ち始めています。 しかし、分散型ストレージはアドレス指定の形式がそれぞれ異なるため、統一的な解決方法が存在しませんでした。 そのため、アプリケーションがどのように名前を解決するか、またドメイン所有者が自分のコンテンツがどのように扱われるかを明確にするためには標準化が必要です。 この `contenthash` フィールドの導入によって、ENSを利用した分散型コンテンツ参照の信頼性と予測可能性が向上します。 ## 仕様 ### `contenthash` フィールドの導入 **ERC1577**では、ENS（Ethereum Name Service）のリゾルバに新たに `contenthash` フィールドが導入されます。 これにより、さまざまな分散ストレージプロトコル（IPFSやSwarmなど）に対応するアドレス情報を統一的に管理できます。 リゾルバが `contenthash` をサポートしているかどうかは、`supportsInterface` 関数に引数 `0xbc1c58d1` を渡して `true` を返すかどうかで判別できます。 従来の `content` フィールドおよび `multihash` フィールドは非推奨とされます。 ### `contenthash` のフォーマット `contenthash` フィールドの値は、マシンが解釈可能な形式「`multicodec`」で表現されます。 形式は以下のようになります。 ``` ``` * `protoCode` は使用するプロトコル（例：IPFS, Swarm）を表す識別子です。 * `value` の中身はプロトコルによって異なり、たとえばIPFSやSwarmの場合は以下の構造です： ``` ``` ### 各要素の役割 * `cid-version` * CIDのバージョン（現在は `0x01`） * `multicodec-content-type` * コンテンツのタイプ（IPFSなら `dag-pb`、Swarmなら `swarm-manifest` など） * `multihash-content-address` * 実際のコンテンツのハッシュ値 アプリケーションは `protoCode` を見て、どのプロトコルかを判別し、それに対応した解決処理を行う必要があります。 ### IPFSの例 * ストレージ * IPFS (`0xe3`) * CIDバージョン * `0x01` * コンテンツタイプ * `dag-pb` (`0x70`) * ハッシュ関数 * `sha2-256` (`0x12`) * ハッシュ長 * 32バイト (`0x20`) * ハッシュ値 * `29f2d17b...c7e3f1f` #### バイナリ形式 ``` 0xe3010170122029f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f ``` #### テキスト形式（人間可読） ``` ipfs://QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4 ``` ### Swarmの例 * ストレージ * Swarm (`0xe4`) * CIDバージョン * `0x01` * コンテンツタイプ * `swarm-manifest` (`0xfa`) * ハッシュ関数 * `keccak256` (`0x1b`) * ハッシュ長 * 32バイト (`0x20`) * ハッシュ値 * `d1de9994...265ea162` #### バイナリ形式 ``` 0xe40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 ``` #### テキスト形式 ``` bzz://d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 ``` #### SwarmのCLIでの利用例 ```bash $ swarm hash ens contenthash d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 > e40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 ``` ### フォールバック `content` または `multihash` フィールドを使って既にIPFSやSwarmのハッシュが設定されているENS名については、移行の猶予期間が必要です。 そのため、以下のような手順が定められています。 * リゾルバが `multihash` インターフェースをサポートしない場合、その代わりに `content` インターフェースを確認する必要があります。 * `content` が存在する場合は、アプリケーション側で文脈に応じた解釈を行うことが求められます。 * この互換処理は少なくとも 2019年3月31日 までは強制される必要があります。 ## 引用 Dean Eigenmann , Nick Johnson , "ERC-1577: contenthash field for ENS [DRAFT]," Ethereum Improvement Proposals, no. 1577, November 2018. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1577. ## 最後に 今回は「ENSリゾルバに新しい`contenthash`フィールドを導入し、IPFSやSwarmなどの分散型ストレージ上のコンテンツに対するアドレス指定を、統一された形式で行える仕組みを提案している**ERC1577**」についてまとめてきました！ いかがだったでしょうか？ 質問などがある方は以下の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