クロスチェーンで再び盗難：製品の視点から見たクロスチェーン分野の設計ロジック深層解析
TechFlow厳選深潮セレクト
クロスチェーンで再び盗難：製品の視点から見たクロスチェーン分野の設計ロジック深層解析
ここ最近、頻発するクロスチェーンのセキュリティ問題が市場の広範な関心を集めています。本稿では、製品設計という観点から、なぜこの分野の製品にこれほど多くのセキュリティ問題が生じるのかを読者に説明したいと思います。
Web3業界の深掘り報道に専念し潮流を洞察著者：0xOar
制作：Seer Labs
序論：
最近、相次ぐクロスチェーンのセキュリティ問題が市場の広範な注目を集めています。本稿では製品設計の視点から、なぜこの分野の製品にこれほど多くのセキュリティ問題が生じるのかを読者に説明することを目的としています。なお、ここで指摘する問題がすべてのプロジェクトに当てはまるわけではなく、多くの問題は設計段階ですでに対策が講じられていることをあらかじめ明記しておきます。主な目的は、より多くの人々にこの分野の複雑さを理解してもらうことにあります。
まず一般的なクロスチェーンブリッジの設計方法について説明し、その後それらのブリッジが直面する可能性のあるセキュリティ問題について述べます。
01 万変しても変わらないクロスチェーンの仕組み
過去のレポートではすでにいくつかの異なるタイプの情報クロスチェーン方式について説明していますが、最終的な形態がどうであれ、製品設計の観点からはサイドチェーン（広義のサイドチェーン。本文中ではロールアップもサイドチェーンに含める。反論しないでください）、ハッシュ時間ロック、公証人（Notary）の三つのメカニズムに大別されます。
（一）サイドチェーン
この三つの方式の中で、サイドチェーン方式が最も高い安全性を持ちます。たとえばさまざまなロールアップやPolkadotのパラレルチェーンなどが該当します。
メインチェーンとサイドチェーンはセキュリティを共有しています。しかし、サイドチェーン方式は通常、元のチェーンとターゲットチェーンが同種構造であることを要求するため、適用可能なシナリオが大幅に制限されます。これがV神が多チェーンを支持しつつも、クロスチェーンには懐疑的である理由であり、セキュリティを共有できないクロスチェーン方式にはあまりにも多くの問題があるからです。
（二）ハッシュ時間ロック
この方式は、完全に非中央集権的な異種チェーン間のP2P型クロスチェーン方式として称されていますが、コストが高く、ユーザーの待ち時間が長いため、現時点での採用率は高くありません。また、依然として第三者が通貨交換の中継ノードとして機能する必要がある場合、安全性と非中央集権性を満たすためにいわゆる「中間コンセンサス層」が必要になります。
（三）公証人（Notary）方式
これは現在最も一般的な異種チェーン向けクロスチェーンブリッジ方式であり、市場にある大多数の製品は基本的に同じ起源を持ち、製品設計の観点からはほとんど差異がありません。主な違いはおそらく情報検証の方法や手順、公証人のコンセンサスアルゴリズム、ホットウォレットの署名アルゴリズムなどに集中しています。ユーザーエクスペリエンスや安全性の面でも大きな差はありません。したがって、セキュリティの観点からは、直面するリスクにも多くの共通点があります。
本稿では特に、公証人方式のクロスチェーンブリッジが共有する典型的なセキュリティリスクについて重点的にまとめ、分析を行います。
02 公証人方式の製品ロジックフロー
公証人方式が抱えるさまざまなリスクを理解する前に、このタイプのソリューションが製品設計上どのようなロジックを持っているかをまず理解する必要があります。
（一）概要
この方式の設計哲学は非常にシンプルです。異種資産のクロスチェーンニーズに直面した際、最も直感的なアプローチは「マッピング」です。つまり、ユーザーAがETHをイーサリアムからFantomへ移動させる場合、資産を実際に転送したり、Fantom上で新たに発行したり（それは不可能ですが）する必要はありません。代わりに、ユーザーAのETHを移動不能なアドレスに預け入れ、そのアドレスに存在するユーザーAのETH数量に応じて、Fantom上に1:1で対応するマップ資産を発行します。このマップ資産は、イーサリアム元チェーン上のそれらETHの利用権を表します。1:1のペッグ（価値連動）があるため、Fantomのユーザーもこの資産の価値を認めます。
最も簡略化されたクロスチェーンの流れ：
（二）設計の難しさ
ここには多くの問題が存在します。その中でも最大の問題はマルチシグウォレットの管理です。なぜなら、ETHをイーサリアムからFantomへ移動するのは入金処理ですが、ユーザーAが再び戻りたい場合は出金処理が関係してくるからです。
入金と出金における非中央集権性およびセキュリティが最大の難関となります。
1. 誰が資金を管理するか？ 2. 誰が取引を開始するか？ 3. 誰が取引を監視するか？ 4. ユーザーが本当に資金を送ったことをどう確認するか？ 5. ユーザーが出金したいという意思を持っていることをどう確認するか？ 6. リプレイ攻撃をどう防ぐか？ 7. 失敗した取引をどう再提出するか？ 8. マルチシグ管理者が悪意を持って行動したらどうなるか？ 9. システムダウン（ダウンタイム）が起きたらどうするか？
考えれば考えるほど複雑に感じられます。クロスチェーンブリッジの技術はマルチシグだけでなく、資産発行、クロスチェーン監視、非同期検証、さらには独立した中間コンセンサス層（新しいチェーン）の発行まで関わっています。
そのため、ユーザーの理解負担をさらに軽減するために、私はこのクロスチェーンプロセスを「入金」と「出金」の二つの部分に分け、それぞれを解説します。これにより皆さんの理解を深められると考えます。
（三）プロセスのさらに詳細な分解
1. 入金
先に断っておきますが、以下の図に示すプロセスは、私が独自に推演した設計案であり、厳密な検証を経ていないものです。設計ロジック内に潜む可能性のあるセキュリティ問題を探ることを目的としており、実際の製品設計として採用すべきものではありません。すべて適当な話です。
図に示すように、元チェーンからターゲットチェーンへの入金取引は原則として以下のステップを含みます：
（1）ユーザーがホットウォレットアドレスに資金を入金
（2）監視モジュールが取引を検知後、BP（コンセンサスノードかつマルチシグ管理者）が取引を発行
（3）コントラクトがBPの署名の正当性を検証
（4）ノードの許容誤差メカニズム（フォールトトレランス）を通過しているか
（5）通過していない場合は返金、通過した場合はマッピングアドレスの関係に基づきターゲットチェーンのアドレスに入金
（6）BPがこの入金取引を確認
（7）ビザンチンフォールト耐性を経て、マップトークンをユーザーのターゲットチェーンアドレスに送付
特に注意すべき点として、このプロセスは一般的な異種チェーン間のクロスチェーンを議論するためのものであり、Anyswapなどの方式と比較して、中間コンセンサス層上でユーザーがアドレスのマッピング関係を事前に登録するステップを追加しています。これは、異なる異種チェーンの取引が付帯情報を扱う方式が異なるため、統一的な処理を行うためです。EVMチェーン間の取引のみを扱う場合はこのステップは不要で、取引発行時に直接ターゲットチェーンアドレスを付与すればよいです。
本題に戻りますが、上記のプロセスからわかるように、第2ステップ以降ではさまざまなロジック検証問題や、異なる状況下での処理問題が生じます。
主な検証ロジックには以下が含まれます：
（1）取引を検知した後の、資産マッピングの開始およびユーザーAのターゲットチェーンアドレスへの送金取引の検証
（2）ターゲットチェーンでの取引発行およびその結果の検証。私のプロセス図に描かれた検証ロジック以外にも、偽物トークンの入金問題の検証、および異なるトークンを呼び出す際に必要な特別な処理などが含まれるべきです。
今後発生する可能性のあるセキュリティリスクをよりよくまとめるために、引き続き出金プロセスの理解を進めます。
2. 出金
出金プロセスは、ターゲットチェーン上のマップ資産を元チェーンの資産に交換するロジックを示しています。特に注意すべき点として、現在多くのトークンは複数チェーン上でバージョンが存在しており、多くのトークンが複数チェーンでネイティブトークンとして存在しています。そのため、多くのブリッジプロジェクトはしばしば資金プールを設けています。資金プールが十分に充実している場合、ユーザーはanyDAIのようなマップ資産の存在を感じることなく、直接ターゲットチェーン版のトークンと交換できます。しかし、これは全体のロジックに影響しません。分析を続けます。
図に示すように、ターゲットチェーンから元チェーンへの出金取引の流れは以下の通りです。（1）ユーザーが取引を発行（等量のマップ資産をターゲットチェーンのホットウォレットに送金）（2）BPの身元を検証し、あるBPが出金リクエストを発行（3）出金権限と署名を確認（4）ビザンチンフォールト耐性を経てリクエストが完了し、元チェーンで出金、元チェーンのホットウォレットからユーザーAに資金を送金（5）この過程でノード検証エラーまたはシステムダウンなどの問題が発生した場合は、ロールバックして再発行する。上記のプロセスからわかるように、ここでの主要な検証ロジックは以下の通りです。（1）発行および署名権限の検証（2）問題発生時のフォールトトレランスメカニズム
（四）セキュリティリスク
1. 設計ロジック上のセキュリティ問題
クロスチェーンブリッジの設計をより丁寧に理解すると、設計ロジック上での課題が非常に多いことがわかります。主に以下の三つの側面にまとめられます（関連する盗難ケースは各問題末尾に記載）
（1）入金
a) 入金コントラクトの権限バグにより、入金された資金がそのまま転送されてしまう。これはほぼすべてのコントラクトプロジェクトが遭遇する愚かな問題。b) 偽物トークンの入金問題。一部のプロジェクトがクロスチェーントークンの真正性を検証しなかったため、fakeTOKEN → realTOKEN（anyswap）。正直、これもかなり愚か。d) 偽物トークンの入金問題。ETHなどのネイティブ資産はERC20コントラクトとは異なり、多くの攻撃はETHに対する不適切な特別処理により、fakeETH → realETHとなる。これがWETHなどのラップド資産が普及した理由（thorchain）。c) 異なるトークンはすべてERC20標準だが、具体的な実装方法が異なり、あるいは追加のロジック（rebase, fallbackなど）を持つため、開発者が対応時に調査を怠ると問題が生じる。例えば（WETH、PERI、OMT、WBNB、MATIC、AVAX）などは送金完了後にsenderのカスタムfallback関数を呼び出して追加操作を行うため、クロスチェーンブリッジの判断が複雑になる（anyswap 2022.1.18）
（2）クロスチェーンメッセージ転送
aチェーンでの入金完了からbチェーンでの資産到着までの間、クロスチェーンブリッジの処理は独立したブロックチェーンシステムのように機能し、一般にDPoSなどのコンセンサスメカニズムが必要です。以下はすべてDPoSを前提とした考慮事項ですが、私はほとんどのノードがプロジェクト側によるものだと疑っており、そもそも中央集権化のリスクがある。a) 入金メッセージの監視。誰が最初にクロスチェーン処理提案を発行するか？ ランダム？ 順番？ 中間コンセンサス層のブロック生成順？ b) 複数の公証人が入金の正当性をどのように検証するか。もしデータソースがInfuraなどのデータプロバイダーに依存している場合、Infuraが単一障害点（SPOF）となる。最も安全なのは各自がノードを運営することだが、コストが非常に高くなる。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. その他のセキュリティリスク
しかし、ロジックフローで示せる問題は業務ロジック上の問題に過ぎず、すべてではありません。セキュリティの観点からは、さらに以下の三つのリスクも考慮すべきです。
（1）システミックリスク
例えば、元チェーンでの入金が当初成功したが、後にリバート（巻き戻し）された場合。これは重大な問題です。V神も言及しています。SolanaからEthereumへのクロスチェーン後、Solana側がリバートすれば、ユーザーの資産が倍増し、全く解決不能。しかし、Ethereumとセキュリティを共有するRollupのようなLayer2では、このような問題は発生しません。
（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にアクセスし、ブラウザキャッシュに機密データを保存した後、悪意あるサイトにアクセスした場合、xxxxの同源ポリシーに制限がなければ、その悪意サイトがxxxxのキャッシュデータを自由に取得できてしまいます。
（3）追加機能のリスク
一部のクロスチェーンブリッジプロジェクトは資産のクロスチェーンに加え、クロスチェーンでのコントラクト呼び出しも提供しており、これにより追加の複雑性が生まれます。攻撃者がaチェーンでbチェーン上のxコントラクトを呼び出す取引を発行。クロスチェーンブリッジはxコントラクトの中身を確認せずそのまま呼び出し、実はxコントラクトがbチェーン上でのマルチシグコントラクトであり、この呼び出しによってマルチシグアカウントが攻撃者のアドレスに変更され、実行成功後、ハッカーがbチェーン上でのクロスチェーンブリッジ資金を自由に操作できるようになる（Poly Network）。
03 まとめ
1. 本レポートの目的は、ユーザーがクロスチェーンブリッジのセキュリティリスクを明確に理解することを支援することであり、クロスチェーンブリッジがどれほど簡単に攻撃されやすいかを悪意を持って強調するものではありません。
2. 公証人方式のクロスチェーンブリッジは、少なくとも現時点では、ユーザーエクスペリエンスが最も良く、適用範囲が広く、コストが最も低い方式です。また、どんな製品も傷だらけの状態から成熟へと進化していく過程を経ます。ブロックチェーン製品が受ける攻撃は往々にして「ロジックの問題」です。これらの問題は時間の経過とともに、経験の蓄積と共に必ず改善されていくでしょう。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
