はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、異なるブロックチェーン上のアカウントを、共通の文字列形式で一意に識別できる仕組みを提案しているCAIP10についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIP・BIP・SLIP・CAIPについてまとめています。
概要
CAIP10は、CAIP2で定義されたブロックチェーンIDを基に、あらゆるブロックチェーン上のアカウントを一意に識別する方法を定める提案です。 ここでいう「アカウント」は、EVM（Ethereum Virtual Machine）でいうEOA（Externally Owned Account、外部所有アカウント）だけでなく、スマートコントラクトやアカウント抽象化による特殊アカウントも含みます。 CAIP10により、複数の異なるブロックチェーン間で、ウォレットやdApp（分散型アプリケーション）がユーザーのアカウント情報を共通形式で扱えるようになります。 従来はウォレットごとに独自のデータ構造を使ってアカウントを区別していたため、互換性がなく、マルチチェーン対応が複雑になっていましたが、CAIP10はそれを標準化して相互運用性を高めます。
動機
この提案の背景には、「特定のブロックチェーンに依存しない」形で、ウォレットとdApp間の通信を行えるプロトコルを設計したいという目的があります。 例えば、異なるチェーン上の資産（トークン）を扱うマルチチェーンウォレットやクロスチェーン対応アプリでは、ユーザーのアカウントを識別してやり取りする必要があります。 しかし、現状ではウォレットごとに独自の方法でアカウントを表現しており、それらを統一する仕組みがありません。 CAIP10は、既存のCAIP2の仕様を拡張し、各チェーン固有の文字列形式でアカウントを指定できるようにすることで、既存アプリとの互換性を保ちつつ新しいマルチチェーン対応の仕組みを実現することを狙っています。
CAIP2については以下の記事を参考にしてください。
CAIP10が導入されることで、ウォレットやアプリケーションは異なるチェーン間でアカウント情報を統一的に管理でき、ユーザー体験の向上や開発コスト削減が期待されます。
仕様
CAIP10では、アカウントID（account_id）を 「CAIP2で定義されたブロックチェーンID」＋「アカウントアドレス」の組み合わせで表します。
この2つをコロン（:）で区切った文字列形式で統一することで、あらゆるブロックチェーン上のアカウントを一意に識別できるようにします。
例として、Ethereumメインネット上の特定アドレスを表す場合は、以下のような形式になります。
eip155:1:0xAbC123...ここで、eip155:1 はCAIP-2で定義されたEthereumメインネットのチェーンID、0xAbC123... がアカウントアドレスです。
構文（Syntax）
account_id は大文字小文字を区別する文字列で、以下のような構造を持ちます。
account_id: chain_id + ":" + account_address-
chain_idCAIP2で定義されたブロックチェーンIDを指します。 半角英数字（小文字）とハイフン（-）が使え、最初の部分（例:eip155）は3〜8文字、後半（例:1）は1〜32文字です。 -
account_address実際のアカウントのアドレスです。 ブロックチェーンによって形式が異なり、最大128文字まで使用可能です。 使用できる記号は-、.、%のみで、それ以外の記号（:,/,\など）は使用できません。 もしそれ以外の記号を使う必要がある場合は、RFC3986で定義されたURLエンコード（例:%20）を用いて表現します。
また、非アルファベット記号を使う場合は、見た目が似ている文字によるホモグラフ攻撃のリスクにも注意が必要です。
Semantics
chain_idは、どのブロックチェーン上のアカウントかを示す識別子で、CAIP2の仕様に従って決定されます。account_addressは、そのチェーン固有の形式で表現されるアカウントアドレスで、大文字小文字は区別されます。
つまり、account_id という統一形式を使うことで、異なるブロックチェーン上のアカウントを衝突なく識別でき、マルチチェーン環境でのウォレットやdApp間の互換性が向上します。
補足
CAIP10のアカウントID形式は、複数のチェーンにまたがっても一意性を保ち、かつ人間が見ても理解しやすくなるように設計されています。 主な目的は3つあります。
- チェーン間の一意性 メインネットやテストネットの区別を含め、異なるチェーン同士でアカウントIDが重複しないようにすること。
- 可読性の向上
chain_idのプレフィックス（先頭部分）を見るだけで、どのブロックチェーンのアカウントかがすぐに分かるようにすること。 - 解析しやすい文字制限 使える文字や長さを制限して、システムが安全かつ簡単に解析できるようにすること。
正規化（Canonicalization）
一部のブロックチェーン、特にEVM系では、アドレス表記に正規化（canonicalization）の仕組みがあります。 例えば、EthereumではEIP55のように大文字小文字を混ぜたチェックサム付き表記が使われます。 また、HIP15のようにオプションとしてアドレスにサフィックスを付ける場合もあります。
EIP55については以下の記事を参考にしてください。
しかし、現時点のCAIP10仕様では正規化を必須としていません。 そのため、実装者はアカウントIDを扱う際に、重複防止や正規化を独自に考慮する必要があります。 また、CAIP10のプロファイルは、CAIPの名前空間仕様（CASA）で拡張情報を持つ場合があります。
テストケース
CAIP10形式の具体例として、以下のようなケースがあります。
# Ethereumメインネット（**EIP55**チェックサム付き）
eip155:1:0xab16a96D359eC26a11e2C2b3d8f8B8942d5Bfcdb
# Bitcoinメインネット
bip122:000000000019d6689c085ae165831e93:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6
# Cosmos Hub
cosmos:cosmoshub-3:cosmos1t2uflqwqe0fsj0shcfkrvpukewcw40yjj6hdc0
# Kusamaネットワーク
polkadot:b0a8d493285c2df73290dfb7e61f870f:5hmuyxw9xdgbpptgypokw4thfyoe3ryenebr381z9iaegmfy
# StarkNet Testnet
starknet:SN_GOERLI:0x02dd1b492765c064eac4039e3841aa5f382773b598097a40073bd8b48170ab57
# 最大長の例（106文字）
chainstd:8c3444cf8970a9e41a706fab93e7a6c4:6d9b0b4b9994e8a6afbd3dc3ed983cd51c755afb27cd1dc7825ef59c134a39f7
# Hederaアドレス（HIP-15によるオプションチェックサム付き）
hedera:mainnet:0.0.1234567890-zbhltこれらは、チェーンIDやアドレスの形式がブロックチェーンごとに異なることを示す例となっています。
互換性
過去のCAIP10では、使用できる文字がもっと制限されておりて英数字以外はほとんど使えませんでした。
さらに、それ以前の古い仕様では、account_address@chain_id のように @（アットマーク） で区切っていました。
# 旧仕様（2021年8月21日以前）
0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb@eip155:1このため、過去のシステムと連携する場合は、古い形式をサポートする必要があるケースがあります。 現行仕様は、より柔軟で読みやすく、異なるブロックチェーン間でも統一的にアカウントを表せる形に改善されています。
引用
Copyright and related rights waived via CC0.
最後に
今回は「異なるブロックチェーン上のアカウントを、共通の文字列形式で一意に識別できる仕組みを提案しているCAIP10」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！
