# [ERC6735] 複数のEVMチェーンで同じアドレスを扱う仕組みを理解しよう！ > ERC6735では、Ethereum Virtual Machine（EVM）を基盤とするアドレスのエイリアス化（Aliasing）を実現するために必要な最小限のビジネス的および技術的前提条件、ならびに機能要件と非機能要件を定義しています。 - URL: https://cardene.dev/articles/aa8615a63e62fcc2663c - 公開日: 2025-10-27 - 更新日: 2025-10-27 - トピック: Blockchain - タグ: ethereum, solidity, smartcontract, ブロックチェーン ## はじめに 『DApps開発入門』という本や色々記事を書いているかるでねです。 https://amzn.asia/d/gxvJ0Pw 今回は、EthereumなどのEVM互換チェーン間で同じ資産やアカウントを一貫して識別・管理できるようにするための「アドレスエイリアス化」という共通ルールを定め、異なるレイヤーのブロックチェーン間でも安全かつ確実に相互運用できる仕組みを提案している**ERC6735**についてまとめていきます！ :::message 以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。 ::: https://eips.ethereum.org/EIPS/eip-6735 他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。 https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4 ## 概要 **ERC6735**では、Ethereum Virtual Machine（EVM）を基盤とするアドレスのエイリアス化（Aliasing）を実現するために必要な最小限のビジネス的および技術的前提条件、ならびに機能要件と非機能要件を定義しています。 エイリアス化とは、異なるレイヤー（Layer 1、Layer 2、またはサイドチェーン）間で、同じデジタル資産やアカウントを識別・変換できるようにする仕組みのことです。 これにより、複数のブロックチェーン環境（例：メインチェーン、セカンドレイヤー、サイドチェーン）間でアドレスを一貫して扱えるようになります。 ## 動機 この取り組みは、OASISが管理するEEA Communities ProjectのL2ワーキンググループ（L2 WG）が提唱したものです。 彼らは、EVMベースのレイヤー（L1、L2、サイドチェーン）間での**相互運用性（interoperability）**を向上させるために、アドレスを決定的（deterministic）に導出する仕組みが必要であると認識しました。 #### 背景と目的 現在、EVMをベースとした異なるチェーン間で同一の資産（スマートコントラクト）や外部所有アカウント（Externally Owned Account：EOA）を扱う場合、それぞれのチェーンでアドレスが異なるため、互いを直接識別する標準的な方法が存在しません。 この状態は、もしインターネットサービスプロバイダごとに独自のIPアドレス体系を使っているようなもので、通信や識別が困難になります。 L2 WGは、これを解決するためにアドレスエイリアス化という概念を導入しました。 この仕組みを導入すると、異なるチェーン間で次のようなことが可能になります。 - **明確なアドレス指定が可能になる** あるチェーン（ソースチェーン）から別のチェーン（ターゲットチェーン）へ送るメッセージで、資産やアカウントを曖昧さなく指定できるようになります。 - **メッセージの出所を検証できる** ユーザーは、メッセージの送信元チェーンを確実に特定でき、必要に応じて、資産やアカウントのorigin chainでの状態も検証できます。 これは、送信元チェーンの「**正規トークンリスト（canonical token list）**」を利用することで実現します。 - **チェーン間のアドレス関係を一貫して扱える** デジタル資産やEOAのアドレスを、EVMベースのL1、L2、サイドチェーン間で一貫して関連付けることが可能になります。 #### 標準化の必要性 現在、アドレスエイリアスを生成・解釈するための共通仕様が存在していません。 各チェーンが独自の方法でアドレスを決定しているため、統一的なアプローチが求められています。 そのため、**ERC6735**では「**root → leaf**」構造に基づいた標準的なアドレスエイリアスの仕組みを提案しています。 この構造では、アドレスエイリアスは「**元のチェーン上のアドレス**」と「**そのチェーン固有のオフセット値（immutable characteristic）**」から導出されます。 このオフセット値により、どのチェーンから派生したアドレスなのかを一意に判断できるようになります。 #### Root → Leaf構造によるアドレスエイリアスの概念 ``` L1アドレス + L1オフセット → L2（A, B, C）に派生 A → B では、L1アドレス + L1オフセット + Aオフセット B → L3 では、L1アドレス + L1オフセット + Bオフセット D → C では、L1アドレス + L1オフセット + Bオフセット + Dオフセット ``` この構造は、EVMベースのL1から複数のL2へ、さらにL3へと階層的に接続される仕組みを表しています。 例えば、L1からL2 Bを経由してL3 D、最終的にL2 Cに至る経路では、オフセットを順に積み重ねることで、アドレスの来歴（どのチェーンを経由したか）を明確に示すことができます。 #### L1からL2 B、L3 D、L2 Cへの経路の強調 図1の中で、特にL1からL2 B、L3 D、L2 Cへと至る経路が赤で示されています。 この経路は、資産やメッセージがどのような経路で伝達されたかを視覚的に理解するためのものです。 #### 範囲の限定 なお、この文書の対象はEVMベースのチェーン間に限定されており、非EVMベースのチェーン間、またはEVMと非EVM間のアドレスエイリアス化は**対象外**とされています。 ## 仕様 #### タイポグラフィ規約：要件IDの表記方法 **ERC6735**では、各要件を一意に識別するために「**要件レベル**」と「**要件番号**」を組み合わせた形式でIDを付与します。 表記形式は以下の通りです。 | 記号 | 意味 | 解釈（RFC2119準拠） | | --- | ----------------- | -------------------- | | [R] | Requirement（必須要件） | MUST（必ず実装する必要がある） | | [D] | Desirable（推奨要件） | SHOULD（推奨されるが必須ではない） | | [O] | Optional（任意要件） | MAY（任意で実装しても良い） | 要件番号は各レベルごとに昇順で付与されます。 例えば、`[R1]` は絶対的に満たす必要がある要件、`[D1]` は推奨事項、`[O1]` は完全に任意の要件です。 なお、ここで示されるすべての要件は EVMベースのL1、L2、またはサイドチェーンに適用されます。 非EVMシステムに対するアドレスエイリアス化は対象外です。 #### アドレスエイリアスに関する必須要件（R1〜R8） ##### R1：アドレスエイリアスの構成方法 チェーンAとチェーンBの間で使用されるアドレスエイリアスは、以下の形式で構成する必要があります。 ``` addressAlias (Chain A) = offsetAlias (for Chain A) + relativeAddress (on Chain A) + offsetAlias (for Chain A) ``` この構造により、アドレスがどのチェーンから来たものかを一意に判断できます。 **テスト可能性** 既存のオープンソースパッケージでエイリアスを分割・解析し、既知の`addressAlias`および`relativeAddress`と比較することで検証できます。 ##### R2：offsetAliasの定義 各チェーンの`offsetAlias`は以下の形式でなければなりません。 ``` offsetAlias = 0xchainId00000000000000000000000000000000chainId ``` **テスト可能性：** オープンソースパッケージを使用して解析し、既知の`chainId`と一致するか確認します。 ##### R3：chainIdのゼロ禁止 `offsetAlias`で使用される`chainId`は0であってはいけません。 `chainId`は数値として定義されており、ゼロでないことを確認することができます。 ##### R4：chainIdの長さ `chainId`は8バイトでなければなりません。 文字列長をバイトに変換して比較することで検証できます。 ##### R5：chainIdのゼロ埋め `chainId`が16桁未満の場合は、16桁になるまでゼロで埋める必要があります。 **例：** Polygon PoSの`chainId`は`137`です。 その場合の`offsetAlias`は次のようになります。 ``` 0x0000000000000137000000000000000000000000000000000000000000000137 ``` **テスト可能性** 解析した`chainId`と既知の値を比較し、ゼロ埋めの桁数が正しいか確認します。 ##### R6：Ethereum Mainnetの特例 Ethereum Mainnet（EVMチェーンの基盤となるL1）の`offsetAlias`は以下でなければなりません。 ``` 0x1111000000000000000000000000000000001111 ``` これは既存のL2ソリューションとの互換性を保つためです。 **例：** USDC資産のエイリアス ``` addressAlias = 0x1111A0b86991c6218b36c1d19D4a2e9Eb0cE3606eB481111 ``` ##### R7：relativeAddressの定義 各チェーン上のEOAまたはスマートコントラクトの`relativeAddress`は、以下のいずれかでなければなりません。 - 元のチェーン上のEOAまたはスマートコントラクトのアドレス - 他のチェーン上のEOAまたはスマートコントラクトの`relativeAddress` **例：** * 元のチェーン上のUSDCの`relativeAddress` ``` 0x1111A0b86991c6218b36c1d19D4a2e9Eb0cE3606eB481111 ``` * Polygon上のラップドUSDCの`relativeAddress` ``` 0x00000000000001371111A0b86991c6218b36c1d19D4a2e9Eb0cE3606eB4811110000000000000137 ``` * EthereumからArbitrumへ送るラップドUSDCのエイリアス例 ``` 0x00000000000421611111A0b86991c6218b36c1d19D4a2e9Eb0cE3606eB4811110000000000042161 ``` **テスト可能性** 既存のEVM実装でアドレスがEOAかスマートコントラクトかを確認する既知の方法が存在するため、検証が可能です。 ##### R8：offsetAliasの順序 `addressAlias`内での`offsetAlias`の順序は、ルートチェーン（root chain）からブリッジ先の順に並べる必要があります。 **正しい順序の例** ``` addressAlias = chainId(C) chainId(B) chainId(A) relativeAddress chainId(A) chainId(B) chainId(C) ``` **誤った順序の例** ``` addressAlias = chainId(A) chainId(B) chainId(C) relativeAddress chainId(C) chainId(B) chainId(A) ``` **テスト可能性** [R1]の構築ルールに基づいて論理演算で順序を検証できます。 #### 適合性 このセクションでは、仕様への準拠を証明するためのテストや条件を定義しています。 現時点では、すべての`MUST`、`SHOULD`、`MAY`要件に対して統一的なテスト入力（テストフィクスチャ）はまだ標準化されていません。 次のバージョンで公開される予定です。 ##### 適合レベル EVMベースのアドレスエイリアス化の実装には、以下の3つのレベルがあります。 | レベル | 必要な条件 | 内容 | | ----------- | ----------- | -------------------- | | **Level 1** | MUSTをすべて満たす | 実装がすべての必須要件に準拠していることを、実装固有のテストレポートで証明する必要があります。 | | **Level 2** | MUST + SHOULDを満たす | 必須および推奨要件のすべてを満たし、テストレポートで根拠を提示する必要があります。 | | **Level 3** | MUST + SHOULD + MAY（条件付き）を満たす | 任意要件を含め、条件付きのMUST/SHOULDもすべて実装していることを証明する必要があります。 | ##### D1：推奨事項（テスト手順の記述） 正規トークンリスト実装が本仕様に準拠していると主張する場合、 各要件に対して実施した**テスト手順とその妥当性の説明**を記載すべきです。 **テスト可能性** 各要件が個別に検証可能であるため、全体としてもテスト可能です。 ##### R9：上位レベルでの準拠証明 レベル2以上の準拠を主張する場合は、各要件に対して実施したテスト手順を明確に記述し、根拠を提示する必要があります。 **テスト可能性** すべての要件がテスト可能であるため、レポート作成および実装検証が可能です。 ## 補足 **ERC6735**は、すでに存在するEthereum（L1）からEVMベースのL2ネットワーク（例：ArbitrumやOptimism）へのアドレスエイリアス化手法を基盤としています。 これまでの仕組みでは、主にEthereumメインネットと特定のL2間でのみアドレスの関連付けが行われてきましたが、**ERC6735**ではこの仕組みをより汎用的に拡張し、どのEVMベースのネットワーク間でも適用できるように一般化しています。 つまり、L1（メインネット）、L2（スケーリングネットワーク）、L3（さらなるレイヤー）といった階層の違いに関係なく、EVMを基盤とするあらゆるネットワーク間でアドレスを一貫して扱える仕組みを提供することを目的としています。 この一般化により、ブロックチェーン間の相互運用性が飛躍的に向上し、異なるネットワーク上に存在するデジタル資産やアカウントを、より安全かつ確実に識別・参照できるようになります。 ## セキュリティ #### データプライバシー **ERC6735**では、データプライバシーに関して特定の法的要求事項や規制遵守を定義していません。 そのため、実装者自身が属する地域や管轄の法律・規制（例：GDPRなど）に基づき、データ保護およびプライバシー関連のコンプライアンスを遵守する責任があります。 標準は技術仕様の枠組みを提供するものであり、法的適用に関しては各実装者の裁量に委ねられています。 #### 運用準備性 **ERC6735**では、特定のアプリケーション・ツール・ライブラリの使用を義務付けていません。 実装者は、使用するソフトウェアやライブラリを選定する時に、信頼性、メンテナンス状況、セキュリティ評価などを含めて十分な検証（デューデリジェンス）を行う必要があります。 つまり、「**この標準を実装する時にどのフレームワークやツールを使うべきか**」という制約はなく、各開発チームが自分たちの環境に合った方法を選択できます。 #### Ethereum型アドレスのセキュリティ上の懸念 EVMアドレスエイリアスはEthereum型アドレス（20バイトの16進数アドレス）を基礎として構築されます。 そのため、`relativeAddress`（相対アドレス）に使用されるアドレスの種類に応じて、以下のようなセキュリティ検証を行うことが推奨されています。 ##### 外部所有アカウント（EOA）の場合 もし`relativeAddress`に使用されているEthereum型アドレスがEOA（Externally Owned Account）である場合、受信側システムは「**コードハッシュ（codehash）がNULLであることを検証する**」という確認を行う必要があります。 これにより、そのアカウントがスマートコントラクトを含まない純粋なEOAであることを確認できます。 これを怠ると、資産転送の時に不正なコードが意図せず実行される可能性があります。 ##### スマートコントラクトの場合 もし`relativeAddress`に使用されているEthereum型アドレスがスマートコントラクトアカウントである場合、 受信側は「**ソースアカウントのコードハッシュが公開されているスマートコントラクトのSolidityコードのコードハッシュと一致するか検証する**」という確認を行うべきです。 これにより、送付元のスマートコントラクトが期待どおりの動作を行う正規のものであることを確認できます。 改ざんや異なるコードが実行されることを防ぐための基本的な安全策です。 ##### チェックサムの検証（ERC-55準拠） 最後に、`relativeAddress`の検証の一環として、アドレスのチェックサム検証を行うことが推奨されています。 この検証は、**ERC55**（Ethereumアドレスの大文字・小文字によるチェックサム規格）に従って実施されます。 :::message **ERC55**については以下の記事を参考にしてください。 ::: [\[EIP55\] Ethereumアドレスのチェックサムの仕組みを理解しよう！](/articles/985f03760df12929b5f9) **ERC55**によるチェックサムは、ユーザーが入力ミスをした場合や、データ転送中にアドレスが破損した場合に誤動作を防ぐ効果があります。 #### 国際化とローカライズ EVMベースのアドレスエイリアス化は言語に依存しない技術仕様であるため、国際化（多言語対応）やローカライズ（地域特化対応）に関する特別な考慮は必要ありません。 アドレスやオフセット値などはすべて16進数形式の技術的要素で構成されており、言語や地域による影響を受ける部分は存在しません。 ## 引用 Kelvin Fichter (@smartcontracts), Andreas Freund (@Therecanbeonlyone1969), "ERC-6735: L2 Aliasing of EVM-based Addresses [DRAFT]," Ethereum Improvement Proposals, no. 6735, March 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6735. ## 最後に 今回は「EthereumなどのEVM互換チェーン間で同じ資産やアカウントを一貫して識別・管理できるようにするための「アドレスエイリアス化」という共通ルールを定め、異なるレイヤーのブロックチェーン間でも安全かつ確実に相互運用できる仕組みを提案している**ERC6735**」についてまとめてきました！ いかがだったでしょうか？ 質問などがある方は以下の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