# [ENSIP22] ENSで複数レコードをまとめて解決する仕組みを理解しよう！

> ENSIP22は、ENS（Ethereum Name Service）に関連するコントラクト機能をERC7996として標準化する提案です。

- URL: https://cardene.dev/articles/16813afa4b69fb6979c8
- 公開日: 2025-08-22
- 更新日: 2025-08-22
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

https://amzn.asia/d/gxvJ0Pw

今回は、ENSリゾルバに新しい機能を定義して効率的に複数の情報を取得できる仕組みを提案している**ENSIP22**についてまとめていきます！

:::message
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

https://docs.ens.domains/ensip/22

他にも様々なEIP・BIP・SLIP・CAIP・ENSIPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

**ENSIP22**は、ENS（Ethereum Name Service）に関連するコントラクト機能を**ERC7996**として標準化する提案です。
目的は、新しい最適化を可能にしつつ、すでにデプロイされている既存のコントラクトとの互換性を維持することです。
ENSに特化した機能を明確に定義することで、より効率的で一貫した利用が可能になります。

## 動機

ENSは2016年に登場して以来、常に古いコントラクトとの互換性を維持してきました。
そのために活用されてきたのが**ERC165**という仕組みです。
**ERC165**は、スマートコントラクトが「**どのインターフェース（関数群）をサポートしているか**」を識別できるようにする規格です。
これにより、多様な実装間での互換性が保たれてきました。

:::message
**ERC165**については以下の記事を参考にしてください。
:::

[\[ERC165\] コントラクトが特定のインターフェースをサポートしているか確認する仕組みを理解しよう！](/articles/541184977a5cba51b759)

しかし、コントラクトの持つすべての機能を単一のインターフェースで表現することは不可能です。
例えば、コントラクトに固有の追加機能や特殊な能力は、**ERC165**だけでは十分に表現できません。

そこで登場するのが「**Feature（機能）**」という考え方です。
Featureを使うと、既存のインターフェースを壊すことなく、新しい機能を表現できるようになります。
**ENSIP22**では、その中でもENSプロトコルに関係するFeatureを標準化し、より扱いやすくすることを目的としています。
これにより、ENSの拡張や新機能の導入がスムーズに行え、開発者や利用者が安心して新しい仕組みを活用できるようになります。

## 仕組み

**ENSIP22**は **EIP7996**に基づいて定義される「**コントラクト機能（Contract features）**」の一部として、ENSにおけるリゾルバ（Resolver）が持つべき拡張機能を整理したものです。
リゾルバとは、ENSの名前（例: `vitalik.eth`）を実際のアドレスや他の情報に変換する役割を持つコントラクトです。
**ENSIP22**では、リゾルバがより効率的に動作するための要件と、複数の情報をまとめて取得する仕組みが定められています。

### リゾルバに求められる条件

リゾルバが「**機能（Features）**」をサポートする場合、以下の条件を満たす必要があります。

1. **ERC3668（CCIP-Read）の対応**
    CCIP-Readとは、オンチェーンのリゾルバが必要なデータをオフチェーンから取得する仕組みです。
    リゾルバがこれを使う場合、再帰的な呼び出しに対応できること、さらに外部ゲートウェイがCORS（クロスオリジン・リソースシェアリング）をサポートしている必要があります。

2. **EIP140のサポート**
   リゾルバは、EVM（Ethereum Virtual Machine）で定義されているEIP-140の仕様に基づいてコンパイルされている必要があります。これにより、より確実なエラー処理や実行が保証されます。

:::message
**EIP140**については以下の記事を参考にしてください。
:::

[\[EIP140\] REVERT命令の仕組みいついて理解しよう！](/articles/31e73aaddaa6503332ce)

3. **直接呼び出し可能であること**
    解決に使う入力データ（calldata）がマルチコールでない場合、リゾルバはバッチ処理用の追加ゲートウェイを介さずに直接呼び出すことが可能です。

### 拡張マルチコール機能

この仕様では、ENSリゾルバに新しい機能が追加されます。

```javascript
eth.ens.resolver.extended.multicall — 0x96b62db8
```

リゾルバが `IExtendedResolver` を実装しており、この機能をサポートする場合、`resolve(name, data)` 関数は `multicall(bytes[])` を正しく処理しなければなりません。

これにより、複数のリクエストをまとめて処理することが可能になります。
特にCCIP-Readを利用するリゾルバでは、1回の `OffchainLookup` リクエストで複数のレコードを取得できるようになり、ネットワーク遅延や通信量を大幅に削減できます。

### 実用上のメリット

この拡張機能を持つリゾルバは、常に直接呼び出しが可能であり、バッチ処理のための特別なゲートウェイを必要としません。
結果として、ENSでの名前解決がより高速で効率的になり、ユーザー体験が改善されます。

## 互換性

**ENSIP22**で追加される「**機能（Features）**」は、従来の仕組みを壊すものではありません。
つまり、ENSリゾルバの機能を知らない、あるいは特定の機能を利用しない呼び出し側（コントラクトやアプリケーション）は、今までと同じように動作します。
新しい仕様に対応していないシステムでも、既存の挙動に変更はないため安心して既存の環境で利用し続けることができます。

## セキュリティ

**ERC7996**でも明記されているように、あるコントラクトが「**この機能をサポートしています**」と宣言したとしても、それが実際に正しく実装されている保証にはなりません。
言い換えると、インターフェースや機能のサポートを名乗ること自体は簡単ですが、その機能が本当に期待通りに動くかは別問題です。
したがって、利用する側は「**宣言されているからといって必ず安全に利用できる**」とは考えず、適切な検証や信頼できる実装の利用が重要となります。

## 最後に

今回は「ENSリゾルバに新しい機能を定義して効率的に複数の情報を取得できる仕組みを提案している**ENSIP22**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下の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