ENSv2の徹底解説

はじめに

Ethereum Name Service（ENS）は、2017年のローンチ以来、単なるオンチェーンのネーミングツールから、インターネットの基盤を支える重要なコンポーネントへと進化してきました。ENS Labsはこの度、ENSをLayer 2（L2）に拡張する「ENSv2」を提案します。本記事では、ENSv2の技術的詳細とその意義について、現時点で最も詳細かつ包括的に解説します。

1. ENSv2の概要

1.1 ENSv2とは？

ENSv2は、既存のENSプロトコルを単にEthereumメインネットからL2ネットワークへ移行するだけでなく、過去7年間に培ったWeb3ネーミングの知見を活用し、アーキテクチャを根本から再構築するプロジェクトです。これにより、ENSはより分散化を深め、新たなユースケースや統合、可能性を追求することが可能となります。

1.2 ENSv2の目的

• 分散化の強化：ENSv2は、プロトコルの分散化を更に推進し、中央集権的な制約を排除します。
• 新たなユースケースの開拓：L2の活用により、従来のEthereumメインネットでは制約されていた新しい機能や統合が可能となります。
• ガスコストの削減：L2への移行により、.ethの登録および更新にかかるガス費用を大幅に削減します。

2. ENSの進化とENSv2の必要性

2.1 ENSの歴史と現状

ENSは、ドメインネームシステム（DNS）とブロックチェーン技術を融合させた分散型のネーミングサービスとして、数百万の.ethドメインが登録され、数千のdApps、ウォレット、ブラウザと統合されています。主要な統合例として、Coinbase、GoDaddy、Uniswap、Farcaster、Boxが挙げられます。

2.2 現行の課題

• スケーラビリティ：Ethereumメインネットのブロックスペース需要増加に伴い、登録や更新のコストが上昇。
• コスト効率：ガス費用の増加により、ユーザーの負担が増大。
• 機能制約：メインネット上の制約により、新たな機能や統合が難しい。

2.3 Layer 2ソリューションの台頭

Ethereumの進化と共に、L2ソリューションが登場し、取引速度の向上とガスコストの削減を実現しています。ENSはCCIP-ReadやEVM Gatewayといった内部イノベーションを通じて、これらのL2への対応を先導してきました。

3. ENSv2の主要な改良点

3.1 ガスコストの削減

ENSv2では、.ethの登録および更新をL2ネットワークに移行することで、ガス費用を劇的に削減します。これにより、ユーザーはより経済的にドメインを管理できるようになります。また、取引速度も向上し、ユーザー体験が改善されます。

3.2 コントロールとカスタマイズの強化

ENSv2は階層型レジストリシステムを採用し、各.eth名が独自のレジストリを持つことで、ユーザーに対して名前の所有権管理における柔軟性を提供します。これにより、名前のサブドメイン管理やカスタマイズが容易になります。

3.3 マルチチェーンの相互運用性の向上

L2上のENSは、CCIP-Read Gatewayと互換性のあるリゾルバを組み合わせることで、.eth名が複数のブロックチェーン間で信頼性高く接続されます。これにより、異なるチェーン間でのスムーズな統合が可能となります。

4. 技術的詳細

4.1 階層型レジストリシステム

ENSv2の中心的な改良点の一つが、階層型レジストリシステムの導入です。これにより、各.eth名が個別のレジストリを持ち、サブドメインやリゾルバの管理がユーザー自身に委ねられます。この設計により、名前の所有権管理が分散化され、柔軟性が向上します。

階層型レジストリの構造：

• ルートレジストリ：トップレベルの.ethドメインを管理。
• サブレジストリ：各.ethドメインが独自のレジストリを持ち、サブドメインの管理を担当。
• リゾルバ：ドメイン名の解決を担当し、各レジストリからのデータを統合。

この構造により、ドメインの管理がより細分化され、特定のサブドメインに対する権限の委譲が容易になります。

4.2 Universal Resolverの更新

