【ITニュース解説】Protocol Upgrade Compatibility Review: OKX

この文章は、ブロックチェーン上で動く金融サービスを提供する「OKX」というプラットフォームが、システムを新しいバージョン（v2.0からv3.0）に更新する際に、その安全性を専門家が評価した報告書である。このような技術の進化と、それに伴うセキュリティの重要性を理解する上で、本報告書は示唆に富む内容である。

OKXは、いわゆる「DeFi（分散型金融）」と呼ばれる領域でサービスを展開している。DeFiとは、銀行のような中央管理者を介さず、ブロックチェーンという技術を使って金融取引を行う仕組みのことだ。OKXは、このDeFiの他にも、中央集権型の仮想通貨取引所や、イーサリアムという主要なブロックチェーンの処理能力を補う「L2（レイヤー2）ロールアップ」と呼ばれる技術を複数利用している。今回のアップグレードは、新しいガバナンス（システムの意思決定方法）や、異なるブロックチェーン間でお金をやり取りする「クロスチェーンブリッジ」という機能の導入、さらにはウォレットのセキュリティモデルの変更などが含まれている。

この報告書の目的は、OKXのシステムアップグレードが、特にブロックチェーン上で動く部分において、既存のシステムと問題なく連携できるか、また新たなセキュリティ上の弱点（脆弱性）を生み出さないかを徹底的に検証することだった。具体的には、システムをアップグレードする際の技術的な手法（プロキシ、ダイヤモンド、イミュータブルなどと呼ばれる）が、データの保存方法や機能の動作を適切に維持できるか、イーサリアムのメインネットワークとL2の挙動の違いが互換性の問題を引き起こさないか、そしてアップグレードの過程やその後で、ガバナンスやアクセス制御の仕組みが悪用される可能性がないか、といった点が重点的に調べられた。

審査の結果、全体的なリスクスコアは10点満点中7点と評価され、「高〜中程度のリスク」があるという結論に至った。これは、アップグレードによってL2と呼ばれる複数の補助的なブロックチェーンネットワーク間での互換性が複雑になり、たった一つのデータ保存の衝突や、ブリッジ（異なるチェーンをつなぐ仕組み）における攻撃の可能性が、50億ドル以上もの資産に危険を及ぼす可能性があると指摘されていることを意味する。

具体的に発見された主要な問題点をいくつか見ていこう。

まず「アップグレードの仕組み」に関して、OKXは「UUPS」と「Diamond」という二つのアップグレードパターンを組み合わせて使っている。これは、システムの一部を個別に更新できる柔軟な設計なのだが、L2環境で「DiamondLoupeFacet」という部分に「ストレージスロット衝突」という問題が指摘された。これは、新しい機能が既存の機能と同じ記憶領域を使ってしまい、管理者の権限が書き換えられたり、システムが停止するフラグが不正に操作されたりする可能性を意味する。もしこれが起きれば、ユーザーの資金が失われる恐れがある、非常に危険な問題だ。また、「proxiableUUID」という、正しいシステム部品が使われていることを確認する仕組みが一部のコンポーネントで欠けていることも指摘された。これにより、攻撃者がシステムを不正な実装に差し替え、完全に制御を奪い、資金を流出させる可能性も考えられる。

次に「クロスチェーンブリッジの互換性」だ。異なるブロックチェーン間で資産を移動させるこの機能には、「msg.sender」という、メッセージを送った人を示す情報がOptimismとzkSyncという異なるL2ネットワーク間で一貫していないという問題が見つかった。これにより、権限のチェックが迂回され、不正な融資や清算操作が行われる可能性がある。さらに、OptimismとzkSyncの間でトランザクションが最終的に確定するまでの時間差（ファイナリティ時間）が異なるため、「リプレイ攻撃」の危険性も指摘された。これは、Optimismで承認された取引が、まだzkSyncで同期される前に、再度zkSyncで実行されてしまい、資産が二重に発行されたり（ダブルミント）、二重に引き出されたりする（ダブルバーン）ことを意味し、10億ドル以上の資産が危険に晒される可能性がある。

