# [ERC7828] ENSを活用したチェーン識別と安全な送金の仕組みを理解しよう！

> ERC7828は、ERC7930（Interoperable Addresses & Names）の拡張仕様です。主な目的は、アドレスとチェーンを結びつけた人間に読みやすい形式を標準化することです。

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

## はじめに

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

https://amzn.asia/d/gxvJ0Pw

今回は、複数のブロックチェーンに存在する同じ形式のアドレスを、人間に読みやすい名前とチェーン名を組み合わせて表記・解決できるようにする仕組みを提案している**ERC7828**についてまとめていきます！

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

https://eips.ethereum.org/EIPS/eip-7828

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

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

## 概要

**ERC7828**は、**ERC7930**（Interoperable Addresses & Names）の拡張仕様です。
主な目的は、アドレスとチェーンを結びつけた人間に読みやすい形式を標準化することです。
提案されているフォーマットは `<address>@<chain>#<checksum>` という形で、アドレスがどのチェーンに属しているのかを明確に示します。

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

[\[ERC7930\] クロスチェーン取引を安全にするためにチェーンIDをアドレスを含む仕組みを理解しよう！](/articles/a0475affba1edb342a9f)

具体的には、以下の要素を導入しています。

- アドレスとチェーンを統合的に表現する形式を定義することで、アドレスだけでは不十分な情報を補う。
- チェーン名は人間に読みやすい文字列とし、ENS（Ethereum Name Service）を使って実際のチェーン識別子（chainID）に解決できるようにする。
- アドレス自体もENSのような人間に読みやすい名前を使えるようにする。
- チェーン名と識別子の対応関係を、中央集権的なリストではなくオンチェーンのレジストリに記録し、誰でも参照できるようにする。
- ENSのドメイン形式の末尾部分（例: `.eth`）はユーザーに見せず、表示はシンプルな形式に統一する。

この仕組みにより、ユーザーは誤ったチェーンに資産を送るリスクを下げられ、また複数のチェーンに存在する同一のエンティティを一つの名前で扱えるようになります。

## 動機

Ethereumを中心としたブロックチェーンの世界では、今後数百から数千のL2（レイヤー2）が存在することが予想されます。
現状、これらのチェーンはEthereumメインネットと同じアドレス形式を使っているため、アドレスだけでは「**どのチェーンのアドレスか**」がわかりません。
この曖昧さが、資産を誤ったチェーンに送付してしまうリスクを高めています。

これまでチェーン名と識別子（chainID）の対応関係は、**EIP155**以来「**中央集権的に管理されたリスト**」に依存してきました。

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

[\[EIP155\] Ethereumネットワークでリプレイ攻撃を防ぐ仕組みを理解しよう！](/articles/2526432899353e4a0225)

しかし、この方法には以下の問題があります。

* チェーン数が急増する中でスケーラビリティに限界がある。
* リストを管理する主体が一元的であり、信頼の集中が起きる。
* 現状では非EVMチェーンへの対応が不足している。

**ERC7828**では、数値ベースの識別子ではなく、人間に読みやすいチェーン名を使い、ENSのワイルドカード解決機能を利用してオンチェーンで解決できるようにします。
これにより、中央集権的なリスト管理を不要とし、分散的で拡張可能なチェーン情報解決を実現します。

さらに、アドレス部分もENSなどの名前解決に対応することで、複数チェーンに存在する同一の実体を単一の名前に紐付けることが可能となり、ユーザー体験の向上と誤送付リスクの低減を両立させます。

この仕様は既存の**ERC7930**との互換性を維持しつつ、将来的に**ERC7785**のようなドメイン規格や他の命名システムとも連携できる拡張性を備えています。

## 仕様

### フォーマットの定義

提案されている形式は、**ERC7930**で定義された「**Interoperable Names**」に追加の意味を与える形で拡張されています。
基本的な書式は以下の通りです。

```
<address>@<chain>#<checksum>
```

