クロスチェーンブリッジはなぜ事故が多発する場所になるのか？

原文标题：《クロスチェーンブリッジはなぜこんなに多くの事故があるのか？》

原文作者：0xScopeチーム

前言

最近頻発するクロスチェーンのセキュリティ問題は市場の広範な関心を集めており、この記事では製品設計の観点から、この分野の製品のセキュリティ問題がなぜこれほど多いのかを読者に説明したいと思います。ここで明言しておくべきは、この記事で指摘される問題はすべてのプロジェクトに存在するわけではなく、大部分の問題は設計時に既に関連する対策が講じられています。この記事の目的は、より多くの人々がこの分野の複雑さを理解できるようにすることです。

記事の執筆ロジックは、まず一般的なクロスチェーンブリッジがどのように設計されているかを明確にし、読者のクロスチェーンブリッジに対する理解を深め、その後、これらのクロスチェーンブリッジが直面する可能性のあるセキュリティ問題をまとめるというものです。

一：万変不離其宗のクロスチェーンソリューション

以前の研究報告では、さまざまなタイプの情報クロスチェーンソリューションが説明されており、最終的な呈示がどのようなものであれ、製品設計の観点からは、サイドチェーン（広義のサイドチェーン、本文中ではロールアップもサイドチェーンに含まれます）、ハッシュタイムロック、オラクルのこの3つのメカニズムのみです。

（一）サイドチェーン

この3つのソリューションの中で、サイドチェーンのセキュリティが最も高いです。例えば、さまざまなロールアップやポルカドットのパラレルチェーンなどです。メインチェーンとサイドチェーンはセキュリティを共有します。

しかし、サイドチェーンソリューションは一般的に元のチェーンとターゲットチェーンが同型であることを要求します。これにより、適用可能なシナリオは大幅に減少します。これが、V神がマルチチェーンを支持する一方で、クロスチェーンを認めない理由でもあります。なぜなら、セキュリティを共有できないクロスチェーンソリューションは問題が多すぎるからです。

（二）ハッシュタイムロック

このソリューションは、ピアツーピアで最も非中央集権的な異種クロスチェーンソリューションとされていますが、コストが高く、ユーザーの待機時間が長すぎるため、現在の採用率はあまり高くありません。また、第三者が通貨交換の中間ノードとして必要な場合、セキュリティと非中央集権の要件を満たすために、いわゆる中間コンセンサス層が必要です。

（三）オラクルメカニズム

これは現在最も一般的な異種クロスチェーンブリッジソリューションであり、市場に出回っているほとんどの製品は基本的に同根同源です。製品設計の観点からは、ほとんど違いはありません。主な違いは、情報検証の方法や手順、オラクルのコンセンサスアルゴリズム、ホスティングウォレットの署名アルゴリズムなどに集中しています。使用体験やセキュリティの違いもあまり大きくありません。したがって、セキュリティの観点から見ると、直面するセキュリティリスクには多くの共通点があります。

この記事では、オラクルメカニズムのクロスチェーンブリッジが直面するいくつかの共通のセキュリティリスクをまとめて分析します。

二：オラクルメカニズムの製品ロジックフロー

オラクルメカニズムが直面するさまざまなリスクを理解する前に、このタイプのソリューションが製品の観点から見ると、主にどのような設計ロジックを持っているのかを理解する必要があります。

（一）簡述

このソリューションは、設計哲学の観点から見ると非常にシンプルです。異種資産のクロスチェーンのニーズに対して、最も直感的なソリューションは「マッピング」です。マッピングとは、ユーザーAがETHをイーサリアムからファントムにクロスチェーンする際に、資産を実際に移動させる必要はなく、ファントム上で再発行する必要もありません（これは不可能です）。まず、ユーザーAのETHを移動できないアドレスに預け、そのアドレスに存在するユーザーAのETHの数量に基づいて、ファントム上で対応する1:1のマッピング資産を発行します。マッピング資産は、イーサリアムの元のチェーン上のETHの使用権を表します。1:1のペッグがあるため、ファントム上のユーザーもこの資産の価値を認めます。

最も簡略化されたクロスチェーンフロー

（二）設計の難点

ここには多くの問題が存在しますが、その中で最大の問題はマルチシグウォレットの管理問題です。なぜなら、ETHがイーサリアムからファントムにクロスチェーンされるのは入金であり、ユーザーAが戻りたい場合は出金の問題が関わってくるからです。

