イーサリアム仮想マシン (EVM) とは何ですか?なぜ重要なのでしょうか?

EVM のコア アーキテクチャ

1. EVM は、イーサリアム ネットワーク内のすべてのノード全体に複製された分散型の決定論的な実行環境として動作します。

2. 各スタック エントリが正確に 32 バイトを占有し、最大深さは 1024 エントリに制限されるスタックベースの計算モデルを実装します。

3. 3 つの異なるメモリ層が存在します。一時的な計算用の揮発性メモリ、コントラクト アカウントごとの永続ストレージ、および入力パラメータ用の不変の呼び出しデータです。

4. EVM によって実行されるすべての命令は、所定の量のガスを消費するため、厳密なリソース責任が強制され、無限ループや DoS 攻撃が防止されます。

5. プログラム カウンターは、コンパイルされたバイトコード内のバイト レベルの実行位置を追跡し、JUMP および JUMPI オペコードを介した正確なジャンプ制御と条件付き分岐を可能にします。

EVM 内の実行ワークフロー

1. Solidity ソース コードは、1 バイト オペコードのシーケンスを含む EVM 互換バイトコードにコンパイルされます。

2. トランザクションの送信時に、EVM は、アカウント残高やストレージ値を含む現在の世界状態とともにコントラクト バイトコードをロードします。

3. 各オペコードは、算術演算、メモリ書き込み、ストレージ読み取りなどの特定の状態遷移をトリガーし、副作用は正常に完了した場合にのみ記録されます。

4. 実行中にガス枯渇が発生した場合、トランザクション開始以降のすべての状態変更がアトミックに元に戻され、ブロックチェーンの一貫性が維持されます。

5. 関数呼び出しからの戻りデータはメモリ内でエンコードされ、最終状態がコミットされる前に出力バッファにコピーされます。

セキュリティと分離のプロパティ

1. EVM は厳密なサンドボックス化を強制します。ファイル システム アクセス、ネットワーク I/O、およびホスト オペレーティング システム リソースとの直接対話はありません。

2. コントラクト コードは、明示的なインターフェイス呼び出しと適切なアクセス制御ロジックがなければ、別のコントラクトのストレージを直接操作できません。

3. すべての外部呼び出し (デリゲート呼び出しを含む) はガス制限とリバート伝播ルールの対象となり、再帰呼び出しの深さとコントラクト間の影響が制限されます。

4. メモリ割り当ては線形であり、制限されています。境界外の読み取りはゼロを返しますが、割り当てられた領域を超えた書き込みはガスを大量に消費する拡張を引き起こします。

5. 元に戻すセマンティクスにより、部分的な失敗によって一貫性のない中間状態 (完全な成功または完全なロールバック) が残らないことが保証されます。

オペコードの分類と機能

1. PUSH1、POP、DUP1、SWAP1 などのスタック操作オペコードは、評価中のオペランドの位置と重複を制御します。

2. ADD、MUL、AND、XOR などの算術命令およびビット単位の命令は、256 ビット ワードで低レベルの計算を実行します。

3. ストレージ操作 SLOAD および SSTORE は、各コントラクト アドレスに関連付けられた永続的なキーと値のストアと対話します。

4. CALLER、ORIGIN、BLOCKHASH、TIMESTAMP などの環境オペコードは、コンテキストに応じたブロックチェーン メタデータを実行中のコントラクトに公開します。

5. JUMPDEST、JUMP、JUMPI などの制御フロー プリミティブにより、構造化されたプログラム フローと実行時条件に基づく動的なディスパッチが可能になります。

ガス会計と経済執行

1. ガスコストのスケジュールはオペコードごとに定義され、進化するハードウェア効率と攻撃対象領域の分析を反映するためにイーサリアム改善提案を通じて更新されます。

2. トランザクションの開始者は、ガス制限とガス価格の両方を指定し、最大計算予算とブロックに含める優先順位を決定する必要があります。

3. 未使用のガスは実行後に送信者に返金され、効率的なコーディングの実践と正確なガス推定が奨励されます。

4. ゼロ以外の値を上書きするときの SSTORE などの特定の操作では、スパムを阻止し、思慮深い状態設計を促すために非対称のコストがかかります。

5. 自己破壊機能は、ガスの一部を返金して契約を解除するメカニズムを提供し、長期的なストレージの肥大化を軽減します。

よくある質問

Q: EVM バイトコードをリバース エンジニアリングして読み取り可能な Solidity ソースにすることはできますか?元の高レベル ロジックの回復は、非可逆コンパイル、オプティマイザー変換、およびデプロイされたバイトコード内のシンボル テーブルやコメントの欠如により、一般に実行不可能です。

Q: EVM がレジスタベースではなくスタックベースのアーキテクチャを使用するのはなぜですか?スタックベースの設計により、命令エンコーディングが簡素化され、オペコード サイズのオーバーヘッドが削減され、レジスタ割り当て戦略を必要とせずに、異種ハードウェア間での確定的な実行が可能になります。

Q: 2 つのコントラクトが同じストレージ スロットに同時に書き込みを試みるとどうなりますか?ストレージ スロットは契約アドレスごとにスコープが定められています。関数呼び出しや合意されたインターフェイスを通じて明示的に仲介されない限り、コントラクト間に共有の可変状態は存在しません。

Q: EVM は整数のオーバーフローまたはアンダーフローをどのように処理しますか? Istanbul のアップグレード前は、算術演算はサイレントにラップされていました。アップグレード後の組み込みオーバーフロー チェックにより、無効な算術結果が即座に元に戻されます。