意見: バージョニングのない EVM
編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: Ethfans)編集者注: この記事は以下から引用しました
イーサリアム愛好家 (ID: Ethfans)
、著者：Wei Tang、翻訳：A Jian、許可を得てOdailyによって転載されました。
EVM を再設計し、下位互換性を向上させ、機能アップグレードをより容易にし、既存の歴史的な重荷を完全に無視する機会があったとしたら、どうすればよいでしょうか?
この記事では、この疑問を検討し、そこから発展した技術的な説明と設計哲学を文書化します。
副題
Web にはバージョンがなく、何十年も続いています。したがって、ここでは、バージョンの違いがない EVM を作成したいと仮定します。
また、この仮想マシンに良好な下位互換性があることを確認したいと考えています (これは必須のプロパティです)。つまり、少なくとも既存の契約との互換性が高く (現在の EVM では、単一のオペコードのガス消費量の変更でさえ既存の契約が破られる可能性があります)、新しい機能を簡単に追加できます。
副題
無効なオペコード
永続的 EVM を設計するための最も単純で、おそらく最も重要な変更は、コントラクト展開の検証プロセスを追加することです。すべてのバイト シーケンスが有効な EVM コードであるわけではありません。将来、これらのコードには異なる機能を持つ新しいオペコードが割り当てられる可能性があるため、無効なオペコードはチェーンにデプロイされるべきではありません。
この検査の技術的な詳細は、EIP-1712 に初めて文書化されました。簡単に言うと、コントラクトによって作成された状態遷移関数を実行する (またはコントラクト コードを状態に追加する) 前に、次のチェックが実行されます。
コードのバイトコードを走査する
コードが PUSH(n) オペコードの場合、次の n バイトをスキップします
それ以外の場合は、エラーが捕捉されます (トラップ)
上記のチェックは、ジャンプ先のチェックと似ています。例外として、ここでは「トラップ」を使用していることに注意してください。これについては後で詳しく説明します。
副題
特徴プローブ
EVM がバージョンの違いを平滑化する場合、EVM ベースのコード実行には、基礎となる環境が特定の機能をサポートしているかどうかを調査する機能が必要です。 EVM が果たす役割を考えると、私たちは、すでに定義されているオペコードの機能が変更されず、新しいオペコードが導入されて機能が追加されることを常に望んでいます。また、一部の契約は、特定の機能を導入する前に展開されている場合があります。これらのコントラクトでは、機能が EVM でサポートされていない場合に実行するフォールバック サブルーチンをスケジュールし、ハード フォークがアクティブになるとすぐに新しい機能の使用を開始できます。機能調査コンポーネントは、ここで使用するジャンパーのようなものです。
このオペコードはスタック引数を受け取ります。パラメーターが 0 から 2^8 の範囲内であるかどうかを確認し、そうでない場合はエラーを捕捉します。
引数 (オペコードとして解釈される) がサポートされていない場合は、0x0 をスタックにプッシュし、それ以外の場合は 0x1 をプッシュします。
例外とトラップ
EVM の動作中には、さまざまな要因によって実行失敗 (フェイル) が発生する可能性があります。単一のトランザクションはガス枯渇により失敗する可能性があり、呼び出しスタックの各層は個別に失敗する可能性があり、そのエラーは親呼び出しフレームによって明示的に処理される必要があります。これらの機能により、ある程度の柔軟性が得られますが、ブロックチェーン上でコントラクトを実行するのは必ずしも良いことではありません。ここで、EVM 自体によって発行される例外は、失敗の代わりにトラップ動作を行うことができることを再定義したいと思います。つまり、呼び出しフレームワークのすべての実行中、ガスが消費されたとき、または現在の状態関数がロールバックされて変更されたときでも、トラップが発生する可能性があります。コントラクトは、致命的ではないエラーを親の呼び出し元に伝えたい場合に戻り値を使用することが推奨されます。
副題
ガス消費量