入金と出金の非中央集権性とセキュリティが最大の難点となります。

1：誰が資金を管理するのか？

2：誰が提起するのか？

3：誰が取引を監視するのか？

4：どうやって確実にユーザーが資金を入金したことを確認するのか？

5：どうやってユーザーの資金が本当にそのユーザー自身が引き出したいものであることを確認するのか？

6：リプレイ攻撃をどう防ぐのか？

7：失敗した取引をどう再提出するのか？

8：マルチシグ管理者が悪事を働いた場合はどうするのか？

9：ダウンタイムが発生した場合はどうするのか？

考えれば考えるほど、ますます複雑に感じます。クロスチェーンブリッジの技術は、単にマルチシグに関わるだけでなく、資産発行、クロスチェーン監視、非同期検証、さらには独立した中間コンセンサス層（新しいチェーン）を発行する必要があります。

したがって、ユーザーの理解の難易度をさらに簡素化するために、クロスチェーンのプロセス全体を入金と出金の2つの部分に分けて説明します。これにより、皆さんがさらに理解を深める手助けをします：

（三）プロセスのさらなる細分化

1：入金

まず声明しておきますが、下図に示すプロセスは私自身が推論した設計案であり、詳細な検証は行っていません。これは設計ロジックにおいて発生する可能性のあるセキュリティ問題を探求するためのものであり、成型されたソリューションとして採用することはできません。全て無駄話です。

図に示すように、元のチェーンからターゲットチェーンへの入金取引は原則として以下のステップを含みます：

（1）ユーザーがホスティングアドレスに入金する

（2）リスナーがこの取引を監視し、BP（コンセンサスノードでもありマルチシグ管理者でもある）が取引を開始する

（3）コントラクトがBPの署名の正当性を検証する

（4）ノードのフォールトトレランスメカニズムを通過するかどうか

（5）もし通過しなければ戻し、通過した場合はマッピングアドレスの関係に基づいてターゲットチェーンアドレスに入金する

（6）BPがこの入金取引を確認する

（7）ビザンチン合意を経て、マッピングトークンをユーザーのターゲットチェーン上のアドレスに転送する

特に注意すべきは、このプロセスは一般的な異種クロスチェーンを議論することを目的としているため、anyswapなどのソリューションに比べて、中間コンセンサス層でユーザーにアドレス関係をバインドさせるステップが追加されています。これは主に異なる異種チェーンの取引に付随する情報の扱いが異なるため、統一的に処理するために、まずユーザーにマッピング関係をバインドさせるためです。

EVMチェーンの取引を処理する場合は、このステップは不要で、取引を開始する際にターゲットチェーンアドレスを直接付加すれば済みます。

本題に戻りますが、上記のプロセスから見ると、第二ステップからさまざまな論理検証問題や異なる状況での処理問題に直面することがわかります。

主な検証ロジックには以下が含まれます：

（1）取引を監視した後、資産マッピングの発起とユーザーAのターゲットチェーン取引の検証

（2）ターゲットチェーン取引の発起および取引結果の検証

もちろん、私のプロセスに描かれた検証ロジックの他にも、偽トークン入金問題の検証や、異なるトークンを呼び出す際に必要な特別な処理問題も含まれるべきです。

今後のセキュリティリスクの可能性をより良くまとめるために、次に出金のプロセスを理解していきます。

2：出金

出金のプロセスは、ターゲットチェーンのマッピング資産を元のチェーンの資産に戻すロジックを示しています。特に注意すべきは、現在多くのトークンが複数のチェーンのバージョンを持っていることです。つまり、多くのトークンが複数のチェーン上でネイティブトークンを持っています。そのため、一部のブリッジプロジェクトは資産プールを設立することがよくあります。資金プールが十分な場合、ユーザーはanyDAIのようなマッピング資産の存在を感じることなく、直接ターゲットチェーンバージョンのトークンに交換されますが、これは全体のロジックには影響しません。したがって、分析を続けます：

図に示すように、ターゲットチェーンから元のチェーンへの出金取引のプロセスは以下の通りです：

（1）ユーザーが取引を開始する（同量のマッピング資産をターゲットチェーンのホスティングウォレットに転送）

（2）BPの身分を検証し、あるBPが出金リクエストを開始する

（3）出金権限と署名を確認する