ENSv2では、Universal Resolverが更新され、解決プロセスの効率化とユーザーおよび開発者にとっての利便性が向上します。新しいUniversal Resolverは、L2とL1の両方で動作し、必要に応じて名前をL2に移動させるオプションを提供します。

Universal Resolverの機能拡張：

• クロスチェーン対応：複数のL2ネットワークおよびL1メインネットとの連携。
• 動的リゾルバ選択：最適なリゾルバを自動的に選択し、効率的な名前解決を実現。
• セキュリティ強化：リゾルバ間の整合性チェックを強化し、不正な名前解決を防止。

4.3 CCIP-Read GatewayとEVM Gateway

ENSv2は、CCIP-Read GatewayとEVM Gatewayを活用し、L2ネットワーク上での名前解決を強化します。これにより、異なるブロックチェーン間での信頼性の高い接続が可能となり、ENSのマルチチェーン対応が実現します。

CCIP-Read Gatewayの役割：

• データフェッチ：L2上のデータを効率的に取得し、L1と連携。
• データ整合性：クロスチェーン間でのデータ整合性を確保。

EVM Gatewayの機能：

• EVM互換性の維持：既存のEthereumスマートコントラクトとの互換性を維持しつつ、L2上での高速な処理を実現。
• プロトコル間通信：異なるEVMベースのネットワーク間でのシームレスな通信をサポート。

5. L2選定フレームワーク

5.1 選定基準

ENSv2のL2選定にあたり、ENS Labsは包括的な選定フレームワークを策定しました。このフレームワークは、以下の3つの要件と9つの評価基準から構成されます。

要件

1. EVM互換性：L2ネットワークは、VitalikのTaxonomyによるType-4以上のEVM互換性を持つ必要があります。
2. 検閲抵抗性と分散化：L2は、シーケンサーの検閲抵抗性と分散化に向けた確かな道筋を持っている必要があります。
3. オープンソース：すべての重要なL2インフラストラクチャは、OSSライセンスの下で公開されている必要があります。

評価基準

1. 最終性と状態更新：トランザクションがL1にコミットされるまでの時間や最終性までの時間を評価。高速なコミットと最終性は、ユーザー更新とクライアントでの反映速度を向上させます。
2. セキュリティと耐障害性：不正証明の可用性やセキュリティ監査の頻度・徹底度を評価。ENSが安全に運用されるための基盤を確保します。
3. パフォーマンスとスケーラビリティ：トランザクションのスループット、確認時間、ガスコスト、スケーラビリティのロードマップを評価。
4. 分散化とガバナンス：ガバナンスモデルとENSがガバナンスの独立性を維持できるかを評価。ENSの価値観と目標に合致することが重要です。
5. 相互運用性とコンポーザビリティ：L2ネットワークのクロスチェーン互換性と標準化インターフェースの採用状況を評価。Ethereumエコシステムとの相互運用性を促進します。
6. 開発者体験とツール：開発者ツール、ドキュメント、サポートリソースの充実度と開発コミュニティの強さを評価。
7. 採用とネットワーク効果：既存プロジェクト、パートナーシップ、特定の技術スタックへの参加によるENSの採用と利便性への影響を評価。
8. カスタマイズとENS特有の機能：L2ネットワークがENS特有の要件を満たす能力を評価。
9. 運用および経済的考慮事項：技術サポートの質、運用オーバーヘッド、手数料、長期的な持続可能性とL2ネットワーク上でのENS運用の経済性を評価。

5.2 選定プロセス

この選定フレームワークに基づき、ENS Labsは複数のL2ネットワークを評価・比較し、最適なプラットフォームを選定します。選定結果は、ENSコミュニティおよびガバナンスフォーラムで公開され、透明性の高いプロセスが保証されます。

6. L2オプションの詳細分析

ENSv2のL2移行にあたり、ENS Labsは以下の3つの主要なオプションを検討しています。それぞれのオプションについて、技術的な利点と課題を詳細に分析します。

6.1 ZKパブリックチェーン

