レイヤーゼロの回避

L2BEAT の当初から、L2 プロトコルに関連するリスクの分析と理解に多大な努力を払ってきました。ユーザーとエコシステムの最善の利益のために行動する、公平で独立した番犬になるために最善を尽くします。プロジェクトや関係するチームに対する個人的な好みが邪魔になることはありません。そのため、特定のチームがプロジェクトに費やす時間と労力を重視しているにもかかわらず、さまざまなプロトコルで赤信号をオンにしたり、懸念事項を指摘したりする必要があるのはよくあることです。セキュリティ関連の議論を早い段階で行うことで、エコシステム全体が潜在的なリスクに備え、疑わしい行動に早期に対応できるようになります。

今日は、クロスチェーン アプリケーションの共有セキュリティ モデルに関する議論を開始したいと思います。現在、共有セキュリティとアプリケーションごとのセキュリティの 2 つのアプローチがあります。最初の共有セキュリティは、たとえばすべてのロールアップで使用されます。2 つ目のアプリケーションごとのセキュリティは、「オムニチェーン」プロジェクトで使用されます。そのようなプロジェクトの代表的な例は、LayerZero です。

共有セキュリティと分離セキュリティ

共有セキュリティとは、特定のインフラストラクチャで実行されている特定のトークンまたはアプリがセキュリティ モデルを自由に選択できないことを意味します。代わりに、インフラストラクチャが課すあらゆるセキュリティ要件に従わなければなりません。たとえば、楽観的なロールアップでは、通常 7 日間のファイナリティ ウィンドウが課せられます。このようなロールアップで実行されるアプリは、この期間を単純に無視したり短縮したりすることはできません。障害のように見えるかもしれませんが、それは理由があって設けられた障害です。これにより、アプリの内部セキュリティ ポリシーに関係なく、そのロールアップで使用しているアプリによって保持されることが期待できる安全性の保証をユーザーに提供できます。アプリはロールアップのポリシーを強化するだけで、弱めることはありません。

分離されたセキュリティとは、インフラストラクチャによって制限されることなく、すべてのアプリがそのセキュリティを定義する責任があることを意味します。最初は、それは良い考えのように思えるかもしれません。結局のところ、アプリ開発者は、アプリに必要なセキュリティ対策を最もよく知っています。しかし同時に、すべてのアプリのセキュリティ ポリシーに関連するリスクを評価する責任をエンド ユーザーに移します。さらに、アプリ開発者がアプリ ポリシーを自由に選択できる場合は、いつでも変更することができます。そのため、アプリごとに 1 回リスクを評価するだけでは十分ではなく、アプリのポリシーが変更されるたびにリスクを評価する必要があります。

問題

各アプリが独自のセキュリティ ポリシーを自由に定義できる分離されたセキュリティ モデルは、深刻なセキュリティ上の懸念をもたらすと考えています。まず第一に、使用する予定のアプリごとにリスクを個別に検証する必要があるため、エンド ユーザーのリスクが増大します。

また、そのようなモデルを使用するアプリのリスクも高まります。隔離されたセキュリティは、セキュリティ ポリシーの変更に関する追加のリスクを追加します。攻撃者がアプリケーションのセキュリティ モデルを変更した場合、単純にそれを無効にして、資金を流出させたり、他の方法で悪用したりする可能性があります。アプリケーションの上には、誤用を防ぐ追加のセキュリティ レイヤーはありません。

さらに、セキュリティ ポリシーはいつでも即座に変更できるため、日常的にアプリを監視してユーザーにリスクを通知することは事実上不可能になります。

これは、スマート コントラクトのアップグレード可能性に似ています。L2BEAT ですでに警告しています。スマート コントラクトにアップグレード可能なメカニズムを持つロールアップとブリッジ、およびそれぞれのケースでアップグレード可能性を管理する正確なメカニズムについてユーザーに通知します。これはすでにかなり複雑であり、分離されたセキュリティ モデルでは、これがすべてのアプリで倍増し、効果的に追跡することがほとんど不可能になっています。

