はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、ENSリゾルバに新しいcontenthashフィールドを導入し、IPFSやSwarmなどの分散型ストレージ上のコンテンツに対するアドレス指定を、統一された形式で行える仕組みを提案しているERC1577についてまとめていきます!
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIPについてまとめています。
概要
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(uvarint)><value(バイト列)>protoCodeは使用するプロトコル(例:IPFS, Swarm)を表す識別子です。valueの中身はプロトコルによって異なり、たとえばIPFSやSwarmの場合は以下の構造です:
<protoCode(uvarint)><cid-version><multicodec-content-type><multihash-content-address>各要素の役割
cid-version- CIDのバージョン(現在は
0x01)
- CIDのバージョン(現在は
multicodec-content-type- コンテンツのタイプ(IPFSなら
dag-pb、Swarmならswarm-manifestなど)
- コンテンツのタイプ(IPFSなら
multihash-content-address- 実際のコンテンツのハッシュ値
アプリケーションは protoCode を見て、どのプロトコルかを判別し、それに対応した解決処理を行う必要があります。
IPFSの例
- ストレージ
- IPFS (
0xe3)
- IPFS (
- CIDバージョン
0x01
- コンテンツタイプ
dag-pb(0x70)
- ハッシュ関数
sha2-256(0x12)
- ハッシュ長
- 32バイト (
0x20)
- 32バイト (
- ハッシュ値
29f2d17b...c7e3f1f
バイナリ形式
0xe3010170122029f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1fテキスト形式(人間可読)
ipfs://QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4Swarmの例
- ストレージ
- Swarm (
0xe4)
- Swarm (
- CIDバージョン
0x01
- コンテンツタイプ
swarm-manifest(0xfa)
- ハッシュ関数
keccak256(0x1b)
- ハッシュ長
- 32バイト (
0x20)
- 32バイト (
- ハッシュ値
d1de9994...265ea162
バイナリ形式
0xe40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162テキスト形式
bzz://d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162SwarmのCLIでの利用例
$ swarm hash ens contenthash d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162
> e40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162フォールバック
content または multihash フィールドを使って既にIPFSやSwarmのハッシュが設定されているENS名については、移行の猶予期間が必要です。
そのため、以下のような手順が定められています。
- リゾルバが
multihashインターフェースをサポートしない場合、その代わりにcontentインターフェースを確認する必要があります。 contentが存在する場合は、アプリケーション側で文脈に応じた解釈を行うことが求められます。- この互換処理は少なくとも 2019年3月31日 までは強制される必要があります。
引用
Dean Eigenmann dean@ens.domains, Nick Johnson nick@ens.domains, "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などからお気軽に質問してください!
他の媒体でも情報発信しているのでぜひ他も見ていってください!

