ENSの名前解決を分担する ens-contracts の設計を読む
ENS プロトコルのコアコントラクト。 DNSResolver = ENS を介して Ethereum ブロックチェーン上で DNS ドメインをホストするための実験的サポートが利用可能です。
ひと目でわかる
- これは何?
- レジストリ、.eth登録、価格オラクル、リゾルバを分離したENS中核コントラクトの構成と導入時の確認点を整理する。
- 誰に向いている?
- ENSの名前管理をSolidityから扱う開発者には、契約の役割とnpm配布物を把握する入口として向いています。採用前には対象ネットワークのアドレス、価格オラクル、commitとrevealの待機条件を実際のデプロイ設定と照合してください。
- 商用利用できる?
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている?
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている?
- 主に TypeScript です(GitHub の言語統計による)。
回答はプロジェクトの GitHub データ(最終同期:2026年9月15日)と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
ENSRegistryが保持する名前の状態
ENSのレジストリは名前解決の起点であり、各ドメインについて所有者、resolver、TTLを記録します。ENS.solはインターフェース、ENSRegistryは中心実装、ENSRegistryWithFallbackは2020年の移行後の実装です。つまり利用側はまず名前からレコード管理者を引き当て、そのresolverに個別の値を問い合わせる構造になります。レジストリ自身がアドレスやテキストをすべて持つ設計ではないため、権限境界を追うときは所有権の変更とresolver側の更新を分けて確認する必要があります。
.eth登録を支えるコントローラ
BaseRegistrarはENSレジストリ内のTLDを所有し、controllerの追加と削除、登録期間の更新、名前所有権の移転、レジストリ上の所有権回収を扱います。controllerは新しい名前を登録し既存名をrenewできますが、既存所有権を変更したり期限を短縮したりはできないとREADMEに記載されています。EthRegistrarControllerはcommitで名前と秘密値のハッシュを先に登録し、待機時間の後にrevealして登録料金を支払う方式です。登録画面を作る場合、この二段階とcommitの有効期限を状態機械として扱うことが要点です。
名前の長さと通貨を決める価格層
価格はcontrollerが参照するoracleに委ねられます。SimplePriceOracleは契約所有者が決めた年額の固定価格を返し、StablePriceOracleは名前の長さとfiat currency oracleを使って価格を設定します。どちらを使うかで管理者権限と価格の変動要因が変わるため、フロントエンドに金額を固定値として埋め込むべきではありません。READMEはSimplePriceOracleの全コンストラクタ条件までは説明していないので、デプロイ済みのABIと設定値を確認し、登録と更新で同じ計算結果になるかをテストしてください。
PublicResolverのEIPプロファイル
PublicResolverは標準的なENS用途向けの汎用resolverです。ABI、単一通貨とマルチコインのアドレス、content hash、任意データ、interface detection、逆引き名、公開鍵、テキストレコードをそれぞれEIPまたはENSIPのプロファイルとして実装します。名前の所有者が対応するENSレコードを更新する権限モデルなので、アプリはresolverのsupportsInterfaceと対象レコードの有無を確認してから書き込むべきです。DNSResolverについては実験的サポートとされ、詳細リンクも古い文書なので、通常機能と同じ確度で扱えません。
npm配布物とリリースを検証する
リポジトリはSolidityソースだけでなく、コンパイル済みJSONコントラクトをnpmパッケージとして提供します。コンパイラがない環境ではnode_modules配下のHardhat artifactを参照できるとREADMEにあります。開発ではbun i、bun run test、bun run pubを使い、Huskyのpre-commitでPrettierを実行します。リリースはstagingからテストネット、メインネットへ進め、semverのタグを付ける流れです。実装を使う前に対象タグのABI、検証済みオンチェーンコード、SafeとCREATE3を含むデプロイ先を突き合わせることが、このリポジトリで先に確認すべき具体的な作業です。
ENSの権限と状態を分けて追う
ENSの登録と解決を組み込む場合、画面の成功表示だけでは処理完了を判断できません。commit transactionが確定したか、待機時間を過ぎたか、revealが同じnameとsecretで送られたかをreceiptとイベントで追跡します。BaseRegistrarの所有者、controller、expiry、ENSRegistryのownerとresolverは別々の状態です。名前を移転した後にresolverレコードが残るか、reclaimがどのregistry状態を直すかも、対象ネットワークの実コントラクトで確認します。L2ReverseRegistrarを使う場合はCREATE3で揃えたアドレスが同じかをチェーンごとに照合し、UniversalSigValidatorへの依存をデプロイ記録に残します。READMEは実際のデプロイ結果を完全な一覧として提示していないため、タグ、ABI、検証済みコード、イベントログを一組にして扱う必要があります。
登録フローを失敗経路まで試す
登録前に名前のhashとsecretを作り、commitの最短待機と期限切れをそれぞれ再現します。期限外のreveal、料金不足、既存名のrenewを別ケースにし、transaction receiptのstatusとイベントを保存します。resolver更新ではname ownerとresolver ownerが一致しない場合の拒否を確認し、addr、text、contenthashの各レコードを読み書きします。SimplePriceOracleとStablePriceOracleを差し替えたときに表示価格と実支払額が一致するかを比較します。これらのテストを対象タグのartifactで実行すれば、npmのABIとオンチェーン契約の不一致も見つけやすくなります。
ABIとアドレスを固定する
npmのcompiled JSONとSolidity importを同じタグで揃え、BaseRegistrar、EthRegistrarController、PublicResolverのABI差分を比較します。対象チェーンのアドレス、owner、expiry、resolverを読み、commitとrevealの待機条件をテストします。DNSResolverはexperimentalと記載されるため、通常のresolver機能と分けて採用可否を決めます。実施記録には対象版と入力条件を残し、成功した結果だけでなく失敗した場合の出力も保存します。設定を変更した前後で同じ確認を繰り返せるようにし、READMEに書かれた機能と自分の環境で確認できた事実を分けます。採用判断では、導入できたかだけでなく、更新、障害、切り戻し、権限、ライセンスを同じ担当者が追跡できるかを確かめます。 登録料金はoracleの設定から計算され、renewは所有者以外も呼べるとREADMEにあります。利用者の権限とcontrollerの権限を同じ画面で扱わず、名前の所有権、期限、resolverレコードを個別に表示します。
編集部の結論
ENSの名前管理をSolidityから扱う開発者には、契約の役割とnpm配布物を把握する入口として向いています。採用前には対象ネットワークのアドレス、価格オラクル、commitとrevealの待機条件を実際のデプロイ設定と照合してください。
コミュニティノート