概要：
既存のZKパブリックチェーン（例：Scroll、Taiko）に直接ENSを拡張するオプションです。また、ZK証明機能を持つOptimistic L2（例：SuccinctのFrontiersでのデモ）を活用することも検討しています。

利点：

• 開発負担の軽減：既存のチェーンを活用するため、独自のチェーンを開発・維持する必要がありません。
• コミュニティとエコシステムの活用：既存のパブリックチェーンのコミュニティやツールを活用できる。

課題：

• ガバナンスの独立性の低下：パブリックチェーンのガバナンスに依存するため、ENSのガバナンス独立性が一部制約される可能性があります。
• カスタマイズの制限：既存のチェーンの仕様に依存するため、特定のカスタマイズが難しい場合があります。

6.2 独自ZKチェーンインスタンス

概要：
既存のZKチェーンスタック（例：Linea）を基に、ENS専用のZKチェーンインスタンスをデプロイするオプションです。StatusがLineaスタックを用いて独自インスタンスを立ち上げた事例に基づきます。

利点：

• 柔軟性の向上：独自のチェーンを運用することで、ENSの特定の要件に合わせたカスタマイズが可能。
• 技術的独立性の確保：パブリックチェーンの影響を受けず、ENS独自のガバナンスを維持可能。

課題：

• 開発および運用コストの増加：独自チェーンの開発、デプロイ、維持には多大なリソースが必要。
• セキュリティの確保：独自チェーンのセキュリティを確保するために、追加のセキュリティ監査とプロトコル開発が必要。

6.3 zkVM（特化型ロールアップ）

概要：
ENSの操作に特化して最適化されたカスタムzkVM（Zero-Knowledge Virtual Machine）を開発するオプションです。Axiomとの協力により、zkVMプロトタイプの開発を進めています。

利点：

• 効率的なZK統合：特化型VMにより、ZK証明の生成コストを削減し、最終性時間を短縮。
• 高性能：ENS特有の操作に最適化されているため、パフォーマンスが向上。

課題：

• 開発の複雑性：完全に新しいVMの開発には、技術的な挑戦とリソースが必要。
• 移行の困難さ：既存のENSアーキテクチャからの大幅な変更が必要となり、移行プロセスが複雑化。

7. 最終選定と推奨

ENS Labsは、上記のオプションを詳細に評価し、選定フレームワークに基づいて最適なL2ソリューションを決定します。選定プロセスでは、技術的な適合性、セキュリティ、スケーラビリティ、開発コスト、ガバナンスの独立性など、多岐にわたる要素を総合的に考慮します。最終的な推奨は、コミュニティおよびガバナンスフォーラムで発表され、透明性の高い形で共有されます。

8. マイグレーション計画

8.1 フェーズ別移行

ENSv2への移行は、DApps、ウォレット、ユーザーへの影響を最小限に抑えるため、段階的に進行します。以下のフェーズに分けて実施されます。

フェーズ1：解決プロセスの変更

• L2対応リゾルバの実装：新しいリゾルバをL2ネットワーク上に展開し、L2上での名前解決を可能にします。
• クロスチェーンブリッジの設定：L1とL2間でのデータ通信を確立し、ユーザーがシームレスに名前を管理できるようにします。

フェーズ2：レジストリの移行

• 階層型レジストリの導入：各.eth名に対して個別のレジストリを設定し、サブドメインの管理を分散化します。
• データ移行ツールの提供：ユーザーが既存の.eth名をL2に移行するためのツールを提供し、スムーズな移行を支援します。

フェーズ3：完全移行と最適化

• L2上での完全運用開始：L2ネットワーク上でのENS運用を正式に開始し、ユーザーの大部分がL2を利用するよう促進します。
• 最適化とフィードバックの反映：ユーザーからのフィードバックを基に、プロトコルの最適化を継続的に行います。

8.2 既存名の維持

既存の.eth名は引き続き無期限に機能し、ENS名の不変性に依存するアプリケーションは変更を必要とせずに運用を継続できます。ただし、これらの名前はENSv2が提供する新機能の一部を利用できない点に留意が必要です。