* `<address>` には通常のアドレス形式（例: `0x123...`）またはENS名（例: `alice.eth`）を使用できます。
* `<chain>` にはチェーンの識別子を表す値または人間が読めるチェーン名（例: `ethereum` や `arbitrum-nova`）を指定できます。
* `<checksum>` は8桁の16進数で表される検証用の値です。

この仕様は、アドレスやチェーンを「**文字列ラベル**」として表現できる点に特徴があります。
これにより、利用者は数値ベースのチェーンIDを覚える必要がなくなります。

### 表記の例

メインネットやテストネット、ロールアップ、非EVMチェーンに対応した例が示されています。

* メインネットのアドレス
    `0x12345...6789@ethereum#FFFFFFFF`
* テストネット（Sepolia）のアドレス
    `alice.testeth@sepolia#00000000`
* Rollupチェーン上のアドレス
    `alice.eth@arbitrum-nova#AAAAAAAA`
* ENS名を別のチェーンに結びつける例
    `alice.rollup1.eth@rollup2#BBBBBBBB`
* 非EVMチェーン（Bitcoinなど）の例
    `alice.eth@bip122:000000000019d6689c085ae165831e93#CCCCCCCC`

これらの例からわかるように、人間に理解しやすい名前を使いながら、複数のチェーンに存在するアドレスを正確に区別できます。

### チェックサムの役割

表示や共有の際には必ず4バイト（8桁の16進数）のチェックサムを付与する必要があります。
これは誤入力やデータ破損を防ぐための仕組みです。

ウォレットは以下のように扱います。

* チェックサムを自動的に計算して検証する。
* 入力されたアドレスに含まれるチェックサムと計算結果が異なる場合は、ユーザーに警告を出して送金を止める。
* ユーザーがチェックサムを省略した場合でも、ウォレットが内部で計算し補うことができる。

これにより安全性が高まり、誤送金のリスクを抑えることができます。

### チェーン名の解決方法

チェーン名は「`.eth`」ドメインを使って管理されます。
例えば「`arbitrum`」というラベルは「`arbitrum.l2.eth`」という形式で登録されます。
これをENSのワイルドカードリゾルバ（汎用的な解決コントラクト）が処理することで、チェーン名から正しいチェーンIDを取得できます。

逆に、チェーンIDから人間に読みやすい名前を取得することも可能です。
そのための仕組みとして `L2Resolver` コントラクトが想定されており、`chainId` 関数でチェーン名からIDを、`chainName` 関数でIDから名前を取得できます。

これにより、オンチェーン上で分散的かつ一貫した方法でチェーン情報を解決できるようになります。

### CASA名前空間の拡張

現在はEVMチェーンを対象とする `eip155` 名前空間が中心ですが、将来的には非EVMチェーン（例えばBitcoinの `bip122`）も扱えるように拡張することが想定されています。
これにより、EVM以外のブロックチェーンも統一的に扱えるようになります。

### アドレス名の解決

アドレス部分についてはENSに全面的に委ねられています。ENSがサポートする命名規則や今後の仕様拡張に従って、各種チェーンのアドレスを解決できます。

* 順方向の解決（名前からアドレスへ）は、**ERC2304**で定義されている仕組みを使い、**BIP44**に基づくコインタイプ識別子を利用します。
* 逆方向の解決（アドレスから名前へ）は、ENSにデプロイされた `L2ReverseRegistrar` を利用し、特定のチェーンで登録されているアドレスを名前に変換します。

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

[\[ERC2304\] ENSで複数チェーンに対応した仕組みを理解しよう！](/articles/007b901a2dc7f7a04112)

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

[\[BIP44\] 階層型ウォレット構造の仕組みを理解しよう！](/articles/031a610d87ac89b71617)

## 補足

**ERC7828**では、アドレスやチェーン名の解決にENS（Ethereum Name Service）だけを使う方針を採用しています。
これは大きな意味があります。
解決手段をENSに一本化することで、新しい仕組みを追加したり、どのリゾルバを使うかを記録する必要がなくなります。
すでに存在する「**Interoperable Addresses v1**」の枠組みをそのまま使えるため、設計がシンプルで、互換性を保ちながら利用できます。

