はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、ENSにプロフィール画像（アバター）を保存・取得できるようにし、Dapp間で同じアバターを共有できるようにする仕組みを提案しているENSIP12についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIP・BIP・SLIP・CAIP・ENSIPについてまとめています。
概要
ENSIP12は、Ethereum Name Service（ENS）におけるアバター画像の扱い方を標準化する提案です。
具体的には、ENSの「avatar」テキストフィールドに保存されるアバターのURI（画像の参照先URL）を取得する方法、利用できるURIの形式（スキーム）、そしてそれをクライアントアプリケーションがどのように解釈して表示すべきかを定義しています。
これにより、ユーザーがENSを通じてプロフィール画像を一貫して利用できる仕組みが整備されます。
動機
ENSのプライマリーネーム（以前はリバースレコードと呼ばれていた）は、Ethereumを基盤とする多くのアプリケーションで「Web3版ユーザー名」として広く使われています。 こうした状況の中で、アプリケーションごとにユーザーがアバター画像を設定するようになり、特にNFTをプロフィール画像（pfp: profile picture）として利用する動きが拡大しました。
しかし、各アプリケーションが独自に管理していると、利用者は毎回プロフィール画像を設定し直さなければならず、アプリ間での一貫性も失われます。 そこで、ENS上にアバター情報を格納する仕組みを導入すれば、ユーザーはENSの1つのレコードに画像情報を登録するだけで、複数のアプリケーションが共通してそのアバターを参照できるようになります。
ENSIP12は、ENSIP5で定義されている「Text Records」を活用し、アバター情報の保存・取得を標準化するものです。 これにより、Web3アプリケーション間でのプロフィール共有が可能になり、ユーザーエクスペリエンスが向上します。
ENSIP5については以下の記事を参考にしてください。
仕様
ENSIP12は、ENS（Ethereum Name Service）を利用してユーザーのアバター画像を統一的に取得する方法を定めています。
ENS名から取得する場合とEthereumアドレスから取得する場合で手順が異なりますが、いずれの場合も「avatar」というテキストフィールドに保存されたURIを参照する仕組みです。
ENS名からの取得
ENS名をもとにアバターURIを取得する場合、クライアントはまず対象のENS名のリゾルバを探し、そのリゾルバに対して以下の呼び出しを行います。
.text(namehash(name), 'avatar')この呼び出しで得られたURIがアバターの参照先となります。 ただし、リゾルバが存在しない場合、呼び出しが失敗（revert）した場合、もしくは空文字が返ってきた場合は「有効なアバターが存在しない」とみなします。
Ethereumアドレスからの取得
Ethereumアドレスをもとにアバターを探す場合は、まずアドレスのリバース解決を行います。 アドレスを小文字の16進数（0xを除いた形式）に変換し、以下の形式でリゾルバを検索します。
<address>.addr.reverseこのリゾルバに対して以下の呼び出しを行います。
.text(namehash('<address>.addr.reverse'), 'avatar')もしここでアバターが取得できない場合は、さらに以下の手順を踏みます。
.name(namehash('<address>.addr.reverse'))を呼び出してENS名を取得する- そのENS名が正しい逆引き（Reverse Record）であることを確認する （ENS名が解決するアドレスと元のアドレスが一致するかを確認する）
- 有効であれば「ENS名からの取得」と同じ手順でアバターURIを探す
これらのどこかで失敗した場合は、アバターが存在しないとみなします。
一般的な形式
アバター情報は必ずURI（統一資源識別子）の形式で保存されている必要があります。 クライアントが認識できないURIスキームの場合、それは「未設定」と同様に扱います。
対応すべき画像形式
最低限、以下の画像フォーマットを扱える必要があります。
- JPEG（image/jpeg）
- PNG（image/png）
- SVG（image/svg+xml）
これ以外の形式にも対応することは可能ですが必須ではありません。
URIの種類
クライアントが対応すべき代表的なURIスキームは以下の通りです。
https
httpsスキームのURIは直接アバター画像を指している必要があります。 HTMLやメタデータなど、間接的な内容を返すことは許可されていません。
ipfs
ipfsスキームも直接アバター画像を参照する必要があります。 クライアントにIPFSの組み込み対応がない場合、URIをIPFSゲートウェイを利用したhttps形式に書き換えて処理できます。
data
dataスキームは、URI自体に画像データを直接埋め込む形式です。 これも直接画像を取得する必要があります。
NFT参照
NFTをアバターとして指定することもできます。 この場合、CAIP22およびCAIP29に従ったURIを利用します。 クライアントは少なくともERC721およびERC1155規格のNFTに対応する必要があります。
NFTのURIを解決する流れは以下の通りです。
- avatarフィールドに記載されたURIからNFTのメタデータURIを取得する
- メタデータURIを解決し、NFTのメタデータ（JSON）を取得する
- メタデータ内の
imageフィールドを参照し、画像URLを得る - その画像URLを解決し、アバター画像として利用する
画像の取得先はhttpsまたはipfsを最低限サポートする必要があります。
さらに、クライアントはNFTが実際にそのユーザーの所有であることを確認する必要があります。 具体的には、ENS名から取得した場合はそのENS名が指すアドレスを、アドレスから取得した場合はそのアドレスを用いてNFTの所有者と照合します。 所有者でない場合、そのURIは無効とみなされます。
例
以下の3つのURIは、すべて同じBAYCトークン0の画像を指しています。
eip155:1/erc721:0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d/0
ipfs://QmRRPWG96cmgTn2qSzjwr2qvfNEuhunv6FNeMFGa9bx6mQ
https://ipfs.io/ipfs/QmRRPWG96cmgTn2qSzjwr2qvfNEuhunv6FNeMFGa9bx6mQこのように、異なるURI形式であっても最終的に同じ画像を取得できる仕組みが整えられています。
最後に
今回は「ENSにプロフィール画像（アバター）を保存・取得できるようにし、Dapp間で同じアバターを共有できるようにする仕組みを提案しているENSIP12」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！