そのため、分離されたセキュリティ モデル自体をセキュリティ リスクと見なしており、そのようなモデルを使用するすべてのアプリは、そうでないことが証明されるまで、デフォルトで危険なものとして扱うと想定しています。

計画

メインネット上で、現実の世界で仮定をテストすることにしました。LayerZero フレームワークが実験用に選択されたのは、これが分離セキュリティをコアに使用する最も一般的なソリューションの 1 つであるためです。安全なオムニチェーン トークンを展開し、その後セキュリティ構成を更新して、悪意のあるトークンの引き出しを可能にしました。トークンのコードは、LayerZero が提供する例に基づいており、本番環境にデプロイされた他の多くのオムニチェーン トークンおよびアプリと非常に類似または同一です。

詳細に入る前に、LayerZero セキュリティ モデルがどのようなものか簡単に見てみましょう。

LayerZero のホワイトペーパーが明確に述べているように、その「トラストレスなチェーン間通信」は、プロトコルの安全性を確保するために連携する 2 つの独立したアクター (オラクルとリレイヤー) に依存しています。

LayerZero がその Web サイトで述べているように、そのコア コンセプトは、「ULN (UltraLightNode) を実行する、ユーザー アプリケーションで構成可能なオンチェーン エンドポイント」であるということです。LayerZero のオンチェーン コンポーネントは、チェーン間でメッセージを中継する 2 つの外部オフチェーン パーティ (オラクルとリレイヤー) に依存しています。

メッセージ M がチェーン A からチェーン B に送信されるたびに、次の 2 つのアクションが発生します。

• まず、オラクルは、チェーン A でメッセージ M を送信するトランザクションが完了するまで待機し、チェーン B にメッセージ バンドルのコミットメント (ブロック ヘッダーのハッシュなど) を書き込みます (正確な形式はチェーン/オラクルによって異なる場合があります)。そのメッセージ M を含むチェーン A で
• 次に、リレイヤーはチェーン B に、格納されたヘッダーにメッセージ M が含まれているという「プルーフ」(たとえば、マークル プルーフ) を送信します。

LayerZero は、「LayerZero の設計は、共謀の可能性を排除する」と主張しています。しかし、実際には、各ユーザー アプリケーションは独自の Relayer と Oracle を定義できるため、その説明は正しくありません (以下に示す実験で証明されています)。LayerZero は、これらのコンポーネントが独立しており、共謀できないことを設計上保証していません。これらの保証を提供するのは、ユーザー アプリケーション次第です。アプリケーションがそれらを壊すことを選択した場合、LayerZero の仕組みにはそれを止めるものは何もありません。

さらに、デフォルトでは、すべてのユーザー アプリケーションがいつでも Relayer と Oracle を変更できるため、セキュリティの想定が完全に再定義されます。そのため、特定のアプリのセキュリティを 1 回確認するだけでは十分ではありません。これは、実験で示すように、確認後いつでも変更される可能性があるためです。

実験

私たちの実験では、ZeroLayer を使用して両方のチェーン間で通信し、Ethereum と Optimism の両方で動作するシンプルなオムニチェーン トークン CarpetMoon を作成することにしました。

私たちのトークンは、最初は LayerZero によって提供されるデフォルトのセキュリティ モデルを使用するため、現在展開されているほとんどの (すべてではないにしても) LayerZero アプリケーションとまったく同じように見えます。したがって、一般的に、LayerZero を使用する他のトークンと同じくらい安全です。

まず、トークン コントラクトを Ethereum と Optimism の両方にデプロイします。
https://ethtx.info/mainnet/0xf4d1cdabb6927c363bb30e7e65febad8b9c0f6f76f1984cd74c7f364e3ab7ca9/
https://optimistic.etherscan.io/tx/0xf41389d71fa3942de5225efb067072728c6c6de56c241574187781db7c73d221

そして、ルーティングを設定して、LayerZero が両方のチェーンのどのコントラクトに対応するかを認識できるようにします。
https://ethtx.info/mainnet/0x19d78abb03179969d6404a7bd503148b4ac14d711f503752495339c96a7776e9/
https://optimistic.etherscan.io/tx/0x037b1bad33faa5607bb5835460a1d5caaf3a147dc3a09762ac7703befcdb3c3c

