相互運用性の Web をナビゲートする: 任意のメッセージ パッシング プロトコルの詳細

紹介

未来はマルチチェーンです。 スケーラビリティの追求により、イーサリアムはロールアップへと向かっています。 モジュール型ブロックチェーンへの移行により、アプリチェーンへの注目が再燃しています。 そして、地平線の向こうでは、アプリケーション固有のロールアップ、L3、ソブリンチェーンのささやきが聞こえてきます。

しかし、これには断片化の代償が伴います。 そのため、ブリッジングの必要性に対処するために基本的なブリッジの最初の波が開始されましたが、多くの場合、機能は制限されており、セキュリティは信頼できる署名者に依存しています。

相互接続されたWeb3の終盤戦はどのようなものになるのでしょうか? すべてのブリッジは、クロスチェーンメッセージングまたは「任意メッセージパッシング」(AMP)プロトコルに進化し、アプリケーションが送信元から宛先チェーンに任意のメッセージを渡すことができるようにすることで、新しいユースケースを解き放つと信じています。 また、構築者がユーザビリティ、複雑さ、セキュリティにおいてさまざまなトレードオフを行う「信頼メカニズムのランドスケープ」も出現するでしょう。

すべての AMP ソリューションには、次の 2 つの重要な機能が必要です。

• 検証: 送信元チェーンからのメッセージの有効性を宛先チェーンで検証する機能
• Liveness:送信元から宛先に情報を中継する機能

100%トラストレスな検証は実現不可能であり、ユーザーは、検証がオンチェーンかオフチェーンかに応じて、コード、ゲーム理論、人間(またはエンティティ)、またはこれらの組み合わせのいずれかを信頼する必要があります。

相互運用性の全体像は、信頼メカニズムと統合アーキテクチャに基づいて分割されます。

信頼メカニズム:

1. トラストコード/数学:これらのソリューションでは、オンチェーンプルーフが存在し、誰でも検証することができます。 これらのソリューションは、通常、ライトクライアントに依存して、デスティネーションチェーン上のソースチェーンのコンセンサスを検証するか、デスティネーションチェーン上のソースチェーンの状態遷移の有効性を検証します。 ライトクライアントによる検証は、任意の長さの計算をオフラインで圧縮し、計算を証明するための簡単な検証をオンチェーンで提供するゼロ知識証明によって、はるかに効率的になります。
2. 信頼ゲーム理論:ユーザー/アプリケーションがトランザクションの真正性について第三者または第三者のネットワークを信頼しなければならない場合、追加の信頼の前提があります。 これらのメカニズムは、経済的インセンティブや楽観的なセキュリティなどのゲーム理論と組み合わせたパーミッションレスネットワークによって、より安全にすることができます。
3. 人間を信頼する:これらのソリューションは、大多数のバリデーターの誠実さや、異なる情報を中継するエンティティの独立性に依存しています。 相互作用する2つのチェーンのコンセンサスを信頼することに加えて、第三者への信頼が必要です。 ここで問題になっているのは、参加団体の評判だけです。 十分な数の参加エンティティがトランザクションが有効であることに同意した場合、そのトランザクションは有効と見なされます。

すべてのソリューションには、ある程度、コードと人間への信頼が必要であることに注意することが重要です。 欠陥のあるコードを含むソリューションはハッカーに悪用される可能性があり、すべてのソリューションには、コードベースのセットアップ、アップグレード、またはメンテナンスに何らかの人的要素があります。

統合アーキテクチャ:

1. ポイント・ツー・ポイント・モデル:すべての送信元とすべての宛先の間に専用の通信チャネルを確立する必要があります。
2. ハブ&スポークモデル:通信チャネルは、そのハブに接続されている他のすべてのブロックチェーンとの接続を可能にする中央ハブで確立する必要があります。

ポイント・ツー・ポイント・モデルは、接続されたすべてのブロックチェーンにペアワイズ通信チャネルが必要なため、拡張が比較的困難です。 これらのチャネルの開発は、異なるコンセンサスとフレームワークを持つブロックチェーンにとって困難な場合があります。 ただし、ペアワイズ ブリッジでは、必要に応じて設定を柔軟にカスタマイズできます。 また、ブロックチェーン間通信プロトコル(IBC)とハブ経由のマルチホップルーティングなど、直接的なペアワイズ通信の必要性はなくなりますが、セキュリティ、レイテンシ、コストに関する考慮事項が再び複雑になります。

