はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、ブロックチェーンのチェーン識別子を分散的かつ安全に管理するため、ENSを利用してチェーン名から識別子を導出・検証できる仕組みを提案しているERC7785についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIP・BIP・SLIP・CAIPについてまとめています。
概要
ERC7785は、ブロックチェーンのチェーン識別子（chain identifier）を「チェーン名などの情報を元に計算したハッシュ値（digest）」として導き出す仕組みを提案しています。 さらに、これらのチェーン名と識別子の対応関係を、これまでのようにGitHubで中央集権的に管理するのではなく、ENS（Ethereum Name Service）を利用して分散的に登録・解決できるようにすることを目的としています。 また、従来のルールに従っていない既存のチェーン識別子にも対応できる仕組みを用意しています。
動機
現在、チェーン名と識別子（例：Mainnet → 0x1）の対応はGitHub上のリストで管理されています。 しかし、この仕組みには以下の問題があります。
- L2（レイヤー2）の数が急増しており、中央集権的なリスト管理ではスケールできない。
- リストを管理する少数の人や組織に依存しており、単一障害点（single point of failure）となっている。
このため、提案では以下の性質を持つ仕組みが求められています。
- 新しいチェーン名と識別子を検閲耐性のある方法で登録できること
- 登録されたチェーン名と識別子を信頼不要（trustless）に解決できること
- 1つのチェーン名に1つの識別子を対応させる一意性を保つこと
チェーン識別子の偽装とリプレイ攻撃
中央集権的なリストが保証していた重要な性質は「チェーン名と識別子の一対一対応」です。 これが崩れると、攻撃者に悪用される可能性があります。
例えば、攻撃者が「my-testnet」という新しい名前を既存のMainnet（0x1）に結びつけて登録したとします。
ユーザーは「my-testnet」という名前を安全なテストネットだと誤解してトランザクションに署名してしまうかもしれません。
しかし実際にはそれはMainnet用のトランザクションであり、攻撃者はその署名済みトランザクションをMainnet上でリプレイ（再利用）できてしまいます。
仕様
ERC7785では、チェーン識別子（chain identifier）の拡張方法と、ENSを利用したチェーン名から識別子への解決方法が示されています。 ここでは、識別子の生成方法と解決の仕組みを順を追って説明します。
チェーン識別子の拡張
これまでのチェーン識別子は、短く任意に決められてきました。
例えば Ethereum Mainnet の識別子は 0x1 のように小さい数値です。
しかし、ブロックチェーンの数が急増している現状では、この方式では対応できません。
そこでERC7785では、識別子のサイズを32バイトに拡張し、暗号学的ハッシュ関数を使って生成する方法が示されています。 ハッシュの入力にはチェーン名が必須であり、必要に応じて追加の情報を含めることができます。
例えばL2チェーンの場合、識別子は次のように計算されます。
chain_id = Keccak-256(CHAIN_NAME, SETTLEMENT_CHAIN_ID, VERSION, DEPLOYER_CONTRACT_ADDRESS, SALT)SETTLEMENT_CHAIN_IDは、L2が最終的に処理を依存するL1チェーンの識別子（例：MainnetやTestnet）VERSIONは、ハッシュの計算に一意性を持たせるための任意の文字列DEPLOYER_CONTRACT_ADDRESSは、L1上に配置されたL2のコントラクトアドレスSALTは追加の一意性を与えるための値
これにより、識別子の衝突を避けながら拡張性を確保できます。
チェーン名の解決
ENS（Ethereum Name Service）を用いることで、チェーン名をチェーン識別子に解決できます。 これはERC2304に従い、ENSレコードの中に識別子と関連情報を格納する形で実現されます。
ERC2304については以下の記事を参考にしてください。
例えば「rollup」というL2チェーンをMainnet上で識別する場合、ENSで次のように解決されます。
rollup.eth -> {version : uint, bridge : address, chain_id : chain_id}この情報を受け取った利用者は、以下のように検証します。
chain_id == hash("rollup", 0x1, version, bridge)この仕組みによって、ENS名から信頼不要（trustless）にチェーン識別子を導出し、正しく一意な関係が保たれていることを確認できます。
つまり、ユーザーは「rollup.eth」という名前を解決するだけで、そのL2のチェーン識別子やブリッジコントラクトなどの情報を得られ、かつハッシュ計算によって正当性を検証できるのです。
互換性
新しい方式で生成されていない既存のチェーン識別子についても、ERC7785ではサポート方法が示されています。 方法は「逆引きマッピング」を利用するものです。 具体的には、既存の識別子をチェーン名へと逆変換できる仕組みを設け、その対応が一意であるかを確認します。
例えば、legacy-rollup.eth というチェーン名が識別子 0x123 に対応している場合、この識別子 0x123 を chainid.reverse ドメインで解決するとチェーン名が返されます。
その結果が legacy-rollup であれば、この対応は正しいと認められます。
こうした逆引きにより、過去に定義された識別子と新しい仕組みで導入される識別子の両方を共存させることが可能になります。
初期設定と引き継ぎ
既存の識別子を新しい仕組みに移行するための「ブートストラップ」と「引き継ぎ」の手順も提案されています。
- まずEthereum Foundation（EF）が中心となり、
chainid.reverseドメインと一時的なl2.ethドメインを構築し、既存のEthereumリストをもとに情報を登録します。 - 次に、各ロールアップ（L2）が
rollup.ethという名前を登録し、自分のchain_idを指すように設定します。 - その後、EFが管理していた
rollup.l2.ethとchain_id.chainid.reverseの権限をそのロールアップに引き渡します。 - 最終的に、そのロールアップ自身が
chain_id.chainid.reverseを更新し、正しいチェーン名（例：rollup.eth）を返すようにします。
この流れにより、既存の識別子を徐々に新しい分散的な仕組みに移行できます。
セキュリティ
セキュリティ面では、主に以下の2つの懸念が挙げられています。
-
ドメイン偽装によるリプレイ攻撃 偽のドメイン名が既存の識別子に結びつけられると、ユーザーが誤って署名したトランザクションが他のチェーンで再利用（リプレイ）されてしまう危険があります。 これを防ぐためには、新しい識別子を必ずハッシュ関数で導出し、既存の識別子については逆引きマッピングで確認する必要があります。
-
ドメインスクワッティング 本来の利用者ではない者が、大量のドメイン名を先取りして後から売りつける行為です。 これはENSの仕組みにも起こりうる問題ですが、すでに中央集権的なGitHubリストにおいても似たような課題が存在するため、L2が増えるにつれて避けがたい問題として認識されています。
引用
Marco Stronati (@paracetamolo), Jeff Lau (@jefflau), "ERC-7785: Onchain registration of chain identifiers [DRAFT]," Ethereum Improvement Proposals, no. 7785, September 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7785.
最後に
今回は「ブロックチェーンのチェーン識別子を分散的かつ安全に管理するため、ENSを利用してチェーン名から識別子を導出・検証できる仕組みを提案しているERC7785」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！