これでトークンがセットアップされました。LayerZero を使用する他のすべてのオムニチェーン トークンとまったく同じように見えます。デフォルトの構成では、疑わしいものは何もありません。

テスト ユーザー (彼女を Alice と呼びましょう) にテスト トークンを提供すると、Alice は 1B の CarpetMoon トークンを Ethereum 上に持っています。
https://ethtx.info/mainnet/0x7e2faa8426dacae92830efbf356ca2da760833eca28e652ff9261fc03042b313/

アリスは、LayerZero を使用してこれらのトークンを Optimism にブリッジします。

イーサリアムのエスクローでトークンをロックします。
https://ethtx.info/mainnet/0xe4dc3757b86bfda8e7baddc088fb1a599e083ed77034c29e5dd8bd11f1e17771/

トランザクションのメッセージは、LayerZero を介して Optimism に配信されています。
https://layerzeroscan.com/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/message/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/nonce/1

ブリッジトークンはオプティミズムで鋳造されており、アリスは現在、オプティミズムで 10 億の MoonCarpet トークンを持っています。
https://optimistic.etherscan.io/tx/0x5388ced88cf562acafff82d6798f791b0b38b90ee106df9bf91c0d86306ec302

OK、すべてが期待どおりに機能したので、アリスはトークンをブリッジし、Ethereum のエスクローに 1B の MoonCarpet トークンがあり、Optimism のアカウントに 1B の MoonCarpet トークンがあることを確認しました。しかし、すべてが正しく機能することを確認するために、彼女はトークンの半分 (500M MoonCarpet) をイーサリアムに戻します。

したがって、Optimism で 5 億トークンをバーンするトランザクションから始めます。
https://optimistic.etherscan.io/tx/0x118a57106488ad0bae1f3b920b1fd98b187752ad966f3a901fc53cff47f2097f

そのトランザクションに関する情報が Ethereum に渡されます。
https://layerzeroscan.com/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/message/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/nonce/1

そして、予想通り、5 億の MoonCarpet トークンがエスクローから Alice のアドレスに返送されます。
https://etherscan.io/tx/0x27702e07a65a9c6a7d1917222799ddb13bb3d05159d33bbeff2ca1ed414f6a18

これまでのところ、想定どおりにすべてが正常に動作しています。Alice はトークンを Ethereum から Optimism に転送できることを確認しており、MoonCarpet トークンについて心配する必要はありません。

しかし、何か問題が発生したとしましょう。たとえば、トークンの背後にあるチームが侵害され、悪意のある人物のボブがアプリの LayerZero 構成にアクセスできるようになります。

このようなアクセスにより、Bob は Oracle と Relayer をデフォルトから自分の管理下にあるものに変更できます。

これは、LayerZero のアーキテクチャに根付いた、LayerZero を使用するすべてのアプリに提供されるメカニズムであり、バックドアのようなものではなく、標準的なメカニズムであることに注意してください。

したがって、ボブはオラクルを彼の管理下にある EOA に変更します。
https://ethtx.info/mainnet/0x4dc84726da6ca7d750eef3d33710b5f63bf73cbe03746f88dd8375c3f4672f2f/

リレイヤーでも同じことを行います。
https://ethtx.info/mainnet/0xc1d7ba5032af2817e95ee943018393622bf54eb87e6ff414136f5f7c48c6d19a/

そして今、奇妙なことが起こります。Oracle と Relayer が Bob の完全な制御下にあるため、Bob は Alice のトークンを盗むことができます。Optimism (MoonCarpet トークンはアリスのウォレットに残っている) でアクションが発生しませんが、Bob は Ethereum の MoonCarpet スマート コントラクトに (LayerZero メカニズムを使用して) 他のチェーンでトークンを焼却し、MoonCarpet トークンを引き出すことができることを納得させることができます。イーサリアムで。