コード/数学を信頼する

ライトクライアントは、デスティネーションチェーン上のソースチェーンのコンセンサスをどのように検証するのでしょうか?

ライトクライアント/ノードは、フルノードに接続してブロックチェーンと対話するソフトウェアです。 デスティネーションチェーン上のライトクライアントは、通常、ソースチェーンのブロックヘッダーの履歴を(順番に)保存し、トランザクションを検証するのに十分です。 relayersのようなオフチェーンエージェントは、ソースチェーン上のイベントを監視し、暗号的包含証明を生成し、ブロックヘッダーとともにデスティネーションチェーン上のライトクライアントに転送します。 ライトクライアントは、ブロックヘッダーを順番に保存し、各ブロックヘッダーには状態を証明するために使用できるマークルルートハッシュが含まれているため、トランザクションを検証できます。 このメカニズムの主な機能は次のとおりです。

1. 安全：

• コードの信頼とは別に、ライト クライアントの初期化中に別の信頼の前提が導入されます。 誰かが新しいライトクライアントを作成すると、カウンターパーティチェーンの特定の高さのヘッダーで初期化されます。 提供されたヘッダーが正しくない可能性があり、ライトクライアントは後でさらに偽のヘッダーでだまされる可能性があります。 ライト クライアントが初期化されると、信頼の前提は導入されません。 ただし、これは誰でも初期化を確認できるため、信頼の前提が弱いです。
• 情報を送信するために必要なリレイヤーには、活性の仮定があります。

1. 実装: 検証に必要な暗号化プリミティブのサポートの可用性に依存します

• 同じタイプのチェーンが接続されている場合(同じアプリケーションフレームワークとコンセンサスアルゴリズム)、両側のライトクライアントの実装は同じになります。 例: すべての Cosmos SDK ベースのチェーンの IBC。
• 2つの異なるタイプのチェーン(異なるアプリケーションフレームワークまたはコンセンサスタイプ)が接続されている場合、ライトクライアントの実装は異なります。 例:コンポーザブルファイナンスは、Cosmos SDKチェーンをIBC経由でSubstrate(Polkadotエコシステムのアプリフレームワーク)に接続できるようにするために取り組んでいます。 これには、サブストレート上のTendermint Lightクライアントと、Cosmos SDKチェーンに追加されたいわゆるHeavyfy Lightクライアントが必要です

1. 課題：

• リソース集約性:ブロックチェーンへの書き込みはコストがかかり、イーサリアムのような動的なバリデーターセットを持つチェーンで実行することは現実的ではないため、すべてのチェーンでペアワイズライトクライアントを実行するのはコストがかかります。
• 拡張性: ライト クライアントの実装は、チェーンの組み合わせごとに必要です。 実装がチェーンのアーキテクチャによって異なることを考えると、異なるエコシステムを拡張して接続することは困難です。
• コードの悪用: コードのエラーは脆弱性につながる可能性があります。 2022年10月のBNBチェーンエクスプロイトでは、すべてのIBC対応チェーンに影響を与える重大なセキュリティ 脆弱性 が明らかになりました。

ZKプルーフは、デスティネーションチェーン上のソースチェーンの状態遷移の有効性をどのように検証するのですか?

すべてのチェーンでペアワイズライトクライアントを実行することは、法外なコストがかかり、すべてのブロックチェーンにとって実用的ではありません。 IBCのような実装のライトクライアントは、ソースチェーンのバリデータセットを追跡する必要がありますが、これはイーサリアムのような動的なバリデータセットを持つチェーンでは実用的ではありません。 ZKプルーフは、ガスと検証時間を短縮するソリューションを提供します。 計算全体をオンチェーンで実行するのではなく、計算の証明の検証のみをオンチェーンで行い、実際の計算はオフチェーンで行います。 計算証明の検証は、元の計算を再実行するよりも短い時間と少ないガスで行うことができます。 このメカニズムの主な機能は次のとおりです。

1. セキュリティ: zk-SNARKは楕円曲線に依存し、zk-STARKはハッシュ関数に依存しています。 zk-SNARKは、信頼できるセットアップを必要とする場合と必要としない場合があります。 信頼できるセットアップは、それらの証明の検証に必要な配達確認の作成に使用されるキーの初期作成イベントを参照する、最初にのみ必要です。 セットアップイベントのシークレットが破棄されない場合、偽の検証によってトランザクションを偽造するために利用される可能性があります。 信頼できるセットアップが完了すると、信頼の前提は導入されません。
2. 実装:SNARK、STARK、VPD、SNARGなどのさまざまなZK証明スキームが現在存在し、現在SNARKが最も広く採用されています。 再帰的ZK証明は、証明の総作業を1台ではなく複数のコンピュータに分割できるようにする、もう一つの最新の開発です。 妥当性の証明を生成するには、次のコアプリミティブを実装する必要があります。

