Opinion: EVM without Versioning

Editor's Note: This article comes fromEthereum enthusiasts (ID: Ethfans)Editor's Note: This article comes from

Ethereum enthusiasts (ID: Ethfans)

, author: Wei Tang, translation: A Jian, reprinted by Odaily with authorization.

In this article, I explore this question and document the technical description and design philosophy that has evolved from it.

Target

secondary title

The Web is versionless and has been for decades. So I assume here that we want to make an EVM that also has no version difference.

We also want to ensure that this virtual machine has good backward compatibility (this is a required property). That is to say, at least it can be well compatible with our existing contracts (in the current EVM, even a change in the gas consumption of a single opcode may break the existing contract), and new functions can be easily added.

secondary title

invalid opcode

• The simplest and possibly most important change to design a persistent EVM is to add a verification process for contract deployment. Not all byte sequences are valid EVM codes, and any invalid opcodes should not be deployed to the chain, because in the future, these codes may be assigned a new opcode with a different function.

• The technical details of this inspection were first documented in EIP-1712. Briefly, before executing the state transition function created by the contract (or adding contract code to the state), the following checks are performed:

• Traversing the bytecode of the code

• If the code is a PUSH(n) opcode, skip the next n bytes

Otherwise, an error is caught (trap)

The above check is somewhat similar to the jump destination check. Note that for exceptions, we are using "trap" here, which we will explain in detail below.

secondary title

Feature Probe

• If the EVM is to smooth out version differences, EVM-based code execution should have the ability to investigate whether the underlying environment supports a particular feature. Given the role played by the EVM, we always hope that the functionality of an already defined opcode can remain unchanged, and new opcodes can be introduced to add functionality. And some contracts may have been deployed before introducing certain functions. These contracts can schedule a fallback subroutine to run when a feature is not supported by the EVM, and start using the new feature as soon as the hard fork activates. The functional investigation component is like the jumper that will be used here.

• This opcode takes a stack argument. It checks to see if the parameter is between 0 and 2^8, and catches the error if not

If the argument (interpreted as an opcode) is not supported, push 0x0 back onto the stack; otherwise push 0x1

Exceptions and Trap

During the operation of EVM, there may be many factors that may cause execution failure (fail). A single transaction may fail due to gas exhaustion; each layer in the call stack may fail individually, and its errors must be explicitly handled by the parent call frame. These features give us a certain degree of flexibility, but they are not necessarily a good thing for contracts to run on the blockchain. Here, we want to redefine that any exception issued by EVM itself can have trap behavior as a substitute for fail. That is to say, there can be traps during all executions of the calling framework, when any gas is consumed, or even when the current state function is rolled back and changed. Contracts are then encouraged to use return values ​​when they want to communicate non-fatal errors to their parent caller.

secondary title