はじめに

『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」で表現されます。 形式は以下のようになります。

text
<protoCode(uvarint)><value(バイト列)>
  • protoCode は使用するプロトコル(例:IPFS, Swarm)を表す識別子です。
  • value の中身はプロトコルによって異なり、たとえばIPFSやSwarmの場合は以下の構造です:
text
<protoCode(uvarint)><cid-version><multicodec-content-type><multihash-content-address>

各要素の役割

  • 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

バイナリ形式

text
0xe3010170122029f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f

テキスト形式(人間可読)

text
ipfs://QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4

Swarmの例

  • ストレージ
    • Swarm (0xe4)
  • CIDバージョン
    • 0x01
  • コンテンツタイプ
    • swarm-manifest (0xfa)
  • ハッシュ関数
    • keccak256 (0x1b)
  • ハッシュ長
    • 32バイト (0x20)
  • ハッシュ値
    • d1de9994...265ea162

バイナリ形式

text
0xe40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162

テキスト形式

text
bzz://d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162

SwarmのCLIでの利用例

bash
$ 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などからお気軽に質問してください!

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