クロスチェーンを見てみる ~Chainlink CCIP① 概要~
前回はTOKIのドキュメントを読んでみたが、次はCCIPのドキュメントを読んでみる
https://note.com/reysol_techcon/n/n68a6d3ae82e2
1. アーキテクチャ概要
トークンの転送に終始せず、ブロックチェーン間でのコントラクトのやり取りを実現するための仕組み
間にある３つのノード群のようなものの説明は後続であるっぽい
以下は、CCIPの基本的なアーキテクチャを示した図である。
ルーターはスマート・コントラクトで、ユーザーにシンプルで一貫性のあるインターフェースを提供します。
・別のブロックチェーン上のスマートコントラクト機能を呼び出す
・ トークンを別のブロックチェーン上のスマートコントラクトまたは外部所有口座（EOA）に転送する。
・ 同じトランザクション内で任意のメッセージとトークンを送信する
（この機能を使用して、トークンとそのトークンで何をするかという指示を別のブロックチェーン上のスマートコントラクトに転送する）
2. アーキテクチャ詳細
不変のIFがあるため、実装者・利用者は安心して実装できる
CCIP内部での処理（水色部分）はプロトコルのアップデートによって変わる必要がある
下図は、クロス・チェーン取引に関わるさまざまなコンポーネントの概要を示している。
スマート・コントラクトまたはEOA（外部所有アカウント）は、CCIPルーターと相互作用して、任意のデータを送信したり、トークンをクロス・チェーンで転送したりする。
濃い青色のコントラクトがCCIPインターフェース（ルーター）である。 CCIPを使うには、ユーザーはルーターとのやり取りを理解するだけでよく、CCIPアーキテクチャ全体を理解する必要はない。
注：CCIPインターフェイスは静的なもので、ユーザーに信頼性と安定性を提供するため、時間が経過しても一貫性を保っています。 水色のコントラクトはCCIPプロトコルの内部的なもので、変更される可能性があります。
オンチェーン上のコンポーネント
この記述だけでは分かりかねるけど、出してと受けてのコントラクトがあり、またオフチェーンからの検証のメッセージを受けて実行するコントラクトが存在
トークンの扱いは対象となるトークン種別によって仕組み（Burn and MintかLock and Mintか 等）を選択すべし
ルーター（Router）
ルーターは、CCIPユーザーがインターフェースをとる主要なコントラクト。
このコントラクトはクロスチェーンでのやり取りを開始する役割を担っている。 1つのブロックチェーンに1つのルーターコントラクトが存在する。
トークンを転送する際、発信者はルーターコントラクトに対してトークンを承認する必要がある。 ルーターコントラクトは、宛先固有のOnRampに指示をルーティングする。 メッセージが宛先チェーンで受信されると、ルーターは、ユーザーのアカウントにトークンを、または受信者のスマートコントラクトにメッセージを「配信」するコントラクトとなる。
コミットストア（Commit Store）
コミッティングDONは宛先チェーン上のCommitStoreコントラクトとやり取りし、ソースブロックチェーン上に確定メッセージのMerkleルートを保存する。 このMerkleルートは、実行DON（Decentlized Oracle Nodeの略）が宛先チェーンで実行する前に、リスク管理ネットワークによって快諾されなければならない。 CommitStoreはメッセージがRisk Management Networkによって快諾されることを保証し、CommitStoreはレーンごとに1つだけ存在する。
オンランプ（OnRamp）
1レーンにつき1つのOnRampコントラクトが存在する。 このコントラクトは以下のタスクを実行する。
・アカウントアドレス構文の検証など、宛先チェーン固有の妥当性のチェック
・メッセージサイズ制限とガス制限の検証 受信者のためにメッセージの順序を保持するためのシーケンス番号の追跡
・手数料の管理
・メッセージにトークン転送が含まれている場合、TokenPoolと連携する
・コミッティングDONによって監視されるイベントを発する
オフランプ（OffRamp）
レーンにつき1つのOffRampコントラクトが存在する。 このコントラクトは以下のタスクを実行する。
・コミットされ快諾されたMerkleルートに対して実行DONが提供する
・プルーフを検証することで、メッセージが真正であることを確認する
・検証後、OffRampコントラクトは受信したメッセージをすべてRouterコントラクトに送信する。
・CCIPトランザクションにトークン転送が含まれている場合、OffRampコントラクトはTokenPoolを呼び出し、正しいアセットを受信者に転送する
トークン・プール
各トークンは独自のトークン・プールに関連付けられており、ERC-20トークンの抽象化レイヤーとして、OnRampingとOffRampingにおけるトークン関連の操作を容易にするように設計されています。
トークン・プールは、トークン発行者がレーンごとにトークンを転送できる最大レートを設定できるセキュリティ機能であるレート制限を提供します。 トークン・プールは、ソースブロックチェーン上でトークンをロックまたはバーンし、宛先チェーン上でトークンをアンロックまたはミントするように設定される。 この設定により、4つの主要なメカニズムが生まれる
＜Burn and Mint＞
トークンはソースブロックチェーンでBurnされ、宛先チェーンで同量のトークンがMintされる。
＜Lock and Mint＞
トークンは発行ブロックチェーン上でロックされ、完全に担保された「ラップされた」トークンが送金先のブロックチェーン上でMintされる。 これらのラップされたトークンは、Burn and Mintメカニズムを使用して非発行ブロックチェーン間で転送することができます。
＜Burn and Unlock＞
トークンはソースブロックチェーンでBurnされ、宛先チェーンで同量のトークンが放出される。 この仕組みは、Lock and Mintの仕組みの逆である。 トークンを発行元のブロックチェーンに送るときに適用される。
＜Lock and Unlock＞
トークンは送金元のブロックチェーンでロックされ、宛先チェーンで同量のトークンが放出される。
トークンを扱う仕組みは、それぞれのトークンの特徴によって異なる。 以下にいくつかの例を挙げて説明する
＜例1 LINKトークン （Lock and Mint, Burn and Unlock）＞
LINKトークンは単一のブロックチェーン（Ethereum Mainnet）でMintされ、総供給量は固定されています。 そのため、CCIPは他のブロックチェーン上でネイティブにMintすることはできません。
LINKの場合、トークン・プールはイーサリアムのメインネット（発行ブロックチェーン）上でトークンをロックし、宛先チェーンでMintするように設定されています。 逆に、非発行ブロックチェーンからイーサリアムメインネットに転送する場合、LINKトークンプールはソース（非発行）ブロックチェーン上でトークンをBurnし、イーサリアムメインネット（発行）上でロックを解除するように設定されます。
＜例2 wETHなど （Lock and Unlock）＞
ラップされたネイティブアセット（例えばWETH）は、ロックとアンロックのメカニズムを使用します。 例えば、イーサリアムメインネットからOptimismメインネットに10WETHを送金する場合、WETHトークンプールはイーサリアムメインネット上の10WETHをロックし、Optimismメインネット上の10WETHをアンロックします。 逆に、OptimismメインネットからEthereumメインネットに戻す場合、WETHトークンプールはOptimismメインネット上で10WETHをロックし、Ethereumメインネット上で10WETHのロックを解除します。
＜例3 ステーブルコイン（Burn and Mint）＞
ステーブルコイン（USDCなど）は複数のブロックチェーン上でネイティブにMintできる。 それぞれのトークンプールは、ソースブロックチェーンでトークンをBurnし、宛先チェーンでネイティブにMintするBurn and Mintメカニズムを採用しています。
＜例4 PoRを持つトークン（Lock and Mint）＞
特定のブロックチェーン上にPoRフィードを持つProof Of Reserve（PoR）を持つトークンは、PoRフィードとの競合のため、他のブロックチェーンにまたがって適用される場合、Burn and Mintメカニズムにとって課題となります。 このようなトークンには、ロック・アンド・ミントのアプローチが好ましい。
リスク管理ネットワーク契約（Risk Management Network contract）
リスク管理契約は、祝福（bless）または呪い（curse）を許可されるリスク管理ノードアドレスのリストを保持する。 このコントラクトはまた、コミットされたMerkle Rootを祝福し、宛先チェーン上のCCIPを呪うためのクォーラムロジックも保持しています。 詳しくは「リスク管理ネットワークの概念」をお読みください。
オフチェーンのコンポーネント
コミットDONでのMerkleルト作成 → リスクマネジメントNWでのチェック → 実行DONでの実行 といっったざっくり３プロセスを経る
コミットDON（Commiting DON）
コミットDONにはいくつかのジョブがあり、各ジョブは指定されたソースチェーンと宛先チェーン間のクロスチェーントランザクションを監視する。
・各ジョブはソースブロックチェーン上の指定されたOnRampコントラクトからのイベントを監視する
・ジョブはファイナリティ（ソースブロックチェーンに依存）を待つ
・ジョブはトランザクションをバンドルし、Merkleルートを作成する（このMerkleルートはコミッティングDONの一部であるオラクルノードの定足数によって署名される）
・最後に、ジョブはMerkleルートを指定された宛先チェーン上のCommitStoreコントラクトに書き込む
実行DON（Executing DON）
コミットDONと同様に、実行DONにもいくつかのジョブがあり、それぞれがソースブロックチェーンとデスティネーションブロックチェーン間のクロスチェーントランザクションを実行する。
・ジョブはトランザクションがCommitStoreコントラクトで中継されたMerkleルートの一部であるかどうかをチェックする
・ジョブはRisk Management Networkがメッセージを祝福するのを待つ
・最後に、ジョブは有効なMerkleプルーフを作成し、OffRampコントラクトがCommitStoreコントラクトのMerkleルートに対して検証する
（これらのチェックが通過した後、ジョブはOffRampコントラクトを呼び出し、宛先ブロックチェーン上でCCIPトランザクションを完了させる）
コミットメントと実行を分離することで、リスク管理ネットワークは実行前にメッセージのコミットメントをチェックする十分な時間を持つことができる。
コミットメントと実行の間の遅延は、異常な再編成の深さ、潜在的なシミュレーション、スラッシングなどの追加チェックも可能にする。
コミットメントの保存はコンパクトであり、固定ガスコストであるが、ユーザーコールバックの実行は非常にガスを消費する可能性がある。 コミットメントと実行を分離することで、失敗した実行の再試行など、様々なケースでのエンドユーザーによる実行が可能になります。
リスク管理ネットワーク（Risk Management Network）
リスク管理ネットワークは、コミットDONがコミットストアにコミットしたMerkle ルートを監視する独立したノードのセットである。
各ノードは、コミットされたMerkleルートとOnRampコントラクトが受信したトランザクションを比較する。 検証が成功すると、リスク管理契約を呼び出し、コミットされたMerkleルートを「祝福」する。 十分な祝福票が集まると、ルートは実行可能になる。
異常が発生した場合、各リスク管理ノードはリスク管理コントラクトを呼び出し、システムを「呪う」。 呪われた定足数に達した場合、リスク管理コントラクトは一時停止され、CCIPトランザクションが実行されるのを防ぎます。 詳細はリスク管理ネットワークのコンセプトセクションをお読みください。
3. CCIPレート制限
Chainlink CCIPのトークン転送には、セキュリティ強化のためにレートリミットがあります。 レートリミットには最大容量とリフィルレートがあり、トークン転送が利用可能な容量の一部または全部を消費した後、最大容量が回復する速度です。
最大限のセキュリティのため、送信元と送信先の両方のブロックチェーンでレート制限が実施される。 これらのレート制限に達した場合、詳細情報を含む記述的エラーが生成され、送信者に返されます。 これにより、CCIPユーザーはdApps内でこれらのエラーを優雅に処理し、エンドユーザー体験を維持することができます。 エラーとその説明の包括的なリストは、エラーAPIリファレンス・ページで入手できます。
トークンプールレート制限（Token pool rate limit）
トークン単位で、単位時間あたりの送金上限がある
上限に達した場合は、次の時間のサイクルまで送金ができない（最短10秒）
個々のレーンでサポートされている各トークンについて、トークンプールレート制限は、一定時間内に転送できるトークンの総数を管理します。
例：Ethereum Mainnet →Base MainnetのsuUSDトークン
・プールの最大容量は200,000suUSD
・補充レートは毎秒2suUSD
・もしそのレーンで200,000 suUSDが送金されれば、全容量が消費される ・その後、ユーザーが20suUSDを送りたい場合、容量が補充されるまで少なくとも10秒待たなければならない
・このトークンのレーンでの最大スループットは10分ごとに1200 suUSD
集約レート制限（Aggregate rate limit）
トークン横断で送金可能な
各レーンはまた、サポートされるすべてのトークンにわたってそのレーンで送金可能な全体的な米ドルの価値を制限する集約レート制限を持っています。 セキュリティーを向上させるため、任意のレーンの集約レートリミットは、そのレーンのすべての個別トークンプールレートリミットの合計よりも常に低くなっています。
あるレーンの最大容量が100,000米ドル、リフィルレートが毎秒167米ドルで、合計60,000米ドルのトークン転送が数回実行された例を考えてみましょう。 この例では、利用可能な残りの容量は 40,000 米ドルである。 ユーザーが50,000米ドルに相当するトークンを送金しようとする場合、追加で必要となる10,000米ドルが補充されるまで少なくとも60秒待たなければならない。 このレーンでの最大スループットは、10分ごとに100,000米ドルです。
CCIP 実行待ち時間（CCIP execution latency）
Chainlink CCIPは、ソースチェーン上のブロック再編成のリスクを最小化するために、セキュリティ第一のアプローチをとるように意図的に設計されています。
CCIPのクロスチェーン取引のエンド・ツー・エンドの取引時間は、ソースチェーン上の取引がファイナリティに達するまでの時間に大きく依存します。 確定までの時間はブロックチェーンによって異なる。 例えばイーサリアムでは、ブロックがファイナライズされるまで約15分かかる。 クロスチェーン取引が、確定までの時間が約1秒であるAvalancheのような、確定がより速いブロックチェーンから開始される場合、エンド・ツー・エンドの取引時間はより速くなる。
ソースチェーンで支払われた手数料が、宛先チェーンでの実行コストの許容範囲内である場合、メッセージはリスク管理ネットワークによって祝福された後、できるだけ早く送信される。
リクエストから実行までの間に実行コストが増加した場合、CCIPは最終的な実行に到達するようガス価格を段階的に増加させますが、これによって追加の遅延が発生する可能性があります。 スマート・エクゼキューションの結果、1時間を超える実行遅延が発生することは稀なはずです。 Smart Execution time windowパラメータは、手動実行が有効になるまでの待ち時間を表します。
極端なネットワーク状況により、スマート実行時間ウィンドウの時間内にDONが実行されなかった場合、CCIPエクスプローラからメッセージを手動で実行できます。 詳しくは、手動実行の概念ガイドをお読みください。
4. アップグレード可能性
アップグレード可能な領域
CCIPにおけるアップグレード可能性とは、CCIPの運用範囲、機能セット、セキュリティ、または信頼性をアップグレードする能力のことです。
これらのアップデートは、以下の項目への変更を通じて適用される：
＜スマートコントラクトの設定＞
スマートコントラクトが公開する専用関数を使って設定を更新できる。 例えば、特定のレーンのレート制限の更新、サポートされるトークンのリスト、指定された宛先ブロックチェーンに対して呼び出すOnRampコントラクトなどです。
＜スマートコントラクトコード＞
一度デプロイされたスマート・コントラクト・コードは、修正やアップグレードができません。 唯一の選択肢は、コントラクトの新しいバージョン（OnRamp、OffRamp、Token Poolなど）をデプロイし、設定変更によって呼び出し元のコントラクトを新しくデプロイされたコントラクトにリダイレクトすることです。
例外として、ルーターコントラクト（Router）があります。ルーターコントラクトは、ソースチェーンと宛先チェーンの両方で、CCIPユーザーの主要なインターフェースとなっています。 このコントラクトと統合する開発者の信頼性と安定性を確保するため、このコントラクトは静的で一貫した状態を維持している。
実装プロセス
処理部分のコントラクトはプロキシ経由のためアップグレード可能
（但し、インターフェースとなるルーターコントラクトは対象外）コントラクトの更新はノードオペレータの承認（署名）を持って実行される
CCIPのすべてのオンチェーン設定変更とアップグレードは、Role-based Access Control Timelock (RBACTimelock)スマートコントラクトを通過しなければならない。
どのような提案も、(1) 専用のManyChainMultiSig (MCMS) コントラクトによって提案され、RBACTimelockによって強制されるレビュー期間を経て、その間にCCIPを確保するノードオペレータの定足数が提案に拒否権を行使できるようになるか、(2) 専用のMCMSコントラクトによって提案され、CCIPを確保する複数のノードオペレータを含む独立した署名者の定足数によって明示的に承認され、時間的制約のある状況下で代替経路を提供しなければならない。
拒否権なしにタイムロックのレビュー期間を通過したオンチェーンアップデートは、誰でも実行可能になります。 これは、実行可能なアップグレードを処理するタイムロック-ワーカーを実行することで可能です。
CCIPオーナーコントラクトに関連するドキュメントとソースコードは、GitHubで読むことができます。
イーサリアム上の提案者マルチシグはEtherscanで見つけることができ、設定の詳細も読むことができる。
5. 手数料
分量が多いので、次の記事に回します、、
所感
概要の理解
トークンの送金に留まらない広く使える規格としようしている設計思想
俯瞰してのエコシステムは手数料の仕組みを見てから改めて整理
もう少し深掘りたいところ
（TOKIと同様に）オフチェーン部分のインセンティブ設計、分散性
USCDが大きなユースケースと理解。実際にどのようにして稼働しているか