• バリデーターが使用する署名スキームの検証
• バリデーターセットのコミットメント(オンチェーンで保存される)にバリデーターの公開鍵の証明を含める
• 頻繁に変更される可能性のあるバリデータのセットを追跡する

1. 課題：

• zkSNARK内にさまざまな署名スキームを実装するには、フィールド外の算術演算と複雑な楕円曲線演算を実装する必要があります。 これを実現するのは簡単ではなく、フレームワークとコンセンサスに応じて、チェーンごとに異なる実装が必要になる場合があります。
• 証明に時間と労力が極端にかかると、専用のハードウェアを持つ専門チームだけがそれを行うことができ、集中化につながります。 プルーフ生成時間が長くなると、レイテンシーが発生する可能性もあります。
• 検証にかかる時間と労力が長くなると、オンチェーンのコストが増加します。

1. 例:Polymer Labs、Succinct LabsによるポリマーZK-IBC。 Polymerは、必要なペアワイズ接続の数を減らしながら接続性を向上させるために、 マルチホップ 対応のIBCに取り組んでいます。

信頼ゲーム理論

ゲーム理論に依存する相互運用性プロトコルは、参加エンティティからの誠実な行動をどのように奨励するかに基づいて、大きく2つのカテゴリに分類できます。

1. 経済安全保障:複数の外部参加者(バリデーターなど)が、ソースチェーンの更新された状態についてコンセンサスに達します。 これはマルチシグの設定と似ていますが、バリデーターになるためには、参加者は一定量のトークンを賭ける必要があり、悪意のある活動が検出された場合にスラッシュすることができます。 パーミッションレスな設定では、誰でもステークを蓄積してバリデーターになることができます。 また、参加するバリデーターがプロトコルに従った場合に、経済的インセンティブとして機能するブロック報酬もあります。 したがって、参加者は正直に言うと経済的にインセンティブが付けられます。 ただし、盗まれる可能性のある金額が賭け金よりもはるかに高い場合、参加者は共謀して資金を盗もうとする可能性があります。 例: Axelar、Celer IM
2. 楽観的なセキュリティ:楽観的なセキュリティソリューションは、少数のブロックチェーン参加者のみが生きており、正直で、プロトコルのルールに従っていると仮定する少数派信頼の仮定に依存しています。 このソリューションでは、1 人の誠実な参加者のみが保証を保持する必要があります。 最も一般的な例は、誰でも不正の証拠を提出できる最適なソリューションです。 ここには経済的なインセンティブもありますが、正直なウォッチャーでさえ、不正な取引を見逃すことは現実的可能です。 楽観的なロールアップもこのアプローチを活用します。 例:Nomad、ChainLink CCIP

• Nomadの場合、ウォッチャーは詐欺を証明できます。 ただし、Nomadウォッチャーは執筆時点でホワイトリストに登録されています。
• ChainLink CCIPは、悪意のある活動を監視することを唯一の目的として、分散型のオラクルネットワークで構成される不正防止ネットワークを活用します。 CCIPのAnti-Fraud Networkの実装はまだ見られません。

これらのメカニズムの主な機能は次のとおりです。

1. セキュリティ:どちらのメカニズムでも、ゲーム理論のメカニズムが効果的であるためには、バリデーターとウォッチャーの許可なしの参加が不可欠です。 経済安全保障メカニズムの下では、ステークされた金額が盗まれる可能性のある金額よりも少ない場合、資金はよりリスクにさらされる可能性があります。 楽観的なセキュリティメカニズムの下では、誰も不正の証拠を提出しない場合、または許可されたウォッチャーが侵害/削除された場合に、楽観的な解決策に対する少数派信頼の仮定が悪用される可能性がありますが、経済セキュリティメカニズムは、セキュリティの活性に同じ依存性を持ちません。
2. 実装：