「ガバナンスとタイムロック」の面でも課題が見つかった。システム変更を提案してから実際に適用されるまでの猶予期間である「タイムロック」が、メインネットワークでは72時間であるのに対し、L2では24時間と短いことが指摘された。これにより、もし攻撃者が一時的に管理者権限を奪った場合、L2上で不正なアップグレードをコミュニティが気付く前に実行してしまうリスクが高まる。また、L2には緊急時にシステムを一時停止するための多重署名（マルチシグ）による代替手段がないことも、緊急対応能力の低下を招くとされた。

「アクセス制御」については、L2契約において「renounceRole」という管理者権限を放棄する機能が、誰でも呼び出せる状態になっていることが問題視された。これは、もし管理者の秘密鍵が漏洩した場合、意図せず管理者権限を失い、緊急時の対応ができなくなるという運用上のリスクがある。

「テストと形式検証」については、L2環境でのストレージレイアウトの形式検証が不足していることや、アップグレード経路に対するテストカバレッジ（テストがカバーしている範囲）が80%未満である点が指摘された。これは、まだ発見されていないバグが存在する可能性を高め、潜在的な問題を抱えたままアップグレードが進むリスクがあることを示唆している。

さらに詳細な攻撃経路としては、「リエントランシー攻撃」の可能性も挙げられた。これは、新しい「CrossChainExecutor」という機能が、外部のL2コントラクトを呼び出す際に、自身の状態を更新する前に呼び出しを行ってしまうことで、攻撃者が悪意のあるL2コントラクトを通じて資金を繰り返し引き出すことができるという、古典的ながらも危険な脆弱性だ。「Delegatecall」という、別のコントラクトのコードを実行する機能を使う際に、信頼されていないライブラリが利用される可能性や、ライブラリのアドレスがホワイトリスト化されていないことも、任意のコード実行や状態破壊のリスクを高めると指摘された。L2でのアップグレードトランザクションにおいて、ガス（手数料）の静的な見積もりにより、複雑な初期化処理がガス制限を超え、アップグレードが途中で失敗し、システムが中途半端な状態になる可能性も挙げられた。

これらの問題に対し、報告書では具体的な推奨事項も示されている。最も重要なのは、L2上のすべての機能について「ストレージレイアウトの完全な監査」を行い、記憶領域の衝突を防ぐことだ。また、「ERC-1822 proxiableUUID()」というチェック機構をすべてのアップグレード可能な機能に導入し、互換性のない不正な実装が設定されるのを防ぐべきだとされている。クロスチェーンブリッジについては、異なるL2間でノンセ（一度しか使えない番号）を同期させる「統一されたクロスチェーンノンセマネージャー」を導入し、リプレイ攻撃の可能性を排除することが求められる。さらに、「msg.sender」の処理を一貫させるためのライブラリの導入や、L2のガバナンスタイムロック期間をメインネットワークと合わせること、緊急時のマルチシグによる一時停止機能の追加も推奨されている。管理者権限の喪失を防ぐために、「renounceRole」機能に管理者のみが使用できる制限を加えることや、リエントランシーガードの導入、ライブラリアドレスのホワイトリスト化、L2アップグレードトランザクションにおける動的なガス見積もりの採用なども、重要な改善点として挙げられている。

この報告書は、DeFiプラットフォームの安全性がいかに複雑で多層的な検討を必要とするかを示している。特に、複数のブロックチェーンやL2技術を組み合わせたシステムでは、それぞれの特性の違いが予期せぬ脆弱性を生み出す可能性があるため、綿密な設計と厳格なセキュリティレビューが不可欠となる。ブロックチェーン技術が進化し続ける中で、このようなセキュリティの課題に正面から向き合い、解決策を導き出すことは、将来の技術者にとって非常に重要な役割を担う。