（4）ビザンチン合意を経て、元のチェーンでの出金リクエストを完了し、元のチェーンのホスティングウォレットからユーザーAに資金を転送する

（5）この間にノード検証エラーやダウンタイムなどの問題が発生した場合は、ロールバックして再度発起する必要があります。

上記のプロセスから見ると、ここで関わる主な検証ロジックには以下が含まれます：

（1）発起と署名権限の検証

（2）問題発生時のフォールトトレランスメカニズム

（四）セキュリティリスク

1：設計ロジック上のセキュリティ問題

クロスチェーンブリッジの設計を詳しく理解した後、設計ロジック上でクロスチェーンブリッジが直面する課題が非常に多いことがわかります。主に3つの側面の問題が含まれます（関連する盗難事例は問題の最後に示されています）。

（1） 入金

a) 入金コントラクトの権限の脆弱性により、入金された資金が直接転送されることがあります。これはほぼすべてのコントラクトプロジェクトが直面する愚かな問題です。

b) 偽トークン入金問題。特定のプロジェクトがクロスチェーントークンの真実性を検証していないため、fakeTOKEN -> realTOKEN（anyswap）という問題が発生します。正直言って、これも少し愚かです。

c) 偽トークン入金問題。ETHなどのネイティブ資産はERC20コントラクトとは異なり、多くの攻撃はETHの特別な処理が不適切であることから発生し、fakeETH -> realETHという問題が生じます。これがWETHなどのラップ資産が流行している理由でもあります。（thorchain）

d) 異なるトークンはすべてERC20標準ですが、具体的な実装方法が異なるか、追加のロジック（リベース、フォールバックなど）が存在します。開発者が適応時に調査を行わなかったため、（WETH、PERI、OMT、WBNB、MATIC、AVAXなど）は送金完了後にsenderがカスタマイズしたフォールバック関数を呼び出して追加の操作を行い、クロスチェーンブリッジの判断の複雑さを増加させました。（anyswap 2022.1.18）

（2） クロスチェーンメッセージ転送

aチェーンで入金が完了した後、bチェーンで資産が到着する前に、クロスチェーンブリッジの処理は独立したブロックチェーンシステムのようになります。つまり、コンセンサスメカニズムが必要であり、一般的にはdposが使用されます。以下はすべてdposを仮定した場合に考慮すべき問題ですが、すべてのノードがプロジェクト側のものである場合、まず中央集権リスクが存在します。

a) 入金メッセージのリスニング。誰が最初にクロスチェーン処理の提案を発起するのか？ランダム？それとも交代？それとも中間コンセンサス層のブロック生成順序に従うのか？

b) 複数のオラクルが入金の正確性を検証する方法。データソースがinfuraなどのデータプロバイダーから来ている場合、infuraは単一障害点リスクを持ちます。最も安全なのは各自がノードを維持することですが、コストが膨大です。

c) クロスチェーン処理が完了したことをどう確認するのか（b上に到着した）。未処理の状態にはいくつかのケースがあります：

i. クロスチェーンブリッジが処理を開始していない

ii. クロスチェーンブリッジが処理を開始したが、検証＆コンセンサスが通過しなかった

iii. クロスチェーンブリッジが検証を通過したが、bチェーンで取引を開始していない

iv. bチェーン上に取引があるが、失敗した（資金不足やその他の状況）

（3）マルチシグ検証問題

問題が多発する重災区であり、大部分はコードロジックの問題です。

a) 3/5署名。私はマルチシグリストにない署名を適当に構成し、それも+1と見なされます（chainswap）。

b) 中央集権問題。名目上はマルチシグですが、実際にはプロジェクト側が掌握しており、巨大な中央集権リスクがあります。

c) 署名検証方法。異なるチェーンの開発モデルが異なるため、開発者が接続時に漏れが生じることが避けられません。wormholeの例：solana上の検証署名関数はシステムコントラクト内の関数であり、正常にはシステムコントラクトを呼び出すべきですが、システムコントラクトのアドレスがコード内にハードコーディングされるべきところを、ここではシステムコントラクトアドレスをパラメータとして渡しており、ハッカーが出金時に偽のシステムコントラクトアドレスを渡すことで、署名検証を回避し、スムーズに資金を引き出しました。

（4） 返金