• 独自のバリデーターを持つミドルチェーン:外部バリデータのグループは、ソースチェーンを監視し、呼び出しが検出されるたびにトランザクションの有効性についてコンセンサスに達し、コンセンサスに達した場合は宛先チェーンにアテステーションを提供します。 バリデーターは通常、一定量のトークンをステークする必要があり、悪意のあるアクティビティが検出された場合にスラッシュすることができます。 例:Axelar Network、Celer IM
• オフチェーンエージェント経由:オフチェーンエージェントは、事前に定義された時間枠内に、オフチェーンエージェントが不正の証拠を提出し、トランザクションを元に戻すことができる、楽観的なロールアップのようなソリューションを実装するために使用できます。 例: Nomad は、独立したオフチェーンエージェントに依存して、ヘッダーと暗号化証明を中継します。 ChainLink CCIPは、クロスチェーントランザクションの監視と証明のために既存のオラクルネットワークを活用します。

1. 課題：

• バリデーターの過半数が共謀した場合、信頼の仮定が悪用されて資金を盗む可能性があり、これには二次投票や不正証明などの対策が必要です。
• ファイナリティ:楽観的なセキュリティベースのAMPソリューションでは、ユーザーやアプリケーションが不正防止の期間を待つ必要があるため、ファイナリティと活性が複雑になります。

1. 利点：

• リソースの最適化:このアプローチは、通常、検証がオンチェーンで行われないため、通常、リソースを大量に消費しません
• 拡張性:このアプローチは、コンセンサスメカニズムがすべての種類のチェーンで同じままであり、異種ブロックチェーンに簡単に拡張できるため、より拡張性があります。

人間を信頼する

1. 多数派の誠実さの仮定:これらのソリューションは、複数のエンティティがトランザクションを検証して署名するマルチシグの実装に依存しています。 最小しきい値に達すると、トランザクションは有効と見なされます。 ここでの前提は、大多数のエンティティが誠実であり、これらのエンティティの過半数が特定のトランザクションに署名している場合、それは有効であるということです。 ここで問題になっているのは、参加団体の評判だけです。 例:マルチチェーン(Anycall V6)、ワームホール。 スマートコントラクトのバグによるエクスプロイトは、2022年初頭のワームホール ハッキング で証明されているように、依然として可能です。
2. 独立性: これらのソリューションは、メッセージ パッシング プロセス全体を 2 つの部分に分割し、2 つのプロセスを管理するために異なる独立したエンティティに依存します。 ここでの前提は、2 つのエンティティが互いに独立しており、共謀していないことです。 例: LayerZero。 ブロックヘッダーは分散型オラクルによってオンデマンドでストリーミングされ、トランザクションプルーフはリレイヤーを介して送信されます。 配達確認がヘッダーと一致する場合、トランザクションは有効と見なされます。 プルーフマッチングはコード/数学に依存していますが、参加者はエンティティが独立していると信頼する必要があります。 LayerZero上に構築されたアプリケーションには、OracleとRelayerを選択する(または独自のOracle / Relayerをホストする)オプションがあるため、個々のOracle/Relayerの共謀に対するリスクが制限されます。 エンドユーザーは、LayerZero、サードパーティ、またはアプリケーション自体がオラクルとリレイヤーを独立して実行していることを信頼する必要があります。

どちらのアプローチでも、参加している第三者機関の評判は、悪意のある行動を思いとどまらせます。 これらは通常、バリデーターやオラクルのコミュニティ内で尊敬されているエンティティであり、悪意を持って行動した場合、評判の低下や他のビジネス活動に悪影響を与えるリスクがあります。

信頼の前提を超えて、相互運用性の未来

AMPソリューションのセキュリティとユーザビリティを考慮する一方で、基本的なメカニズム以外の詳細も考慮する必要があります。 これらは時間の経過とともに変化する可能性のある可動部分であるため、全体的な比較には含めませんでした。