一方で、ENSに依存することによって、ウォレットはユーザーに対して「**解決済みの名前**」と「**解決されていない生の表記（raw形式）**」のどちらも表示できる柔軟性を持ちます。
例えば、`alice.eth@ethereum#FFFF` のようにENSを解決した形でも、`0x1234...@eip155:1#FFFF` のように生の形式でも、ウォレットが状況に応じてユーザーに提示できるということです。

## 互換性

この仕様で導入された新しい名前の書き方は、従来の**ERC7930**でサポートされていた名前すべてを表現できます。
つまり、ENSを使った解決をしなくても、元の仕様どおりに「**生のアドレスやチェーン識別子**」をそのまま表示することが可能です。

そのため、既存の仕組みを壊すことなく、徐々に人間に読みやすい形式へ移行できます。
すでに**ERC7930**に対応しているシステムも、この仕様に適応する際に大きな変更を必要としません。

## 参考実装

この参考実装は規範的な仕様ではなく、あくまで一例として「**人間に読みやすいアドレス表記をどのようにERC7930のバイナリ形式に変換するか**」を示すものです。
ENS（Ethereum Name Service）の利用方法は将来的に変更される可能性があるため、ここでは具体的な処理手順のサンプルとして理解するのが適切です。

以下では、順方向解決（名前からアドレスへ）と逆方向解決（アドレスから名前へ）の2つの流れを解説します。

### 順方向解決（Forward Resolution）

順方向解決とは、人間が入力した「**名前**」から実際に使える**ERC7930**形式のアドレスを導く手順です。

例えばユーザーが「`alice.eth`」という名前を入力し、「`optimism`」というチェーンを選んだとします。

1. ユーザーが選んだチェーン名に自動的に「`.l2.eth`」を付与し、`optimism.l2.eth` という形式を生成します。
2. **ENSIP1**に従い、この文字列の `namehash` を計算します。

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

[\[ENSIP1\] ENSの登録と更新の仕組みを理解しよう！](/articles/9bfb5c7b037fc33dc2ff)

3. `L2Resolver.chainId` 関数に `namehash` を渡し、対応するチェーンIDを**ERC7930**の形式で取得します。
4. 取得したチェーンIDを**CAIP2**形式に変換します。
5. **ENSIP11**に従い、**EIP155**のchainIdをコインタイプ（coinType）に変換します。

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

[\[ENSIP11\] ENSが導入するEVMチェーン識別番号の仕組みを理解しよう！](/articles/6eb35a26617eb07d31a1)

6. ENSレジストリに問い合わせ、`alice.eth` に対応するresolverを取得します。
7. resolverの `addr` 関数を呼び出し、対象のコインタイプに対応するアドレスを取得します。
    例として `0xaAaAaA...` が返るとします。
8. もし返り値がゼロアドレスなら、名前は登録されておらず解決は失敗です。
9. 最後に、チェーンタイプ・チェーン参照・アドレス長・アドレスを順に並べ、**ERC7930**のバイナリ形式に変換します。
10. チェックサムを計算し、ユーザーに `<address>@<chain>#<checksum>` の形式で表示します。

これにより、ユーザーは「`alice.eth\@optimism#C69BEB13`」のような形式を得られます。

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

[\[CAIP2\] 複数のブロックチェーンを識別する仕組みを理解しよう！](/articles/ee2925039fa62b982101)

### 逆方向解決（Reverse Resolution）

逆方向解決とは、すでにシリアライズ済みの**ERC7930**アドレスから、人間に読みやすい名前を導く手順です。

例えば、シリアライズされたアドレス `0x00010000010A14AAAAAAAA...` が入力されたとします。

1. 先頭のバイト列からバージョンやチェーン情報、アドレス部分を分解します。
    この例ではチェーンタイプが`eip155`で、`chainId`は`10`（optimism）です。