8.3 技術的移行のサポート

• スマートコントラクトのアップグレード：ENSのスマートコントラクトをL2対応にアップグレードし、新機能を有効化します。
• 開発者向けドキュメントの提供：開発者が新しいアーキテクチャに対応するための詳細なドキュメントとサンプルコードを提供します。
• テストネットの活用：本番環境に移行する前に、テストネット上でENSv2の機能を徹底的にテストし、バグやセキュリティホールを排除します。

9. セキュリティとガバナンス

9.1 セキュリティ強化策

ENSv2の移行に際して、セキュリティは最優先事項です。以下の強化策を講じます。

• 多層防御アプローチ：スマートコントラクトの監査、リゾルバのセキュリティテスト、クロスチェーンブリッジの検証を通じて、多層的なセキュリティを確保します。
• 不正証明システムの導入：ZK rollupsの特性を活かし、不正なトランザクションや操作を迅速に検出・防止します。
• 継続的なモニタリング：運用中のシステムを24/7でモニタリングし、異常な活動を即座に検出・対応します。

9.2 ガバナンスモデルの維持

ENSv2では、分散化とガバナンスの独立性を維持するために以下の方針を採用します。

• 分散型ガバナンスの強化：ENS DAOを通じて、プロトコルの変更やアップデートに関する意思決定を分散型に行います。
• 透明性の確保：すべての開発プロセスと意思決定を透明に公開し、コミュニティの信頼を維持します。
• コミュニティの参加促進：ガバナンスフォーラムや提案システムを活用し、コミュニティメンバーが積極的にプロトコルの発展に参加できる環境を整備します。

10. パフォーマンスとスケーラビリティ

10.1 トランザクションスループット

ENSv2は、L2ネットワークの高いトランザクションスループットを活用し、大量のドメイン登録や更新を迅速に処理します。これにより、ユーザーは待ち時間の短縮と快適な操作体験を享受できます。

10.2 確認時間と最終性

ZK rollupsを活用することで、トランザクションの最終性を2〜24時間以内に達成します。これは、従来のOptimistic Rollupsにおける7日間のチャレンジウィンドウと比較して大幅な改善です。迅速な最終性は、名前所有権の即時確定を可能にし、ENS DAOのガバナンス原則に適合します。

10.3 ガスコストの最適化

L2ネットワーク上でのガス費用の削減により、ユーザーは.ETH名の登録や更新をより低コストで行えます。さらに、ENSv2はガスコストの動的調整機能を導入し、ネットワークの需要に応じて最適な料金体系を提供します。

11. 開発者向けツールとサポート

開発者ツールの提供

ENSv2は、開発者が新しいアーキテクチャに迅速に適応できるよう、以下のツールを提供します。

• SDKとAPI：ENSv2に対応したソフトウェア開発キット（SDK）とアプリケーションプログラミングインターフェース（API）を提供し、DAppsやサービスとの統合を容易にします。
• テストツール：開発者がENSv2の機能をテストネット上で検証できるツールを提供し、開発プロセスを効率化します。
• ドキュメントとサンプルコード：詳細なドキュメントとサンプルコードを提供し、開発者がENSv2の機能を最大限に活用できるよう支援します。

12. まとめ

ENSv2は、Ethereum Name Serviceの次なる飛躍を象徴するプロジェクトです。L2への拡張により、ENSはさらなる分散化、コスト効率の向上、マルチチェーン対応を実現し、Web3の未来を支える基盤としての地位を強化します。技術的な挑戦は多岐にわたりますが、ENS Labsはコミュニティと共に、この革新的な進化を成功させるために全力を尽くします。

ENSv2の成功は、分散型インターネットの発展に寄与し、ユーザーと開発者に新たな可能性を提供します。ENSコミュニティの皆様のご支援とご協力をお願い申し上げます。

参考文献

ENS Labs development proposal: ENSv2 and native L2 support

Technical feedback thread

ENSv2: An Update on our Progress