はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、複数のブロックチェーン間で同じトークンを正確に識別・共有できるようにするための共通データ標準を定めた提案しているERC6734についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。
概要
ERC6734では、複数のブロックチェーン（Layer 1、Layer 2、またはサイドチェーン）が、他のチェーン上のトークンを識別できるようにするためのJSON形式のトークンリストについて提案しています。 この仕組みにより、異なるブロックチェーン間で同一トークンを統一的に扱えるようにすることを目的としています。
動機
この取り組みは、OASIS（オープンソース技術標準化団体）のもとで運営されている EEA Communities Projects の L2 ワーキンググループ（L2 WG）によって進められています。 その背景には、複数のブロックチェーン（L1、L2、サイドチェーン）でトークンを定義し、リスト化する際の大きな課題があります。
課題
異なるチェーン間でトークンをやり取りする時、以下のような問題が発生します。
トークンの「正規版（canonical token）」の特定
あるチェーンA上のトークンをチェーンBへブリッジ（橋渡し）するとき、チェーンB上にはそのトークンの新しい表現（wrapped tokenなど）を作成する必要があります。 しかし、このとき「どのトークンがチェーンAの元のトークンに対応する正規版なのか」という点で合意を取ることが難しくなります。 この問題はL2（セカンドレイヤー）に限らず、ブリッジを介して接続されるすべてのチェーンに共通しています。
ブリッジとルートの標準化
どのブリッジを通じて、どのチェーン間でトークンをやり取りできるかというルート情報を整理・標準化することも大きな課題です。 この点については別のEIPで扱う予定ですが、トークンリストと密接に関係しています。
これらの課題は、マルチチェーン（複数チェーンが共存する）環境における根本的な問題です。
目的
ERC6734の目的は、トークンを利用するユーザーが、異なるチェーン間でのトークン使用をより明確にして混乱を避けられるようにすることです。 つまり、トークンの「どのチェーン上の、どのアドレスのトークンが、他のチェーン上のどのトークンと同一なのか」を判別しやすくすることを目指しています。
現状の課題と例
現在、L2プロジェクトではそれぞれが独自のトークンリストを管理しています。
- Arbitrum Uniswapトークンリストを拡張し、独自のフィールドを追加。
- Optimism 同様に独自拡張を行っているが、仕様はArbitrumと異なる。
これらの拡張には、トークンをブリッジするための情報（どのブリッジを使用できるか）も含まれています。 しかし、実際にはトークンを運べるブリッジは複数存在するため、トークンリストとブリッジ情報は分離すべきとされています。 また、OptimismとArbitrumの両方で、トークンの正規性（canonicity）は「トークン名＋シンボル」の組み合わせによって定義されています。
Arbitrum のトークン例
{
"logoURI": "https://assets.coingecko.com/coins/images/13469/thumb/1inch-token.png?1608803028",
"chainId": 42161,
"address": "0x6314C31A7a1652cE482cffe247E9CB7c3f4BB9aF",
"name": "1INCH Token",
"symbol": "1INCH",
"decimals": 18,
"extensions": {
"bridgeInfo": {
"1": {
"tokenAddress": "0x111111111117dc0aa78b770fa6a738034120c302",
"originBridgeAddress": "0x09e9222e96e7b4ae2a407b98d48e330053351eee",
"destBridgeAddress": "0xa3A7B6F88361F48403514059F1F16C8E78d60EeC"
}
}
}
}この例では、extensionsの中にbridgeInfoという項目があり、どのブリッジ経由でトークンを移動できるかが定義されています。
しかし、他のブリッジ経路も存在するため、この情報をトークンリストと分ける必要があります。
今後の方向性
この標準では、既存のフレームワーク（例：Uniswapトークンリスト）を基盤としつつ、Decentralized Identifiers（DID：分散型識別子） の概念を取り入れます。 具体的には、JSON-LD（JSON Linked Data） モデルを活用し、以下の要素を導入します。
- URI（Uniform Resource Identifier） トークン情報を一意に識別し、解決（参照）可能にする。
- JSON-LDスキーマ データ構造を機械的に検証できるようにする。
これにより、既存のツールを用いてスキーマ検証が容易になり、トークン間の互換性と透明性が向上します。
範囲の限定
なお、ERC6734では「トークンそのものを定義する標準」を作ることは対象外です。 あくまで「トークンの識別と関連付け」に焦点を当てた仕様です。
仕様
表記規則：要件ID
各要件は、ユニークなIDで識別されます。 IDは「要件レベル」と「番号」の組み合わせで構成され、以下の形式で表されます：
| プレフィックス | 意味 | RFC2119での解釈 |
|---|---|---|
| [R] | 絶対要件 | MUST |
| [D] | 推奨要件 | SHOULD |
| [O] | 任意要件 | MAY |
例えば、[R1] は絶対的な要件、[D1] は推奨される要件、[O1] は任意の要件を意味します。
要件定義
[R1] カノニカルトークンリストに必須のデータ要素
以下の要素は、トークンリストに必ず含める必要があります。
| 要素名 | 説明 |
|---|---|
type |
データの種類を示す識別子 |
tokenListId |
トークンリストの一意なID（URI形式） |
name |
トークンリストの名称 |
createdAt |
作成日時 |
updatedAt |
更新日時 |
versions |
バージョン情報 |
tokens |
トークンデータの一覧 |
これらの定義と例は、後述のスキーマで詳しく示されています。
[R2] tokens 要素の構造
tokens フィールドは複合データであり、少なくとも以下の項目を含む必要があります。
| 要素名 | 説明 |
|---|---|
chainId |
トークンが存在するチェーンの識別子 |
chainURI |
チェーンのジェネシスブロックURI |
tokenId |
トークンを特定する一意のURI |
tokenType |
トークンの種類（例：fungibleなど） |
address |
トークンコントラクトのアドレス |
name |
トークン名 |
symbol |
トークンシンボル |
decimals |
小数点桁数 |
createdAt |
作成日時 |
updatedAt |
更新日時 |
[D1] その他の要素
上記以外のデータ要素も、可能であればリストに含めることが推奨されます。
[CR1]>[D1] 拡張データ要素の使用
拡張データ（extensions）を利用する場合、以下のデータが必ず含まれていなければなりません。
| 要素名 | 説明 |
|---|---|
rootChainId |
元のチェーンID |
rootChainURI |
元チェーンのジェネシスブロックURI |
rootAddress |
元トークンのコントラクトアドレス |
[R3] URIの準拠性
URIとして定義されているすべてのプロパティは、RFC 3986に準拠する必要があります。
[R4] chainId の要件
chainId プロパティはEIP155に従う必要があります。
EIP155については以下の記事を参考にしてください。
これは、異なるネットワーク間でのトランザクション再送防止（replay protection）を保証するものです。
EIP155では、署名のv値にCHAIN_IDを組み込む仕様が定義されています。
この要件は既存の暗号ライブラリで検証可能です。
[O1] humanReadableTokenSymbol プロパティ
humanReadableTokenSymbol プロパティは任意で使用できます。
これは、人間が識別しやすい形でトークンを表現するためのプロパティです。
[CR2]>[O1] 表記ルール
humanReadableTokenSymbol は以下のように構築します。
tokenSymbol + "-" + chainId例：
tokenSymbol = ETH
chainId = 1
humanReadableTokenSymbol = ETH-1JSONスキーマ
以下は、カノニカルトークンリストの完全なJSONスキーマです。 このスキーマは、JSON-LD（JSON Linked Data）形式にも対応しており、W3CのDID（分散型識別子）仕様と互換性があります。
{
"$id": "https://github.com/eea-oasis/l2/schemas/CanonicalTokenList.json",
"$schema": "https://json-schema.org/draft-07/schema#",
"title": "CanonicalTokenList",
"description": "Canonical Token List",
"type": "object",
"required": ["type","tokenListId","name","createdAt","updatedAt","versions","tokens"],
"properties": {
"type": {"type": "string", "examples": ["CanonicalTokenList"]},
"tokenListId": {"type": "string", "description": "トークンリストの公開URI"},
"name": {"type": "string", "description": "トークンリスト名"},
"createdAt": {"type": "string", "description": "作成日時"},
"updatedAt": {"type": "string", "description": "更新日時"},
"versions": {
"type": "array",
"items": {"type": "object", "properties": {"major": {"type": "integer"}, "minor": {"type": "integer"}, "patch": {"type": "integer"}}}
},
"tokens": {
"type": "array",
"items": {
"type": "object",
"required": ["chainId","chainURI","tokenId","tokenType","address","name","symbol","decimals","createdAt","updatedAt"]
}
}
}
}このスキーマはW3C CCG Traceability Work Itemのように既存ツールで検証可能です。
適合性
このセクションでは、実装がこの仕様にどの程度適合しているかを示すための基準を定義しています。
適合ターゲット
現時点では、すべての MUST, SHOULD, MAY 要件を網羅する公式テストセットは定義されていません。
今後のバージョンで標準化されたテストフィクスチャ（検証用データセット）が公開される予定です。
適合レベル
実装の成熟度に応じて、以下の3つのレベルが定義されています。
| レベル | 内容 |
|---|---|
| Level 1 | MUST要件すべてに準拠。テストレポートにより確認される。 |
| Level 2 | MUSTおよびSHOULD要件すべてに準拠。 |
| Level 3 | MUST、SHOULD、MAY要件（条件付き要件を含む）すべてに準拠。 |
[D2] 適合主張の説明
仕様への準拠を主張する場合、各要件ごとのテスト手順とその根拠を明示することが推奨されます。
[R5] 高レベル準拠（Level 2以上）の主張
Level 2またはそれ以上の準拠を主張する場合、各要件のテスト方法を詳細に記述しなければなりません。 これにより、第三者が検証可能な形で実装の正当性を確認できます。
補足
ERC6734は、ArbitrumやOptimismのような既存のカスタムトークンリスト、そしてUniswap Token List Projectを基礎として設計されています。 目的は、これらの既存仕様を拡張・整理することで、より明確で安全性の高いトークンリストを提供し、非Web3系の組織（一般企業や金融機関など）にも採用されやすくすることです。
JSON-LDを採用する理由
ERC6734では、トークンリストの表現にJSON-LD（JSON Linked Data）標準を採用しています。 JSON-LDを使用することで、自己主権型ID（Self-Sovereign Identity）や分散型ID（W3C DID）、検証可能な証明書（W3C Verifiable Credential）などの標準と容易に統合できるようになります。
これにより、以下のような利点があります。
| 項目 | 内容 |
|---|---|
| 相互運用性 | L1、L2、サイドチェーン間でトークンや発行者を共通の識別方式で扱える |
| 既存ツールの活用 | JSON-LDやW3C DID対応ツールをそのまま利用可能 |
| 意味の明確化 | schema.org の既知のデータプロパティを参照することで、各用語の意味を明確化 |
つまり、ブロックチェーン間で異なるトークンリストを使用していても、共通の語彙体系とスキーマ定義を持つことで、データの相互理解が可能になります。
セキュリティ
悪意あるURIへの対策
URI（リソース識別子）を利用する場合、リンク先が悪意のあるWebサイトや不正なリソースである可能性があります。 したがって、実装者は以下の点に注意する必要があります。
- URIで指定されたデータソースが信頼できるものであることを確認する
- トークンリストの内容（アドレスやトークン情報）が正確で改ざんされていないことを保証する
この仕様はデータスキーマに焦点を当てているため、同形異義攻撃（homoglyph attack）のような文字の見た目を悪用した攻撃（例：CVE-2021-42574）に対する特別な対策は不要とされています。
データプライバシー
この標準は、特定の国や地域の個人情報保護法や規制への準拠を義務付けるものではありません。 つまり、データの扱い方や保存方法に関しては実装者自身が責任を持ち、自国や対象市場の法規制（例：GDPRなど）に従う必要があります。
実運用時の注意点
この標準では、特定のアプリケーション・ツール・ライブラリを使用することを要求していません。 実装者は利用するソフトウェアやライブラリについて、以下のような適切な検証（デューデリジェンス）を行うべきです。
- ライブラリの信頼性とメンテナンス状況を確認する
- 外部依存関係に既知の脆弱性がないか確認する
- バージョン管理と署名の検証を徹底する
これにより、運用環境でのセキュリティリスクを最小限に抑えることができます。
国際化とローカリゼーション
多言語環境での利用を考慮し、この仕様ではW3Cの「Strings on the Web: Language and Direction Metadata」のベストプラクティスに従うことを推奨しています。 これは、Web上のテキストデータに対して以下のようなメタデータを適切に付与することを目的としています。
| 項目 | 内容 |
|---|---|
| 言語の特定 | 各文字列がどの言語で記述されているかを明示する |
| 文字方向の指定 | 左から右（LTR）または右から左（RTL）などのテキスト方向を指定する |
これにより、異なる文化圏や言語環境でも一貫した表示と処理が可能になります。
引用
Kelvin Fichter (@smartcontracts), Andreas Freund (@Therecanbeonlyone1969), Pavel Sinelnikov (@psinelnikov), "ERC-6734: L2 Token List [DRAFT]," Ethereum Improvement Proposals, no. 6734, March 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6734.
最後に
今回は「複数のブロックチェーン間で同じトークンを正確に識別・共有できるようにするための共通データ標準を定めた提案しているERC6734」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！
