上位 10 の TVL チェーンのうち 9 つ以上が EVM スマート コントラクトをサポートしています。
元のタイトル:「セキュリティ リスクのためにフォークされた EVM を使用する方法」
作詞：イーサン・ポシアスク、エリック・メン、ナディール・アクタル、ガブリエラ・メレンデス・クアン、トム・ライアン
編纂者: ケイティ・クー
ERC-20 やその他のスマート コントラクト ベースの資産を取引する顧客のセキュリティと保管保証を強化するために、Coinbase ブロックチェーン セキュリティ チームは、これらの資産の動作を定義するプログラム層であるイーサリアム仮想マシン (EVM) を調査しました。独自のネットワークのEVMを変更するプロジェクトを評価する際、CoinbaseのブロックチェーンセキュリティチームはEVMの主要な変更をレビューし、変更されたEVMが元のEVM実装と同じセキュリティと保管保証を提供できるかどうかを判断します。
2023 年 5 月の時点で、イーサリアム仮想マシン (EVM) は、最も人気のあるスマート コントラクト実行プラットフォームの「ビッグ ブラザー」の称号を獲得しました。 DefiLlama によると、Total Value Locked (TVL) の上位 10 チェーンのうち 9 チェーンが EVM スマート コントラクトをサポートしています。したがって、EVM を深く理解することは、ブロックチェーン エコシステム全体でスマート コントラクトをサポートするために不可欠です。
EVM は、イーサリアム ネットワーク上でスマート コントラクトを分散実行するための仮想マシンです。 EVM 互換のブロックチェーンの多くは、go-ethereum (Golang) や besu (Java) などのさまざまな言語で人気のある Ethereum 実装クライアントの標準実装をプロトコル ソフトウェアで直接利用しています。
とはいえ、EVM のフォークと変更は、主要なプロトコル内であっても、ブロックチェーン エコシステムでは実際には非常に一般的です。たとえば、Coinbase のベース L2 ブロックチェーンを「強化」する Optimism Bedrock Stack は、op-geth と呼ばれる go-ethereum 実行クライアントのフォークを使用しており、人気のある ethereum 実行クライアントと同じ EVM を実行します。ただし、これは、Ethereum 上の EVM が Optimism 上の EVM とまったく同じように動作することを意味するものではありません。op-geth EVM は、場合によってはわずかに異なる動作をします (つまり、ランダムな値を返す難易度はシーケンサーによって決定されます)。
これは恐ろしいことのように聞こえますが、一般に EVM の導入には有益です。標準の EVM 実装は基本イーサリアム プロトコル向けに高度に最適化されていますが、フォークされた EVM は多くの場合、独自の新しいプロトコル向けにそれを拡張します。その結果、一部の EVM 互換チェーンではコントラクトがイーサリアムとは異なる方法で実行される可能性があり、EVM スマート コントラクトの動作のセキュリティ前提もプロトコルごとに大きく異なる可能性があります。
この目的を達成するために、Coinbase は、いくつかのフォークされた EVM 実装のセキュリティへの影響を評価するための Web3 セキュリティ フレームワークを開発しました。私たちはこれを Coinbase のフォークされた EVM フレームワークと呼んでいます。これについては以下で詳しく説明します。
このフォークされた EVM セキュリティ フレームワークにより、Coinbase は効果的に次のことを行うことができます。
Ethereum 仮想マシンにセキュリティ リスクがどのように存在するかを理解するには、まず標準の EVM 実装が提供する保証を知る必要があります。 Ethereum 実装仕様に記載されているように、標準 EVM を Ethereum バリデータ実行クライアントによって一貫して使用される EVM として定義します。これまでのところ最もよく使用されているクライアントは go ethereum (つまり geth) です。
セキュリティを 2 つのセキュリティ基準に要約します。これらは、フォークされた EVM 実装が Coinbase サポートの対象となるための最小要件を表します。
当社のフォークされた EVM フレームワークは、全体的なセキュリティ基準 (つまり、契約の不変性と安全な実行環境) への準拠を評価する際に、次の監査要件に焦点を当てています。次のリスク コンポーネントはフォーク EVM 監査の完全な範囲ではないことに注意してください。
EVM オペコードの定義とエンコーディングを変更すると、コントラクトの実行方法に大きな違いが生じる可能性があります。たとえば、フォークされた EVM 実装 (EVM') が算術 ADD オペコードを変更して、2 つの値 (x1 - x2) を減算するロジック (x1 + x2) を定義するとします。
結果として、逸脱した EVM は、標準 EVM との実行において等しくなく、互換性がありません。オペコードの変更の結果は、算術オペコードでの整数のオーバーフローやアンダーフローの防止などの有益な動作になる場合もあれば、ローカル アセットの無限のミントを引き起こす自己破壊動作などのより危険な動作になる場合もあります。
EVM は、アクセスしにくい EVM バイトコードを使用する代わりに、Golang などのより便利でパフォーマンスの高い言語を使用して、プリコンパイルされたコントラクトを使用して複雑な関数 (暗号化関数など) を定義します。
基本的に、これらは、ノード ソフトウェアで表される所定のチェーン アドレスを通じてアクセスされるプログラムされた機能です。イーサリアム イエロー ペーパー (2023 年 5 月現在) では 9 つのプリコンパイラーが定義されており、これら 9 つのプリコンパイラーに対する変更や新しいプリコンパイラーの導入は監査する必要があります。
別の具体的な例、BNB スマート チェーンの脆弱性を見てみましょう。 BNB スマート チェーンは、ノードを実行するために go-ethereum の逸脱した実装を使用します。この目的を達成するために、2 つの新しいプリコンパイルされたコントラクト (tmHeaderValidate、iavlMerkleProofValidate) が導入され、サードパーティ ソフトウェア (つまり、Cosmos SDK) を利用してライト クライアント ブロック検証とマークル証明検証を実行します。問題は、Cosmos SDK ソフトウェアの IAWL ツリー表現に実装上のバグがあり、暗号的に無効な証明が検証に合格することを可能にしてしまうことです。言い換えれば、誰でも何もないところからお金を生み出すことができるのです。攻撃者は、iavlMerkleProofValidate プリコンパイラーにネストされたこの実装の欠陥を悪用して、Binance クロスチェーン ブリッジから数億ドルを吸い上げることができました。
この悪用例は、プリコンパイラのセキュリティの必要性と、逸脱した EVM 実装のために新しいプリコンパイルされたコントラクトを導入する潜在的なリスクを示すことを目的としています。
追加のプリコンパイラを導入すると、致命的なリスクが生じる可能性があります。
コンパイラと EVM を完全に別個のエンティティとして扱っているにもかかわらず、Solidity コンパイラは、Solidity を通過する最初の 3 つのプリコンパイル済みコントラクト (ecrecover、sha256、および &ripemd) の動作について厳密な仮定を行っていることに注意する価値があります。ネイティブ言語のキーワード関数言語での表現。 Solidity コンパイラーは実際に舞台裏でこれらのキーワードをバイトコードに処理し、コントラクト間の静的呼び出しを実行します。以下の図は、コントラクト間の通信方法をさらに示しています。
標準プリコンパイラを変更することによって導入されるセキュリティ リスクには次のものがあります。
EVM の基本コンポーネントを変更することによってもたらされる主なリスクには次のものがあります。
私たちの目標は、ブロックチェーン技術に基づいたオープンな金融システムを構築することであり、この目的のために、さまざまなEVM実装の開発を奨励しています。ただし、EVM 準拠のブロックチェーンが Coinbase で完全にサポートされるためには、標準の EVM 実装の基本要件を満たしている必要があります。このペーパーは、EVM からの逸脱に伴うリスクに対する意識を高め、資産発行者が EVM から逸脱する場合に安全なコンポーネントの開発を優先することを奨励し、Web3 エコシステム全体のセキュリティ意識を高めることを目指しています。
10k 人気度
44k 人気度
17k 人気度
29612k 人気度
10716k 人気度
11184k 人気度
11560k 人気度
9060k 人気度
13109k 人気度
「フォークされた EVM」のセキュリティ リスクを評価するにはどうすればよいですか?
上位 10 の TVL チェーンのうち 9 つ以上が EVM スマート コントラクトをサポートしています。
元のタイトル:「セキュリティ リスクのためにフォークされた EVM を使用する方法」
作詞：イーサン・ポシアスク、エリック・メン、ナディール・アクタル、ガブリエラ・メレンデス・クアン、トム・ライアン
編纂者: ケイティ・クー
ERC-20 やその他のスマート コントラクト ベースの資産を取引する顧客のセキュリティと保管保証を強化するために、Coinbase ブロックチェーン セキュリティ チームは、これらの資産の動作を定義するプログラム層であるイーサリアム仮想マシン (EVM) を調査しました。独自のネットワークのEVMを変更するプロジェクトを評価する際、CoinbaseのブロックチェーンセキュリティチームはEVMの主要な変更をレビューし、変更されたEVMが元のEVM実装と同じセキュリティと保管保証を提供できるかどうかを判断します。
フォーク EVM ステータス
2023 年 5 月の時点で、イーサリアム仮想マシン (EVM) は、最も人気のあるスマート コントラクト実行プラットフォームの「ビッグ ブラザー」の称号を獲得しました。 DefiLlama によると、Total Value Locked (TVL) の上位 10 チェーンのうち 9 チェーンが EVM スマート コントラクトをサポートしています。したがって、EVM を深く理解することは、ブロックチェーン エコシステム全体でスマート コントラクトをサポートするために不可欠です。
EVM は、イーサリアム ネットワーク上でスマート コントラクトを分散実行するための仮想マシンです。 EVM 互換のブロックチェーンの多くは、go-ethereum (Golang) や besu (Java) などのさまざまな言語で人気のある Ethereum 実装クライアントの標準実装をプロトコル ソフトウェアで直接利用しています。
とはいえ、EVM のフォークと変更は、主要なプロトコル内であっても、ブロックチェーン エコシステムでは実際には非常に一般的です。たとえば、Coinbase のベース L2 ブロックチェーンを「強化」する Optimism Bedrock Stack は、op-geth と呼ばれる go-ethereum 実行クライアントのフォークを使用しており、人気のある ethereum 実行クライアントと同じ EVM を実行します。ただし、これは、Ethereum 上の EVM が Optimism 上の EVM とまったく同じように動作することを意味するものではありません。op-geth EVM は、場合によってはわずかに異なる動作をします (つまり、ランダムな値を返す難易度はシーケンサーによって決定されます)。
これは恐ろしいことのように聞こえますが、一般に EVM の導入には有益です。標準の EVM 実装は基本イーサリアム プロトコル向けに高度に最適化されていますが、フォークされた EVM は多くの場合、独自の新しいプロトコル向けにそれを拡張します。その結果、一部の EVM 互換チェーンではコントラクトがイーサリアムとは異なる方法で実行される可能性があり、EVM スマート コントラクトの動作のセキュリティ前提もプロトコルごとに大きく異なる可能性があります。
EVM セキュリティ フレームワークをフォークする
この目的を達成するために、Coinbase は、いくつかのフォークされた EVM 実装のセキュリティへの影響を評価するための Web3 セキュリティ フレームワークを開発しました。私たちはこれを Coinbase のフォークされた EVM フレームワークと呼んでいます。これについては以下で詳しく説明します。
このフォークされた EVM セキュリティ フレームワークにより、Coinbase は効果的に次のことを行うことができます。
EVM互換ブロックチェーンのセキュリティ標準
Ethereum 仮想マシンにセキュリティ リスクがどのように存在するかを理解するには、まず標準の EVM 実装が提供する保証を知る必要があります。 Ethereum 実装仕様に記載されているように、標準 EVM を Ethereum バリデータ実行クライアントによって一貫して使用される EVM として定義します。これまでのところ最もよく使用されているクライアントは go ethereum (つまり geth) です。
セキュリティを 2 つのセキュリティ基準に要約します。これらは、フォークされた EVM 実装が Coinbase サポートの対象となるための最小要件を表します。
EVM 実装のセキュリティ リスクをどのように監査すればよいでしょうか?
当社のフォークされた EVM フレームワークは、全体的なセキュリティ基準 (つまり、契約の不変性と安全な実行環境) への準拠を評価する際に、次の監査要件に焦点を当てています。次のリスク コンポーネントはフォーク EVM 監査の完全な範囲ではないことに注意してください。
EVM オペコードの定義とエンコーディングを変更すると、コントラクトの実行方法に大きな違いが生じる可能性があります。たとえば、フォークされた EVM 実装 (EVM') が算術 ADD オペコードを変更して、2 つの値 (x1 - x2) を減算するロジック (x1 + x2) を定義するとします。
結果として、逸脱した EVM は、標準 EVM との実行において等しくなく、互換性がありません。オペコードの変更の結果は、算術オペコードでの整数のオーバーフローやアンダーフローの防止などの有益な動作になる場合もあれば、ローカル アセットの無限のミントを引き起こす自己破壊動作などのより危険な動作になる場合もあります。
EVM は、アクセスしにくい EVM バイトコードを使用する代わりに、Golang などのより便利でパフォーマンスの高い言語を使用して、プリコンパイルされたコントラクトを使用して複雑な関数 (暗号化関数など) を定義します。
基本的に、これらは、ノード ソフトウェアで表される所定のチェーン アドレスを通じてアクセスされるプログラムされた機能です。イーサリアム イエロー ペーパー (2023 年 5 月現在) では 9 つのプリコンパイラーが定義されており、これら 9 つのプリコンパイラーに対する変更や新しいプリコンパイラーの導入は監査する必要があります。
別の具体的な例、BNB スマート チェーンの脆弱性を見てみましょう。 BNB スマート チェーンは、ノードを実行するために go-ethereum の逸脱した実装を使用します。この目的を達成するために、2 つの新しいプリコンパイルされたコントラクト (tmHeaderValidate、iavlMerkleProofValidate) が導入され、サードパーティ ソフトウェア (つまり、Cosmos SDK) を利用してライト クライアント ブロック検証とマークル証明検証を実行します。問題は、Cosmos SDK ソフトウェアの IAWL ツリー表現に実装上のバグがあり、暗号的に無効な証明が検証に合格することを可能にしてしまうことです。言い換えれば、誰でも何もないところからお金を生み出すことができるのです。攻撃者は、iavlMerkleProofValidate プリコンパイラーにネストされたこの実装の欠陥を悪用して、Binance クロスチェーン ブリッジから数億ドルを吸い上げることができました。
この悪用例は、プリコンパイラのセキュリティの必要性と、逸脱した EVM 実装のために新しいプリコンパイルされたコントラクトを導入する潜在的なリスクを示すことを目的としています。
追加のプリコンパイラを導入すると、致命的なリスクが生じる可能性があります。
コンパイラと EVM を完全に別個のエンティティとして扱っているにもかかわらず、Solidity コンパイラは、Solidity を通過する最初の 3 つのプリコンパイル済みコントラクト (ecrecover、sha256、および &ripemd) の動作について厳密な仮定を行っていることに注意する価値があります。ネイティブ言語のキーワード関数言語での表現。 Solidity コンパイラーは実際に舞台裏でこれらのキーワードをバイトコードに処理し、コントラクト間の静的呼び出しを実行します。以下の図は、コントラクト間の通信方法をさらに示しています。
標準プリコンパイラを変更することによって導入されるセキュリティ リスクには次のものがあります。
EVM の基本コンポーネントを変更することによってもたらされる主なリスクには次のものがあります。
EVM セキュリティに注意を払う必要があるのはなぜですか?
私たちの目標は、ブロックチェーン技術に基づいたオープンな金融システムを構築することであり、この目的のために、さまざまなEVM実装の開発を奨励しています。ただし、EVM 準拠のブロックチェーンが Coinbase で完全にサポートされるためには、標準の EVM 実装の基本要件を満たしている必要があります。このペーパーは、EVM からの逸脱に伴うリスクに対する意識を高め、資産発行者が EVM から逸脱する場合に安全なコンポーネントの開発を優先することを奨励し、Web3 エコシステム全体のセキュリティ意識を高めることを目指しています。