• コードの整合性: 最近の多くのハッキングでは、コードのバグが悪用されており、信頼性の高い監査、綿密に計画されたバグ報奨金、および複数のクライアント実装が必要です。 すべてのバリデーター(経済/楽観/評判のセキュリティ)が同じクライアント(検証用ソフトウェア)を実行すると、単一のコードベースへの依存度が高まり、クライアントの多様性が低下します。 たとえば、イーサリアムは、geth、nethermind、erigon、besu、akulaなどの複数の実行クライアントに依存しています。 さまざまな言語で複数の実装を行うことで、クライアントがネットワークを支配することなく多様性が高まる可能性が高く、潜在的な単一障害点が排除されます。 複数のクライアントを持つことは、1つの特定の実装のエクスプロイト/バグのために少数のバリデーター/署名者/ライトクライアントがダウンした場合に、活性を高めるのにも役立ちます。
• セットアップとアップグレード可能性:ユーザーと開発者は、バリデーター/ウォッチャーがパーミッションレスでネットワークに参加できるかどうかを認識する必要があり、そうでなければ、パーミッションエンティティの選択によって信頼が隠されます。 スマートコントラクトのアップグレードは、悪用につながるバグを導入したり、信頼の前提を変更したりする可能性さえあります。 これらのリスクを軽減するために、さまざまなソリューションを実装できます。 例えば、現在のインスタンス化では、Axelarゲートウェイはオフライン委員会の承認(4/8しきい値)を条件としてアップグレード可能ですが、近い将来、Axelarはゲートウェイへのアップグレードをすべてのバリデーターにまとめて承認するよう要求する予定です。 Wormholeのコアコントラクトはアップグレード可能で、Wormholeのオンチェーンガバナンスシステムによって管理されます。 LayerZeroは、アップグレードを回避するために不変のスマートコントラクトと不変のライブラリに依存していますが、新しいライブラリをプッシュすることができ、デフォルト設定のdappsは更新されたバージョンを取得し、バージョンを手動で設定したdappsはそれを新しいバージョンに設定する必要があります。
• MEV:ブロックチェーンが異なれば、共通のクロックで同期されることはなく、ファイナリティまでの時間も異なります。 その結果、宛先チェーンでの実行順序と時間はチェーン間で異なる場合があります。 クロスチェーンの世界におけるMEVは、明確に定義することが困難です。 これにより、ライブ性と実行順序の間にトレードオフが生じます。 順序付けされたチャネルでは、メッセージの順序付けされた配信が保証されますが、1 つのメッセージがタイムアウトするとチャネルは閉じられます。 別のアプリケーションでは、順序付けは必要ないが、他のメッセージの配信には影響がないシナリオが望ましい場合があります。

動向と今後の展望

• カスタマイズ可能な付加的なセキュリティ: 多様なユースケースに適切に対応するために、AMP ソリューションは開発者により高い柔軟性を提供するインセンティブを与えられています。 Axelarは、アプリケーション層のロジックを変更することなく、メッセージの受け渡しと検証をアップグレードできる アプローチを導入し ました。 HyperLane V2 では、開発者が経済セキュリティ、楽観的セキュリティ、動的セキュリティ、ハイブリッド セキュリティなど、複数の選択肢から選択できるモジュールが導入されました。 CelerIMは、経済的なセキュリティとともに、さらに楽観的なセキュリティを提供します。 多くのソリューションは、メッセージを送信する前に、ソースチェーンで事前定義された最小数のブロック確認を待機します。 LayerZeroを使用すると、開発者はこれらのパラメーターを更新できます。 一部の AMP ソリューションでは、引き続き柔軟性が高まると予想されますが、これらの設計上の選択については、ある程度の議論が必要です。 アプリはセキュリティをどの程度構成できるか、また、アプリが標準以下の設計アーキテクチャを採用した場合はどうなるのか。 セキュリティの背後にある基本的な概念に対するユーザーの認識は、ますます重要になる可能性があります。 究極的には、AMP ソリューションの集約と抽象化が、おそらく何らかの形で組み合わせまたは 「付加的」セキュリティで行われることを予測しています。
• 「コード/数学を信頼する」メカニズムの成長と成熟:理想的なエンドゲームでは、ゼロ知識(ZK)証明を使用してメッセージと状態を検証することで、すべてのクロスチェーンメッセージの信頼が最小限に抑えられます。 この変化は、Polymer Labs や Succinct Labs などのプロジェクトの出現によってすでに目撃されています。 また、Multichainは最近、ZKプルーフによる相互運用性を実現するためのzkRouterホワイトペーパー を公開し ました。 最近 発表された Axelar Virtual Machineでは、開発者はInterchain Amplifierを活用して、Axelarネットワークへの新しい接続をパーミッションレスで設定することができます。 例えば、イーサリアムの状態に対する堅牢なライトクライアントとZKプルーフが開発されると、開発者はそれらをAxelarネットワークに簡単に統合して、既存の接続を置き換えたり強化したりできます。 LayerZeroは、そのドキュメントで、将来的に最適化された新しいプルーフメッセージングライブラリを追加する可能性について語っています。 ラグランジュのような新しいプロジェクトは、複数のソースチェーンからの複数の証明の集約を模索しており、ヘロドトスはZK証明を通じてストレージ証明を実現可能にしています。 ただし、このアプローチは、異なるコンセンサスメカニズムやフレームワークに依存するブロックチェーン間で拡張することが難しいため、この移行には時間がかかります。 ZKは比較的新しく複雑な技術であり、監査が困難であり、現在のところ、検証と証明の生成はコスト的に最適ではありません。 長期的には、ブロックチェーン上で拡張性の高いクロスチェーンアプリケーションをサポートするために、多くのAMPソリューションが信頼できる人間やエンティティを検証可能なソフトウェアで補完する可能性が高いと考えています。
• コードが悪用される可能性は、監査とバグ報奨金によって最小限に抑えることができます。 時間の経過とともに、これらのシステムは、その履歴がセキュリティの証明として機能するため、信頼しやすくなります。
• ZKプルーフの生成コストが下がります。 ZKP、再帰的ZK、プルーフアグリゲーション、および特殊なハードウェアの研究開発が進むにつれて、プルーフの生成と検証にかかる時間とコストが大幅に削減され、より費用対効果の高いアプローチになると予想されます。
• ブロックチェーンはよりzkフレンドリーになります。 将来的には、zkEVMは実行の簡潔な妥当性証明を提供できるようになり、軽量のクライアントベースのソリューションは、デスティネーションチェーン上のソースチェーンの実行とコンセンサスの両方を簡単に検証できるようになります。 イーサリアムの終盤戦では、コンセンサスを含む「すべてをzk-SNARKする」計画もあります。
• 人間性/評判/アイデンティティの証明:AMPソリューションのような複雑なシステムのセキュリティは、単一のフレームワークでカプセル化することはできず、複数のソリューションレイヤーを保証します。 例えば、アクセラは経済的インセンティブとともに、ノードの一部への議決権の集中を防ぎ、分散化を促進するために 二次投票 を実装しています。 人間性、評判、身元に関するその他の証明も、セットアップと許可のメカニズムを補完することができます。

