はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、複数のブロックチェーンで異なる形式のアドレスやチェーン識別情報を相互変換できる仕組みを提案しているCAIP350についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIP・BIP・SLIP・CAIPについてまとめています。
概要
CAIP350は、各チェーンの名前空間（namespace）ごとに異なるアドレス形式やネットワーク識別方法を統一し、ERC7930で定義された「Interoperable Address（相互運用可能アドレス）」形式に変換する方法を定めています。 ERC7930は「アドレス＋チェーンID」のペアを扱う自己記述型の形式で、チェーンやアドレス種別のメタデータを内部に含むため、外部で追加情報をやり取りする必要を減らすことができます。 このCAIPでは、CASAシステムに「名前空間ごとのプロファイル」としてチェーン固有のシリアライズ方法を登録する仕組みを追加し、現在および将来のあらゆるチェーンが統一的にInteroperable Addressへ準拠できるようにします。
動機
既存のCAIP2やCAIP10はアドレスやチェーン情報をテキストで表す仕様ですが、以下の課題があります。
CAIP2については以下の記事を参考にしてください。
CAIP10については以下の記事を参考にしてください。
まず、オンチェーンでの利用を想定するとバイナリ形式が望ましい場合があり、既存仕様はこれに対応していません。 また、CAIP10はテキスト形式であるため、同一のアカウントでも表記方法の違いにより複数の表現が存在し得ます。 これは辞書キーなどで使う場合に重複エントリを招く原因になります。 さらに、人間が読みやすいよう長さを制限しているため、識別子から一部の意味情報を削らざるを得ない場合があり、その情報はウォレットでは取得できますがスマートコントラクト上では取得できません。 最後に、テキスト形式はエンコードのオーバーヘッドがあり、情報量に対する効率が低くなります。 CAIP350はこれらの問題を解消し、チェーン固有の仕様を考慮しながら、統一的かつ効率的なアドレス表現を実現することを目的としています。
仕様
CAIP350では、各チェーンの名前空間（namespace）において、異なる形式間を決定的かつ一意に変換する方法を定義します。 変換の対象となるのは、主に4種類の形式ペアです。
まず、そのチェーン固有の慣例的なアドレス文字列表現と、ERC7930が定義する「Interoperable Name（相互運用可能な名前）」形式との相互変換です。
次に、チェーンの識別子（chain reference）の慣例的な文字列表現と、ERC7930が定義する文字列表現との変換です。
さらに、ERC7930の「Interoperable Address」と、そのチェーンのchain referenceに対応するInteroperable Nameとの変換も含まれます。
そして最後に、そのチェーンに存在する全てのアドレス形式について、ERC7930のInteroperable Addressと、そのアドレスに対応するInteroperable Nameとの変換を定義します。
また、各名前空間は必ず、過去の定義と衝突しない唯一の2バイトのバイト列を割り当て、この値をERC7930で定義されるchainTypeプロパティに使用しなければなりません。
これらの内容は、相互運用性の最大化とレビューのために、CAIP350プロファイルとして必ず明記する必要があります。
Namespacesレジストリには、このプロファイルのテンプレートが用意されています。
補足
CAIP350を別で定義する理由は、すべてをERC7930の中に含めて「Living ERC（随時更新される標準）」として運用するのは不適切だったためです。 Ethereumのエコシステムでは、Living ERCは非常にまれで、現在はEIP1のみが該当します。 ERC7930では、フォーマットそのものの定義を確定させつつ、各チェーンのシリアライズ仕様は必要に応じて別途定義できる方が望ましいとされています。 もしすべてをERC7930内で扱うと、仕様策定や編集の負担がERC7930の著者に集中してしまいますが、CASAのアプローチでは、各チェーンのエコシステムに関わる当事者が自分たちの名前空間のプロファイルを定義できるため、作業の分担と効率化が可能になります。
セキュリティ
CAIP350のプロファイルは、チェーンの特性によってはInteroperable Addressに求められる「正規性（canonicity）」を保証できない場合があります。 正規性とは、1つのアドレスに対して常に同一の表現を持つ性質を指します。 この保証が欠けると、その正規性を前提として動作するシステムで予期しない挙動が発生する可能性があります。 そのため、もし正規性を確保できない場合は、プロファイル内の「Extra Considerations」欄にその旨を明記する必要があります。
互換性
CAIP350は、CAIP2およびCAIP10との互換性を重視しています。 ただし、すべての変換が常に容易に行えるわけではなく、以下の2種類のケースが存在します。
まず、「変換は可能だが難しいケース」です。 これは変換の時に追加のリソースが必要となり、ネットワークやストレージに制約のあるクライアントでは対応が難しい場合です。 例として、CAIP2で短縮されたGenesis Blockhashを含むSolanaのアドレスを、完全な形式のCAIP350へ変換するケースが挙げられます。 このような変換は推奨されますが、対応できないクライアントであっても標準に準拠していると見なされます。
次に、「変換が不可能なケース」です。 例えば、非常に大きなEVMのchainidはCAIP350では表現できても、CAIP2では長さ制限のため表現できません。 また、CAIP10のみが定義されていてchainTypeが存在しないチェーンは、CAIP350へシリアライズすることができません。
クライアントライブラリは、この2つのパターンを区別して、それぞれ異なるエラーを返すことが推奨されます。
引用
Copyright and related rights waived via CC0.
最後に
今回は「複数のブロックチェーンで異なる形式のアドレスやチェーン識別情報を相互変換できる仕組みを提案しているCAIP350」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！
