メッセージング・ブリッジスタック：Connextを理解するパート1
この投稿は、安全なブリッジ設計について啓蒙し、Connextが存在する必要がある理由を説明することを目的としたシリーズのパート1です。パート2およびパート3は、今後数週間にわたって公開される予定です。
ここ数年、この領域ではブリッジプロトコルの不具合によるハッキングが発生しています。これは、ブリッジアーキテクチャのベストプラクティスの欠如や、外部で検証されたブリッジプロジェクトの数が増え続けていることと相まって、ほとんどの開発者に疑問を抱かせています：
安全なクロスチェーン開発は可能なのだろうか？
この疑問に答えることが、昨年ConnextがAmarokのアップグレードを設計する際に重視したことでした。私たちが気づいたのは、ブリッジングを第一原理から考え直し、具体的に特定する必要があるということでした：
- メッセージング・ブリッジのコンポーネントとは何か？
- 信頼とセキュリティ・リスクに最も寄与するコンポーネントはどれか？
- 各コンポーネントのリスクをどのような方法で相殺したり、オフロードしたりすることができるのか？
この投稿の目的は、上記を解明し、実行することで、私たち（そしてコミュニティ）がブリッジングを修正するためにどのように協力できると信じているかを説明することにあります。
ブリッジとは何か？
まず「ブリッジとは何なのか」という基本的なことから始めましょう。ブリッジという用語は、かなり拡大解釈されており、以下のような意味を持つようになりました：
- チェーン間でトークンを転送するためのアプリケーションUI
- チェーン間でトークンを送信するためのベースプロトコル
- チェーン間でトークンを送信するためのベースプロトコル（任意の）メッセージを送信するメカニズム
上記(3)は、クロスチェーン・メッセージング・プロトコル、一般化されたメッセージ・パッシング・システム、または相互運用性プロトコルと呼ばれることがあります。中には、(3)は明確にブリッジではないと主張する人もいますが、これは一般的に、この用語から自分たちを切り離すためのプロジェクトによる意味的な恣意に過ぎないでしょう。
この記事では、上記の(3)の定義として、メッセージングブリッジという用語を採用します（あらゆる種類のアプリケーション固有のブリッジの基礎となるプリミティブであるためです）。また、アプリケーション固有のブリッジは、NFTブリッジやトークンブリッジなどのように、その用途によって分類することにします。
メッセージング・ブリッジフロー
現在、世の中には多くの異なるメッセージングブリッジの構造が存在します。しかし、すべてのメッセージングブリッジは同じコア構造を持ち、以下の3つのコンポーネント（レイヤーとして可視化するのが最適です）を実装しています：
- 転送（Transport）： あるチェーンから別のチェーンへメッセージデータをポストする
- 検証（Verification）： データの正しさを証明する
- 実行（Execution）： ブリッジされたデータで何かをする
では、各レイヤーの仕組みについて掘り下げていきましょう。
転送
転送とは、あるドメインからデータのペイロードを読み出し、データの正しさを仮定することなく、別のドメインに中継する方法です。
転送は通常、1つまたは複数のオフチェーンアクターによって行われ、オリジンチェーンブリッジ・コントラクト上の「アウトボックス」を監視し、対応するデータをデスティネーションチェーンブリッジ・コントラクト上の「インボックス」にポストします。ブロックチェーンからの読み取りと書き込みのために、既存コンポーネントを使用してこれを構築するのはかなり簡単です。
転送レイヤーでハッキングやその他の障害が発生するリスクは、極めて小さいものとなりますが、最悪の場合、チェーン間でメッセージが送れなくなり、ブリッジのダウンタイムにつながります。サブグラフやリレーヤーネットワーク（Gelato、Keep3rなど）など、より分散的でフォールトトレラントな依存関係を使用すれば、トランスポートのダウンタイムリスクを低減できます。
検証
検証は、クロスチェーン通信の安全性を確保する方法です。あるデータのペイロードがチェーンを越えて転送された後、検証レイヤーは、宛先チェーンに投稿されたデータが、元々オリジンで投稿されたデータと同じであることを確認するために、何らかのメカニズムを使用します。
クロスチェーン・メッセージはどのように検証するのでしょうか？方法はいくつかありますが、それぞれ信頼性、レイテンシ、複雑さのトレードオフがあります。
この方法については、「相互運用性のトリレンマ」と「Optimistic Bridging」の記事でご紹介しています。また、ブリッジメッセージの検証のニュアンスについては、このシリーズの次の記事で説明する予定です。
この記事では、メッセージの検証はブリッジを構築する上で難しい部分であることを理解することが最も重要であるとしています。
検証レイヤーは、他のチェーン上の信頼できないソースから送られてくる任意かつ未知のデータを保護するもので、複雑な暗号化または外部依存のいずれかを必要とします。検証レイヤーの実装が安全であっても、メッセージ検証は、例えばm-of-n検証レイヤーに対する51％攻撃のように、信頼を最小化しなければ経済的攻撃のリスクもあります。
これらの課題によって、検証レイヤーの監査は非常に困難なものとなっています。
主要なブリッジのハッキングはすべて、何らかの形でメッセージ検証の失敗が関わっています。検証レイヤーがハッキングされると、攻撃者はメッセージングブリッジによって制御されるすべてのもの（例えば、チェーン間でブリッジされたロックされたトークンなど）への「特権的」なアクセスを得ることになります。このため、私たち（他の多くの人々）は、アプリケーション開発者が独自のメッセージ検証を行わないことを強く推奨しています。このレイヤーでミスを犯すと、壊滅的な影響を受ける可能性があるからです。
実行
実行レイヤーは、オフチェーンのアクターのセットで、データがチェーン間で転送され、正しいことが確認されると、ターゲットコントラクトに対して実行され、目的地のチェーン上で1つまたは複数のインタラクションをトリガーすることを保証する責任があります。ブリッジ実行レイヤーは、デスティネーションのコントラクトを呼び出すために、オリジンのメッセージングブリッジインターフェースに手数料を支払い、calldataを送信することによって、開発者がそれに対して構築するものです。
多くの場合、実行レイヤーは、オリジンでデータをmerkle rootsにパックするか（その後、デスティネーションでmerkle proofsを使ってそのデータをアンパックする）、ブロックヘッダー自体をリレーする（そしてデスティネーションでストレージ証明を実行する）かのどちらかを実行します。これは、トランスポートと検証には一般的にかなりのコストがかかるため（特にライトクライアントヘッダ検証のようなトラスト最小化手法）、バッチ処理によってトランザクションごとのコストを下げる必要があるためです。
実行レイヤーは、メッセージ検証のリスクを完全に引き継ぎますが、それ自体は低い信頼とセキュリティ・リスク・プロファイルを持っています。実行レイヤーは、バッチングや下位レイヤーとの受け渡しの際にメッセージを扱いますが、これらのやり取りは通常、非常に少なく、監査も容易となります。実行レイヤーのコントラクトは、手数料の分配とオフチェーンアクターへの流動性の支払いを主に担当するため、このレイヤーでのハッキングは通常、手数料収入の盗難や、ネットワークを積極的に運用するオフチェーンアクターの資金の損失を伴うだけで、これらはすべて、検証レイヤーでのハッキングよりもかなり低い影響しかありません。
特殊なケース：高速実行
実行に関する興味深い、そしてあまり評価されていない側面は、ある種のクロスチェーン相互作用を、その相互作用を含むメッセージが輸送され検証される前に、（安全かつ信頼なく）実行することが完全に可能であるということです。
この概念は、オプティミスティック・ロールアップ・ブリッジの「高速流動性」システムがどのように機能するかを考えると、おそらく最もよく理解できるでしょう。
アリスがオプティミズムからイーサリアムに100USDCを送金すると、通常、資金を受け取るまでに7日間待つ必要があります。この待ち時間を短縮するために、アリスはボブ（イーサリアムですでに100 USDCを持っている）に手数料を支払って代わりにすぐに資金を送ることができ、ボブはOptimismのブリッジを渡ってくる100 USDCを請求することができます。この例では、ボブは基本的にアリスに資金を「前払い」しており、7日後に返済されるというオンチェーン保証があるため、そうすることが安全であることは明確で
高速流動性のコアとなる原理は、高速実行を行うために一般化することも可能です。単純にチェーン間で100USDCを転送する代わりに、アリスはボブに自分の資金を前払いして、彼女に代わってコントラクト関数を呼び出すよう依頼することができます。アリスがチェーン間で「スローパス」コールを開始したことをボブが確認できる限り、ボブは将来的に返済されることをオンチェーンで保証することができます。
このメカニズムは、アリスが認証されていない（パブリック）関数を呼び出したい場合、つまり、呼び出し元が誰であるかを制限しない関数に適用することができます。例えば、アリスがDAOで、ターゲット関数がonlyDAO modifierを持つ場合、ボブがアリスのトランザクションを高速に実行することはまず不可能です。
まとめ
より安全なメッセージングブリッジを構築したいのであれば、まず検証レイヤーのセキュリティと信頼最小化の両方を改善することに優先的に注力すべきであることは明らかでしょう。
次回は、そもそもなぜ単一の安全なクロスチェーンメッセージ検証レイヤーを構築することが難しいのか、その理由を掘り下げます。そして、メッセージ検証の最良の結果を導き出し、そこに至るまでにどのようにセキュリティを最適化することができるかを考えていきましょう。