まず、不正な Oracle を使用して Ethereum のブロックハッシュを更新します。
https://ethtx.info/0xde2edee2cc7f070120e96c9df90d86696970befcfc221e18c6ac4168bb5b1d92/

そして今、彼はエスクローから残りのトークンを引き出すことができます:
https://ethtx.info/0xda695f374b375d5372efeca37aae4c5a17f114d5a76db1e86edebb0924bcdcc7/

結果

アリスは、なぜ、いつ何か問題が起こったのかさえ知りません。突然、Optimism での彼女の MoonCarpet トークンは、もはや Ethereum のトークンによって裏付けられていません。

スマート コントラクトはアップグレードできず、意図したとおりに機能しています。唯一の疑わしいアクティビティは Oracle と Relayer の変更ですが、これは LayerZero に組み込まれた通常のメカニズムであるため、Alice はこの変更が意図的であったかどうかさえわかりません。そしてアリスがその変化を知ったとしても、それはもう手遅れです — 攻撃者は彼女が反応する前に資金を使い果たすことができます.

そして、LayerZero はここでも役に立ちませんでした。これらはすべて、メカニズムの有効な実行であり、もはや制御できません。理論的には、アプリケーション自体が Oracle と Relayer の変更をブロックできますが、私たちが知る限り、すでにデプロイされているアプリケーションはそれを実行していません。

誰かがそれに気付くかどうかを確認するためにこの実験を行いましたが、予想どおり、誰も気づきませんでした. LayerZero で構築されたすべてのアプリケーションを効果的に監視して、セキュリティ ポリシーが変更されていないかどうかを確認し、変更があった場合にユーザーに警告することは事実上不可能です。

Oracle と Relayer がセキュリティ リスクをもたらすような変更を行ったことに追いつくことができたとしても、それが起こったときにはすでに手遅れです。新しいオラクルとリレイヤーは、チェーン間の通信を検閲するか、単に無効にすることを自由に選択できるようになったため、通常、ユーザーはそれについて何もできません。これは私たちの実験で明確に示されています。アリスがアプリケーション構成の変更に気付いたとしても、彼女はブリッジされたトークンで多くのことを行うことができません。新しいオラクルとリレイヤーは元のチェーンをリッスンしなくなるため、イーサリアムにメッセージを返します。

結論とCTA

上記のように、私たちのトークンは LayerZero を使用して構築され、そのメカニズムを意図したとおりに使用しましたが、トークンのエスクローから資金を盗むことができました。もちろん、これはアプリケーション (この場合は CarpetMoon トークン) の障害であり、LayerZero 自体ではありませんが、それは LayerZero 自体がセキュリティを保証しないことを証明しています。

LayerZero が Oracle と Relayer に関するセキュリティ モデルを説明するとき、アプリの所有者 (または秘密鍵を所有している誰か) は不合理なことは何もしないと想定しています。しかし、その仮定は、敵対的な環境では正しくありません。さらに、ユーザーはアプリケーションの所有者を信頼できるサード パーティとして信頼する必要があります。

実際には、この結果として、LayerZero を使用して構築されたアプリケーションのセキュリティについて仮定を立てることはできません。そうでないことが証明されるまで、各アプリは危険であると見なされるべきです。

実際、L2BEAT サイトにすべてのオムニチェーン トークンを含めることを計画していた PR からすべての話が始まりましたが、それらのリスクを評価する方法を理解するのに苦労しました。リスクベクトルを分析しながら、実験のアイデアを思いつきました。

L2BEAT の場合、結果として、LayerZero を使用して構築されたすべてのアプリの上にアラートを配置し、潜在的なセキュリティ リスクについて警告する必要があります。しかし、特に私たちの分野では、分離されたセキュリティは避けるべきアンチパターンであると考えているため、セキュリティ モデルについてより幅広い議論を開始したいと考えています。

LayerZero のような分離されたセキュリティ モデルがますます普及するにつれて、それらを悪用するプロジェクトがますます増え、多くの損害を引き起こし、業界全体の不確実性が高まると確信しています。