L2BEATは実験を通じてLayerZeroを「解明」しました：なぜ「独立した安全性」が安全でないのか？
現在、プロジェクトはオラクルとリレーの変更権限に制限を設けておらず、ハッカーが権限を取得すると自由に攻撃を行うことができます。原文タイトル：《Layer Zeroを回避する: なぜ孤立したセキュリティはセキュリティではないのか》
著者：Krzysztof Urbański、L2BEATチームメンバー
編訳：Babywhale、Foresight News
L2BEATは設立以来、Layer 2プロトコルに関連するリスクを分析し理解するために多大な努力を注いできました。私たちは常にユーザーとエコシステムの最大の利益を出発点とし、プロジェクトや関連チームに対する個人的な好みに影響されない公正で独立した監視者となるよう努めています。だからこそ、プロジェクトチームがプロジェクトに投入した時間と努力を尊重しつつも、特定のプロトコルに存在する潜在的なリスクについて「警鐘を鳴らす」ことや懸念を指摘することがあります。安全に関する議論を早期に行うことで、エコシステム全体が潜在的なリスクに対してより良く準備し、疑わしい行動に早く反応できるようになります。
今日はクロスチェーンアプリケーションの共有セキュリティモデルについて議論したいと思います。現在、2つのセキュリティモデルがあります：共有セキュリティと独立アプリケーションセキュリティ。共有セキュリティは、すべてのRollupのようなものです。独立アプリケーションセキュリティは主に「omnichain」プロジェクトで使用されており、この種のプロジェクトはLayerZeroを主に使用しています。
共有セキュリティと独立セキュリティ
共有セキュリティとは、特定のトークンやアプリケーションが与えられたインフラストラクチャ上で動作することを指し、自由にセキュリティモデルを選択するのではなく、インフラストラクチャが課すセキュリティ要件に従わなければなりません。例えば、Optimistic Rollupsは通常、7日間の最終ウィンドウ期間を課します------このようなRollups上で動作するアプリケーションは、この期間を単純に無視したり短縮したりすることはできません。これは障害のように見えるかもしれませんが、理由があります。この期間はユーザーにセキュリティ保証を提供し、アプリケーションの内部セキュリティポリシーが何であれ、このセキュリティポリシーを遵守しなければなりません。アプリケーションはRollupsのセキュリティを強化することはあっても、弱体化させることはありません。
独立セキュリティとは、各アプリケーションがそのセキュリティを定義する責任を負い、インフラストラクチャによる制限を受けないことを指します。一見すると良いアイデアのように思えますが、アプリケーションの開発者がアプリケーションに必要なセキュリティ対策を最もよく理解しているからです。しかし同時に、これは各アプリケーションのセキュリティポリシーに関連するリスクの評価の責任をエンドユーザーに移転します。さらに、アプリケーション開発者が自由にセキュリティポリシーを選択できる場合、いつでも変更することができます。したがって、各アプリケーションのリスクを一度評価するだけでは不十分であり、アプリケーションのポリシーが変更されるたびに評価する必要があります。
存在する問題
私たちは、各アプリケーションが自由にセキュリティポリシーを定義できる独立セキュリティモデルが深刻なセキュリティ問題を引き起こすと考えています。まず、エンドユーザーのリスクが増加します。なぜなら、彼らは使用しようとしている各アプリケーションのリスクを検証しなければならないからです。
独立セキュリティは、このモデルを使用するアプリケーションのリスクも増加させます。例えば、セキュリティポリシーの変更に関する追加のリスクが増加します------攻撃者がアプリケーションのセキュリティモデルを変更しようとする場合、単に無効にして資金を枯渇させたり、他の方法で攻撃したりする方が簡単です。アプリケーションの上には攻撃を防ぐための追加のセキュリティ層がありません。
さらに、セキュリティポリシーがいつでも即時に変更できるため、アプリケーションをリアルタイムで監視し、ユーザーにリスクを通知することはほぼ不可能です。
私たちは、これはスマートコントラクトのアップグレード可能性に似ていると考えています。私たちはすでにL2BEATで警告を発しています。私たちは、スマートコントラクトにアップグレード機構を持つRollupやクロスチェーンブリッジについてユーザーに通知し、各ケースでのアップグレードの管理メカニズムを明示しています。これはすでにかなり複雑であり、独立したセキュリティモデルを使用することでその数は倍増し、効果的に追跡することはほぼ不可能になります。
だからこそ、私たちは独立したセキュリティモデル自体がセキュリティリスクであると考え、デフォルトではこのモデルを使用するすべてのアプリケーションはリスクがあると見なされるべきであり、そうでないことが証明されるまでそうであるべきだと仮定しています。
セキュリティの脆弱性を証明する
私たちは、仮説をテストするためにメインネットで実験を行うことに決めました。LayerZeroフレームワークを選んだのは、独立したセキュリティを中心にした最も人気のあるソリューションの1つだからです。私たちは安全なomnichainトークンを展開し、その後、悪意のあるトークンの引き出しを許可するようにセキュリティ設定を更新しました。トークンのコードはLayerZeroが提供するサンプルに基づいており、実際に展開された多くの他のomnichainトークンやアプリケーションと非常に似ているか、同じです。
しかし、詳細に入る前に、LayerZeroのセキュリティモデルがどのようなものであるかを簡単に説明しましょう。
LayerZeroはホワイトペーパーで、「信頼不要のチェーン間通信」は、プロトコルのセキュリティを確保するために2つの独立した参加者（オラクルとリレイヤー）が共同で行動することに依存していると指摘しています。
LayerZeroはそのウェブサイトで、コアコンセプトは「ULN（UltraLightNode）を実行し、構成可能なオンチェーンエンドポイントのユーザーアプリケーション」であると述べています。LayerZeroのオンチェーンコンポーネントは、2つの外部オフチェーンコンポーネントがチェーン間でメッセージを中継することに依存しています------オラクルとリレイヤーです。
メッセージMがAチェーンからBチェーンに送信されるたびに、次の2つの操作が行われます：
- まず、オラクルはAチェーンでメッセージMを送信するトランザクションが完了するのを待ち、その後Bチェーンに関連情報を書き込みます。例えば、AチェーンがメッセージMを含むブロックヘッダーのハッシュ値（異なるチェーン/オラクル間の正確な形式は異なる場合があります）を含むことになります。
- 次に、リレイヤーはBチェーンに「証明」（例えばMerkle Proof）を送信し、保存されたブロックヘッダーがメッセージMを含んでいることを証明します。
LayerZeroは、リレイヤーとオラクルが独立して誠実な参加者であると仮定しています。しかし、LayerZeroはホワイトペーパーでも述べているように、その仮定が満たされない場合、例えばリレイヤーとオラクルが共謀し、「オラクルが提供するブロックヘッダーとリレイヤーが提供するトランザクション証明が無効であるが、依然として一致する」という事態が発生する可能性があります。
LayerZeroは「LayerZeroの設計は共謀の可能性を排除します」と主張しています。しかし、実際にはこの主張は正しくありません（私たちが以下で示す実験で証明します）。なぜなら、各ユーザーアプリケーションが独自のリレイヤーとオラクルを定義できるからです。LayerZeroは設計によってこれらのコンポーネントが独立しており、共謀できないことを保証するのではなく、ユーザーアプリケーションがこれらの保証を提供します。アプリケーションがそれらを破壊することを選択した場合、LayerZeroにはそれを防ぐメカニズムがありません。
さらに、デフォルトでは、すべてのユーザーアプリケーションはいつでもリレイヤーとオラクルを変更でき、セキュリティ仮定を完全に再定義できます。したがって、特定のアプリケーションのセキュリティを一度確認するだけでは不十分です。なぜなら、確認後にいつでも変更される可能性があるからです。これは私たちが実験で示すことになります。
実験設計
私たちの実験では、シンプルなomnichainトークンCarpetMoonを作成し、EthereumとOptimismの両方で動作させ、LayerZeroを使用して2つのチェーン間で通信を行うことに決めました。
私たちのトークンは最初、LayerZeroが提供するデフォルトのセキュリティモデルを使用し、大（おそらくすべてではない）現在展開されているLayerZeroアプリケーションと完全に同じになります。したがって、一般的にLayerZeroを使用する他のトークンと同じくらい安全です。
まず、EthereumとOptimismに私たちのトークンコントラクトを展開しました：
https://ethtx.info/mainnet/0xf4d1cdabb6927c363bb30e7e65febad8b9c0f6f76f1984cd74c7f364e3ab7ca9/
次に、LayerZeroが2つのチェーン上のどのコントラクトがどのコントラクトに対応しているかを知るためのルーティングを設定しました。
https://ethtx.info/mainnet/0x19d78abb03179969d6404a7bd503148b4ac14d711f503752495339c96a7776e9/
トークンが展開され、LayerZeroを使用する他のすべてのomnichainトークンと完全に同じように見え、デフォルト設定で、疑わしい点はありません。
私たちは「テストユーザー」Aliceに10億枚のEthereum上のCarpetMoonトークンを提供しました。
https://ethtx.info/mainnet/0x7e2faa8426dacae92830efbf356ca2da760833eca28e652ff9261fc03042b313/
今、AliceはLayerZeroを使用してこれらのトークンをクロスチェーンでOptimismに移動させます。
私たちはトークンをEthereumのエスクローコントラクトにロックしました：
https://ethtx.info/mainnet/0xe4dc3757b86bfda8e7baddc088fb1a599e083ed77034c29e5dd8bd11f1e17771/。
取引を含むメッセージはLayerZeroを介してOptimismに送信されています：
クロスチェーンのトークンがOptimismでミントされ、Aliceは現在Optimismで10億枚のMoonCarpetトークンを持っています：
すべてが期待通りに進んでおり、Aliceはトークンをクロスチェーンで移動させ、Ethereumのエスクローコントラクトに10億枚のMoonCarpetトークンがあることを確認し、Optimismのアカウントにも10億枚のMoonCarpetトークンがあることを確認しました。しかし、すべてが正常であることを確認するために、彼女はトークンの半分をEthereumに戻します。
私たちはOptimismで5億トークンを焼却する取引を開始しました：
その取引に関する情報がEthereumに送信されます：
期待通りに、5億枚のMoonCarpetトークンがエスクローコントラクトからAliceのアドレスに戻ります：
https://etherscan.io/tx/0x27702e07a65a9c6a7d1917222799ddb13bb3d05159d33bbeff2ca1ed414f6a18。
ここまで、すべてが正常であり、仮定とも完全に一致しています。AliceはEthereumからOptimismにトークンをクロスチェーンで移動させ、再びクロスチェーンで戻すことができることを確認しました。彼女はMoonCarpetトークンについて心配する理由はありません。
しかし、仮定自体に問題があります------例えば、私たちのトークンの背後にいるチームが問題に直面し、悪人Bobが私たちのアプリケーションのLayerZero設定にアクセスできるようになった場合。
このように、Bobはオラクルとリレイヤーをデフォルトのコンポーネントから彼が制御するコンポーネントに変更できます。
注意すべきは、これはLayerZeroを使用する各アプリケーションに提供されるメカニズムであり、LayerZeroのアーキテクチャに根ざしており、いかなる種類のバックドアでもなく、標準的なメカニズムです。
したがって、Bobはオラクルを彼が制御するEOAに変更しました：
https://ethtx.info/mainnet/0x4dc84726da6ca7d750eef3d33710b5f63bf73cbe03746f88dd8375c3f4672f2f/。
リレイヤーも同様に変更されました：
https://ethtx.info/mainnet/0xc1d7ba5032af2817e95ee943018393622bf54eb87e6ff414136f5f7c48c6d19a/。
今、奇妙なことが起こります。オラクルとリレイヤーが現在Bobの完全な制御下にあるため、彼はAliceのトークンを盗むことができます。たとえOptimism上で何の行動も取らなくても（MoonCarpetトークンは依然としてAliceのウォレットにあります）、BobはEthereum上のMoonCarpetスマートコントラクトに（LayerZeroメカニズムを使用して）彼が他のチェーンでトークンを焼却したと主張し、Ethereum上のMoonCarpetトークンを引き出すことができます。
まず、彼は彼が制御するオラクルを使用してEthereumのブロックハッシュを更新します：
https://ethtx.info/0xde2edee2cc7f070120e96c9df90d86696970befcfc221e18c6ac4168bb5b1d92/。
今、彼はエスクローコントラクトから残りのトークンを引き出すことができます：
https://ethtx.info/0xda695f374b375d5372efeca37aae4c5a17f114d5a76db1e86edebb0924bcdcc7/。
実験結果
Aliceは、なぜ、いつエラーが発生したのかを全く知らないままです。突然、彼女のOptimism上のMoonCarpetトークンはEthereum上のトークンのサポートを失いました。
スマートコントラクトはアップグレード不可能で、期待通りに動作しています。唯一の疑わしい活動はオラクルとリレイヤーの変更ですが、これはLayerZeroに組み込まれた通常のメカニズムであるため、Aliceはこの変更が意図的であるかどうかを知ることすらできません。たとえAliceがこの変更を知ったとしても、すでに手遅れです------攻撃者は彼女が反応する前に資金を枯渇させることができます。
LayerZeroも無力です------これらは彼らのメカニズムの有効な実行であり、彼らは制御できません。理論的には、アプリケーション自体がオラクルとリレイヤーの変更を防ぐことができますが、私たちの知る限り、すでに展開されているアプリケーションはそのようなことをしていません。
私たちはこの実験を行い、誰かがそれに気づくかどうかをテストしましたが、予想通り、誰も気づきませんでした。LayerZeroを使用して構築されたすべてのアプリケーションを効果的に監視し、セキュリティポリシーが変更されたかどうかを確認し、その際にユーザーに警告することはほぼ不可能です。
たとえ誰かがオラクルとリレイヤーが変更されてセキュリティリスクをもたらしたことに気づいたとしても、手遅れです。新しいオラクルとリレイヤーは、伝達されるメッセージを自由に選択するか、単にチェーン間通信を無効にすることができ、ユーザーは通常それに対して無力です。私たちの実験は明確に示しています。たとえAliceがアプリケーションの設定の変更に気づいたとしても、彼女は彼女のクロスチェーントークンであまり多くのことをすることはできません------新しいオラクルとリレイヤーはもはや元の通信チェーンでメッセージを受け入れないため、メッセージをEthereumに戻すことはありません。
結論
私たちが見たように、私たちのトークンがLayerZeroを使用して構築され、そのメカニズムを期待通りに使用しているにもかかわらず、私たちはトークンのエスクローから資金を盗むことができました。もちろん、これはアプリケーション（私たちの例ではCarpetMoonトークン）の誤りであり、LayerZero自体の誤りではありませんが、これはLayerZero自体が何のセキュリティ保証も提供しないことを証明しています。
LayerZeroがオラクルとリレイヤーのセキュリティモデルについて説明する際、彼らはアプリケーションの所有者（または秘密鍵を持つ人）が不合理なことをしないと仮定しています。しかし、対抗的な環境では、この仮定は正しくありません。さらに、これはユーザーにアプリケーション開発者を信頼できる第三者として信頼させることを要求します。
したがって、実際には、LayerZeroを使用して構築されたアプリケーションのセキュリティについて何の仮定もできません------各アプリケーションはリスクがあると見なされるべきであり、そうでないことが証明されるまでそうであるべきです。
実際、全体の話は、私たちがL2BEATのウェブサイトにすべてのomnichainトークンを含めることを計画していたPRから始まりました------私たちはそれらのリスクを評価する方法を理解するのに苦労しました。リスクを分析する際に、私たちは実験のアイデアを提案しました。
L2BEATがオンラインになった場合、その結果は、LayerZeroを使用して構築された各アプリケーションの上に警告を配置し、潜在的なセキュリティリスクを警告する必要があるということです。しかし、私たちはセキュリティモデルについてより広範な議論を展開したいと考えています。なぜなら、私たちは独立したセキュリティが避けるべきパターンであると考えているからです。特に私たちの分野では。
私たちは、LayerZeroのような独立したセキュリティモデルがますます普及するにつれて、ますます多くのプロジェクトがそれを悪用し、大きな損害を引き起こし、業界全体の不確実性を高めると信じています。