2. `L2Resolver.chainName` を呼び出し、chainIdに対応するチェーン名を取得します。
    この場合は `optimism.l2.eth` が返ります。
3. **ENSIP19**の仕様に従って、アドレスとchainIdを用いた逆引き用文字列を生成します。
    形式は `<address>.<coinType>.reverse` です。

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

4. ENSレジストリに問い合わせ、対応するresolverを見つけます。通常は `L2ReverseRegistrar` というコントラクトが応答します。
5. `nameForAddr` 関数を呼び出し、アドレスに紐づいた人間可読の名前を取得します。
    この例では `alice.eth` が返ります。
6. 取得した名前が正しくforward解決できるか確認します。もし異なるアドレスを返したり、解決できない場合は「**未解決のアドレス**」としてユーザーに生の表記を提示し、注意を促します。
7. 最後にチェックサムを計算し、`alice.eth@optimism#C69BEB13` のような形式に整形して表示します。

## セキュリティ

### 名前のなりすましリスク

ENSを利用して人間に読みやすい名前を解決する際には、ユニコード文字の「**見た目の似ている文字（グリフ）**」によるなりすまし攻撃に注意が必要です。
例えば、攻撃者が「`alice.eth`」という名前を偽装したい場合、見た目は同じでも実際には異なる文字（ラテン文字の「`a`」ではなくキリル文字の「`а`」など）を使った「`аlice.eth`」を登録する可能性があります。

この場合、攻撃者は次のような手口を使えます。

1. 攻撃者が特定のチェーン上でアドレスを生成し、そのアドレスのチェックサムを「`00112233`」と一致させる。
2. 上記の偽名（例: `аlice.eth`）を登録し、そのアドレスに紐付ける。

これにより、見た目では正しい「`alice.eth`」に見えても、実際には攻撃者のアドレスへ送金してしまうリスクがあります。
ウォレット開発者はこのようなグリフ衝突を検出し、ユーザーに警告を表示する必要があります。

### 逆引き解決に伴う信頼の前提

**ENSIP19**（ENSの逆引き仕様）を利用してアドレスから名前を解決する場合、チェーンの種類によって信頼性の前提が異なります。

* ZK-rollupのような仕組みでは、オンチェーン証明を利用することで、信頼最小化された（信頼を特定の第三者に依存しない）解決が可能です。
* 一方でSidechainでは、中央集権的なCCIP-readゲートウェイや署名権限を持つ主体に依存するケースがあります。
    この場合、名前解決は特定の管理者の正しさを信じる必要が生じます。

ウォレットは、逆引き解決を行った際に「**その結果が信頼最小化されているのか、あるいは特定の主体に依存しているのか**」を必ずユーザーに示すべきです。
これにより、ユーザーは解決結果を鵜呑みにするのではなく、潜在的なリスクを理解したうえで利用できます。

## 引用

Sam Kaufman (@SampkaML), Marco Stronati (@paracetamolo), Yuliya Alexiev (@yuliyaalexiev), Jeff Lau (@jefflau), Sam Wilson (@samwilsn), Vitalik Buterin (@vbuterin), Teddy (@0xteddybear), Joxes (@Joxess), Racu (@0xRacoon), Skeletor Spaceman (@0xskeletor-spaceman), TiTi (@0xtiti), Gori (@0xGorilla), Ardy (@0xArdy), Onizuka (@onizuka-wl), Lumi (@oxlumi), Moebius (@0xmoebius), "ERC-7828: Readable Interoperable Addresses using ENS [DRAFT]," Ethereum Improvement Proposals, no. 7828, November 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7828.

## 最後に

今回は「複数のブロックチェーンに存在する同じ形式のアドレスを、人間に読みやすい名前とチェーン名を組み合わせて表記・解決できるようにする仕組みを提案している**ERC7828**」についてまとめてきました！
いかがだったでしょうか？

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