a) （2）-cで議論したように、クロスチェーンの状態には多くの可能性があり、いかなる状況でもユーザーに返金の方法を提供する必要があります。例えば、anyswapでは入金時にまず元のチェーン上でユーザーにanyTokenを発行し、その後ターゲットチェーン上でユーザーにanyTokenを発行し、元のチェーンのanyTokenをバーンします。これにより、問題がどこにあっても、ユーザーはanyTokenを保持することで自分の資産を示すことができます。このプロセスには3つのチェーン（元、ターゲット、クロスチェーンブリッジ）と4つの資産（元チェーンとターゲットチェーン上の元のトークン/anyToken）が関与しており、非常にコードロジックの問題が発生しやすいです。

b) Thorchainは2021年7月23日に発生した脆弱性で、ハッカーがコードロジックの問題を利用して巨額の偽入金を構築し、クロスチェーンブリッジが処理できず、返金ロジックに入ってしまい、ハッカーが巨額の返金を得る結果となりました。

2：その他のセキュリティリスク

しかし、論理フローで示される問題はビジネスロジック上の問題に過ぎず、すべてではありません。

セキュリティの観点から、私たちはさらに3つの側面のリスクを考慮する必要があります：

（1）システムリスク

例えば、元のチェーンの入金が最初に成功し、その後ロールバックされると、これは巨大な問題です。V神が議論したように、資産がSolanaからEthereumにクロスチェーンされた後、クロスチェーンが完了した後にsolanaがロールバックされると、ユーザーの資産が倍増し、解決策はありません。

しかし、Ethereumとセキュリティを共有するレイヤー2のロールアップのようなものでは、このような問題は発生しません。

（2）フロントエンドリスク

a) 偽のURL、例えばoxdao.fi、0xdao.fi、oxdai.fiなど。

b) XSS攻撃、すなわちクロスサイトスクリプト攻撃は、コード注入攻撃の一種です。例えば、www.xxxx.finance/?params=hackerscode12345のように、URLは確かに公式サイトですが、URLにハッカーのコードが含まれている場合、フロントエンド開発者がXSSを防ぐ注意を払わなければ、このコードがページ上で実行され、ユーザーがハッカーの送金取引を承認する署名を行うことになります。したがって、出所不明のリンクを開かないでください。

c) CORSクロスサイトサービス攻撃。厳格な同一オリジンポリシーの下では、ブラウザは自サイトからのコンテンツのみを読み込むことを許可します。つまり、www.xxxx.financeサイトに表示されるすべてのコンテンツや呼び出されるAPIは、xxxx.financeドメインから来るべきですが、現在ほとんどのプロジェクトはクロスサイト呼び出しを許可しています。つまり、xxxxのフロントエンドがquickswapのAPIを呼び出すことができ、逆もまた然りです。これは開発上の便利さをもたらしますが、リスクも伴います。

もし私がxxxx.financeにアクセスし、ブラウザのキャッシュにいくつかの機密データを保存した後、悪意のあるURLにアクセスした場合、xxxxの同一オリジンポリシーが制限されていなければ、その悪意のあるURLはxxxxにキャッシュされたデータを自由に取得できます。

（3）追加機能のリスク
一部のクロスチェーンブリッジプロジェクトは、資産のクロスチェーンだけでなく、クロスチェーンコントラクト呼び出しも提供しており、これが追加の複雑さをもたらします。

攻撃者がaチェーンでbチェーンのxコントラクトへの呼び出しを発起し、クロスチェーンブリッジがxコントラクトが何であるかを気にせずに直接呼び出した場合、xコントラクトがクロスチェーンブリッジのbチェーン上のマルチシグコントラクトであることに気づかず、この呼び出しがマルチシグアカウントを攻撃者自身のアドレスに変更することになります。実行が成功すると、ハッカーはクロスチェーンブリッジのbチェーン上の資金を自由に支配できるようになります（poly network）。

三：結語

1：本報告の目的は、ユーザーがクロスチェーンブリッジのセキュリティリスクをより明確に理解する手助けをすることであり、クロスチェーンブリッジがどれほど攻撃を受けやすいかを悪意的に誇張することではありません。

2：オラクルメカニズムのクロスチェーンブリッジソリューションは、少なくとも現時点では体験が最も良好で、適用範囲が最も広く、コストが最も低いソリューションです。また、どの製品も傷だらけから成熟へと進化する過程を経るものであり、ブロックチェーン製品が受ける攻撃は往々にして「論理問題」です。これらの問題は、時間の経過とともに経験が増すにつれて、必ず改善されていくでしょう。