「フォークされた EVM」のセキュリティリスクを評価するにはどうすればよいですか?

Odaily资深作者

2023-05-30 09:35

この記事は約2306文字で、全文を読むには約4分かかります

上位 10 の TVL チェーンのうち 9 つが EVM スマートコントラクトをサポートしています。

この記事の由来は Coinbaseこの記事の由来は

ERC-20 やその他のスマートコントラクトベースの資産を取引する顧客のセキュリティと保管保証を強化するために、Coinbase ブロックチェーンセキュリティチームは、これらの資産の動作を定義するプログラム層であるイーサリアム仮想マシン (EVM) を調査しました。独自のネットワークのEVMを変更するプロジェクトを評価する際、CoinbaseのブロックチェーンセキュリティチームはEVMの主要な変更をレビューし、変更されたEVMが元のEVM実装と同じセキュリティとカストディの保証を提供できるかどうかを判断します。

副題

フォークされた EVM ステータス

2023 年 5 月の時点で、イーサリアム仮想マシン (EVM) は、最も人気のあるスマートコントラクト実行プラットフォームの「ビッグブラザー」の称号を主張しています。 DefiLlama によると、トータルバリューロック (TVL) の上位 10 チェーンのうち 9 チェーンが EVM スマートコントラクトをサポートしています。したがって、ブロックチェーンエコシステム全体でスマートコントラクトをサポートするには、EVM を深く理解することが重要です。

EVM は、イーサリアムネットワーク上でスマートコントラクトを分散実行するための仮想マシンです。多くの EVM 互換ブロックチェーンは、go-ethereum (Golang) や besu (Java) などのさまざまな言語での一般的な Ethereum 実行クライアントの標準実装をプロトコルソフトウェアで直接利用しています。つまり、EVM のフォークと変更は、主要なプロトコル内であっても、ブロックチェーンエコシステムでは実際に非常に一般的です。

。たとえば、Coinbase のベース L2 ブロックチェーンを「強化」する Optimism Bedrock Stack は、人気のあるイーサリアム実行クライアントと同じ EVM を実行する、op-geth と呼ばれる go-ethereum 実行クライアントのフォークされたバージョンを使用します。ただし、これは、Ethereum 上の EVM が Optimism 上の EVM とまったく同じように動作することを意味するものではありません。op-geth EVM は、場合によってはわずかに異なる動作をします (つまり、ランダムな値を返す難易度はシーケンサーによって決定されます)。一部の EVM 互換チェーンでは、コントラクトはイーサリアムとは異なる方法で実行される場合があり、EVM スマートコントラクトの動作に対するセキュリティの前提条件もプロトコルごとに大きく異なる場合があります。

副題

EVMセキュリティフレームワークのフォーク

この目的を達成するために、Coinbase は、一部のフォークされた EVM 実装におけるセキュリティへの影響を評価するための Web3 セキュリティフレームワークを開発しました。私たちはこれを Coinbase のフォークされた EVM フレームワークと呼んでいます。これについては以下で詳しく説明します。

このフォークされた EVM セキュリティフレームワークにより、Coinbase は効果的に次のことを行うことができます。
イーサリアムトークンフレームワークのセキュリティ前提の無効性を理解することで、新しい EVM 互換ブロックチェーンを安全に有効にして、分散型取引所で ERC-20/ERC-721 トークンをサポートできるようになります。
Coinbase の Base L2 ブロックチェーン上で EVM スマートコントラクトの安全な使用と実行を確保します。

副題

EVM互換ブロックチェーンのセキュリティ標準

セキュリティを 2 つのセキュリティ基準に要約します。これらは、フォークされた EVM 実装が Coinbase サポートの対象となるための最小要件を表します。

副題

EVM実装のセキュリティリスクをどのように監査すればよいでしょうか?

当社のフォークされた EVM フレームワークは、全体的なセキュリティ基準 (つまり、契約の不変性と安全な実行環境) への準拠を評価する際に、次の監査要件に焦点を当てています。次のリスクコンポーネントはフォーク EVM 監査の全範囲ではないことに注意してください。

EVM オペコードの定義とエンコーディングを変更すると、コントラクトの実行方法に大きな違いが生じる可能性があります。たとえば、フォークされた EVM 実装 (EVM') が算術 ADD オペコードを変更して、2 つの値 (x 1 - x 2 ) を減算するロジック (x 1 + x 2 ) を定義するとします。

結果として、逸脱した EVM は標準 EVM と等しくなく、実行時に互換性がありません。オペコードの変更の結果は、算術オペコードでの整数のオーバーフローやアンダーフローの防止などの有益な動作になる場合もあれば、ローカルアセットの無限のミントを引き起こす自己破壊動作などのより危険な動作になる場合もあります。

EVM は、アクセスしにくい EVM バイトコードを使用するのではなく、Golang などのより便利でパフォーマンスの高い言語を使用して、プリコンパイルされたコントラクトを使用して複雑な機能 (暗号化機能など) を定義します。

基本的に、これらは、ノードソフトウェアで表される所定のチェーンアドレスを通じてアクセスされるプログラムされた機能です。イーサリアムイエローペーパーでは 9 つのプリコンパイラーが定義されており (2023 年 5 月現在)、これら 9 つのプリコンパイラーに対する変更や新しいプリコンパイラーの導入は監査の対象となります。

別の具体的な例、BNB スマートチェーンの脆弱性を見てみましょう。 BNB スマートチェーンは、ノードを実行するために go-ethereum の逸脱した実装を使用します。この目的を達成するために、2 つの新しいプリコンパイルされたコントラクト (tmHeaderValidate、iavlMerkleProofValidate) が導入され、サードパーティソフトウェア (つまり、Cosmos SDK) を利用してライトクライアントブロック検証とマークル証明検証を実行します。問題は、Cosmos SDK ソフトウェアの IAWL ツリー表現に実装上のバグがあり、暗号的に無効な証明が検証に合格することを可能にしてしまうことです。言い換えれば、誰でも何もないところからお金を生み出すことができるのです。攻撃者は、iavlMerkleProofValidate プリコンパイラーにネストされたこの実装の欠陥を悪用して、Binance クロスチェーンブリッジから数億ドルを吸い上げることができました。

この悪用例は、プリコンパイラのセキュリティの必要性と、逸脱した EVM 実装のために新しいプリコンパイルされたコントラクトを導入する潜在的なリスクを示すことを目的としています。

追加のプリコンパイラを導入すると、致命的なリスクが生じる可能性があります。
当事者が展開された契約の状態を一方的に変更できるようにする。
これには、ストレージのすべての変更 (挿入、更新、削除) が含まれます。
信頼できない、未検証または未監査のサードパーティ依存関係を使用します。

不定ノード内の値へのアクセスを提供します。

コンパイラと EVM を完全に別個のエンティティとして扱っているにもかかわらず、Solidity コンパイラは、ネイティブ言語のキーワード関数に渡される最初の 3 つのプリコンパイル済みコントラクト (ecrecover、sha 256、および &ripemd) の動作について厳密な仮定を行っていることに注意する価値があります。 Solidity言語での表現。 Solidity コンパイラーは実際に舞台裏でこれらのキーワードをバイトコードに処理し、コントラクト間の静的呼び出しを実行します。以下の図は、コントラクト間の通信方法をさらに示しています。