はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、ENSにコントラクトの機能（インターフェース）を紐づけて、コントラクトの細かい機能を外部から取得可能にする仕組みを提案しているERC1844についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIPについてまとめています。
概要
ERC1844は、Ethereum Name Service（ENS）の名前やアドレスに対して、関連するコントラクトのインターフェース情報を公開し、それをアプリケーションが発見・利用できるようにする仕組みを定義しています。
ここで言う「インターフェース」とは、特定のコントラクトが提供する機能のことです。 ENSを使って、あるアドレスや名前に関連する機能がどのようなものかを照会できるようにすることで、アプリケーションはそのアドレスが直接実装していない機能であっても、どこでそれが実行可能なのかを知ることができます。
インターフェースは、対象のコントラクト自身が持つ場合もあれば、別のコントラクトが提供していることもあります。 このように柔軟に機能の場所を紐づけられる点がこの提案の特徴です。
動機
これまでEthereumでは、ERC165によって、あるアドレス（コントラクト）が特定のインターフェースを実装しているかどうかを調べることができました。 しかし、それはそのアドレス自身が持つ機能に限られており、他のコントラクトに委任されている機能などは対象外でした。
ERC165については以下の記事を参考にしてください。
実際には、あるコントラクトが持たない機能であっても、別のコントラクトと連携することで提供されている場合があります。 例えば、あるERC20トークンは「アトミックスワップ（同時に複数の資産を交換する機能）」に対応していないかもしれませんが、アトミックスワップ機能を提供する別のコントラクトと組み合わせることで、トークンの名前にその機能を結びつけることができます。
ERC1844を用いれば、ENSに「この名前に関連するスワップ機能はこのアドレスで実装されています」という情報を登録しておくことで、外部アプリケーションはその情報を取得し、正しい機能を持つコントラクトに接続できます。 これにより、名前やアドレスを基点に、よりリッチな機能発見が可能になります。
この機能は、アプリケーションの柔軟性や拡張性を高め、Web3のユーザー体験を向上させる基盤となります。
仕組み
概要
ERC1844では、ENS（Ethereum Name Service）に関連する名前やアドレスに対して、どのスマートコントラクトが特定のインターフェースを実装しているかを問い合わせるための新しい関数 interfaceImplementer を定義しています。
この関数は、ENSの「リゾルバ」と呼ばれる仕組みに新たなプロフィールを追加するもので、指定されたENS名（node）と、インターフェースを一意に識別するID（interfaceID）を引数として受け取り、そのインターフェースを実際に実装しているスマートコントラクトのアドレスを返します。
関数仕様
function interfaceImplementer(bytes32 node, bytes4 interfaceID) external view returns (address);この関数は以下のように動作します。
nodeは、対象となるENS名をハッシュ化した値（namehash）です。interfaceIDは、ERC165形式のインターフェースID（例：0x80ac58cdなど）です。- 戻り値は、そのインターフェースを実装しているコントラクトのアドレスです。もし該当するものがなければ、0アドレス（
address(0)）を返します。
この関数自身もERC165で識別可能なインターフェースとして定義されており、そのインターフェースIDは 0xb8f2bbb4 です。
実装上のルール
戻り値として返されるアドレスは、必ずスマートコントラクトでなければなりません。 EOA（Externally Owned Account：外部アカウント）は認められません。
また、返されたスマートコントラクトは、可能であればERC165に準拠している必要があります。 つまり、自身がどのインターフェースに対応しているかを公開できる形式であることが望ましいとされています。
フォールバック戦略（代替手段）
リゾルバがこの機能を実装する場合、以下のような「フォールバック戦略」を採用することも許可されています。
まず、ユーザーが interfaceImplementer によって明示的に指定したインターフェースに対応するアドレスが存在しない場合、リゾルバは addr() 関数を使って、ENS名に関連付けられている基本のコントラクトアドレスを取得できます。
そして、そのコントラクトが指定されたインターフェースIDに対応しているかどうかを確認し、対応していればそのアドレスを返します。対応していなければ、0 を返します。
この処理中に、対象のコントラクトがエラー（revert）を返した場合でも、リゾルバはエラーをそのまま返すのではなく、必ず 0 を返す必要があります。
適用対象
ERC1844は、ENSにおける「正引き（名前からアドレスへ）」にも「逆引き（アドレスから名前へ）」にも使用可能です。 これにより、名前とアドレスのどちらを起点にしても、関連するインターフェース情報を問い合わせられるようになります。
補足
コントラクトに直接インターフェース情報を持たせる場合の問題点
インターフェースの発見手法として、最も単純な方法は「対象となるコントラクトそのものに、どのインターフェースを実装しているかを返す関数を追加すること」です。 しかし、この実装にはいくつもの問題があります。
まず、各コントラクトは自分自身で対応しているインターフェースの一覧を管理する必要があります。 これは、コードの複雑さを増すだけでなく、誰がその一覧を変更できるかというアクセス制御の仕組みを新たに導入しなければなりません。 特に元々静的でシンプルだったコントラクトにとっては、こうした追加設計が大きな負担になります。
さらに、この機能を実装するには、コントラクト開発時点でその必要性を認識し、設計に組み込む必要があります。 既にデプロイ済みのコントラクトに後からこのような機能を追加することはできません。 これは、ブロックチェーンの不可変性という性質上当然の制約です。
また、インターフェース一覧をコントラクト内部に持つ場合、それは1つの正規リストしか存在できないという構造上の制限もあります。 例えば、ある利用者は「ERC20の基本機能だけを提供する」ことを期待している一方で、別の利用者は「拡張機能も含めて対応しているかどうか」を調べたい場合、そうした視点の違いに柔軟に対応することが難しくなります。
ENSリゾルバを使う利点
このような課題を解決する方法として、ENSリゾルバを利用するアプローチが提案されています。
ENSでは、ある名前（またはアドレス）に対して情報を外部から動的に紐付けることができます。 これにより、元のコントラクトを変更せずに、誰でも後からインターフェース情報を追加・更新できるようになります。
ENSリゾルバを使えば、開発者以外の第三者であっても、「このENS名に関連するインターフェース実装はこのコントラクトにあります」といった情報を登録できます。 例えば、既存のトークンコントラクトが「アトミックスワップ」に対応していない場合でも、関連する別のコントラクトを指定することで、機能の発見性を向上させることができます。
このように、ENSリゾルバを使う方法は、以下の点で従来の「内部に実装を持たせる方法」に比べて、より拡張性と柔軟性に優れています。
- コントラクトの改修不要
- 柔軟なアクセス管理（誰でも登録可能）
- 複数のインターフェースバージョンや実装の併存が可能
引用
Nick Johnson (@arachnid), "ERC-1844: ENS Interface Discovery [DRAFT]," Ethereum Improvement Proposals, no. 1844, March 2019. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1844.
最後に
今回は「ENSにコントラクトの機能（インターフェース）を紐づけて、コントラクトの細かい機能を外部から取得可能にする仕組みを提案しているERC1844」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！