Web3のオープン精神では、複数のアプローチが共存する複数の未来が見られる可能性があります。 実際、アプリケーションでは、複数の相互運用性ソリューションを冗長な方法で使用したり、ユーザーがトレードオフを開示したりして組み合わせたりすることができます。 ポイント・ツー・ポイント・ソリューションは「トラフィックの多い」ルート間で優先されるのに対し、ハブ・アンド・スポーク・モデルはチェーンのロングテールを支配する可能性があります。 結局のところ、相互接続されたWeb3の地形を形作るのは、私たち、ユーザー、ビルダー、コントリビューターの集合体です。

貴重なフィードバックをレビューし、提供してくださった Polymer Labs の Bo Du 氏と Peter Kim 氏、Axelar Network の Galen Moore 氏、Succinct Labs の Uma Roy 氏、LayerZero の Max Glassman 氏、Ryan Zarick 氏に感謝します。

参考文献一覧:

• アクセラー: https://docs.axelar.dev/
• CelerIM: https://im-docs.celer.network/developer/celer-im-overview
• ChainLink CCIP: https://blog.chain.link/introducing-the-cross-chain-interoperability-protocol-ccip/
• デブリッジ: https://docs.debridge.finance/
• IBC: https://tutorials.cosmos.network/academy/3-ibc/
• LayerZero: https://layerzero.gitbook.io/docs/
• マルチチェーン: https://docs.multichain.org/getting-started/introduction
• 遊牧民: https://docs.nomad.xyz/nomad-101/introduction
• ポリマーラボ: https://polymerlabs.medium.com/
• 簡潔なラボ: https://blog.succinct.xyz/
• ワームホール: https://docs.wormhole.com/wormhole/

追加の読書リスト:

• 任意のメッセージング ブリッジのナビゲーション: 比較フレームワーク : https://blog.li.fi/navigating-arbitrary-messaging-bridges-a-comparison-framework-8720f302e2aa
• L2Bridgeリスクフレームワーク: https://gov.l2beat.com/t/l2bridge-risk-framework/31
• 橋のホラティウス: https://maven11.substack.com/p/horatius-at-the-bridge

免責事項：

1. この記事は[medium]からの転載です。 すべての著作権は原著作者[LongHash Ventures]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。