Account versioning

Re-define account state stored in the world state trie to have 5 items: nonce, balance, storageRoot, codeHash, and version. The newly added field version is a 256-bit scalar. We use the definition of "scalar" from Yellow Paper. Note that this is the same type as nonce and balance, and it is equivalent to a RLP variable-sized byte array with no leading zero, of maximum length 32.

When version is zero, the account is RLP-encoded with the first 4 items. When version is not zero, the account is RLP-encoded with 5 items.

Account versions can also optionally define additional account state RLP fields, whose meaning are specified through its version field. In those cases, the parsing strategy is defined in "Additional Fields in Account State RLP" section.

When fetching an account code from state, we always fetch the associated version field together. We refer to this as the code’s version below. The code of the account is always executed in the code’s version.

In particular, this means that for DELEGATECALL and CALLCODE, the version of the execution call frame is the same as delegating/receiving contract’s version.

In Ethereum, a contract has a deployment method, either by a contract creation transaction, or by another contract. If we regard this deployment method a contract’s parent, then we find them forming a family of contracts, with the root being a contract creation transaction.

We let a family of contracts to always have the same version. That is, CREATE and CREATE2 will always deploy contract that has the same version as the code’s version.

In other words, CREATE and CREATE2 will execute the init code using the current code’s version, and deploy the contract of the current code’s version. This holds even if the to-be-deployed code is empty.

A new phrase, validation is added to contract deployment (by CREATE / CREATE2 opcodes, or by contract creation transaction). When version is 0, the phrase does nothing and always succeeds. Future VM versions can define additional validation that has to be passed.

If the validation phrase fails, deployment does not proceed and return out-of-gas.

Define LATEST_VERSION in a hard fork to be the latest supported VM version. A contract creation transaction is always executed in LATEST_VERSION (which means the code’s version is LATEST_VERSION), and deploys contracts of LATEST_VERSION. Before a contract creation transaction is executed, run validation on the contract creation code. If it does not pass, return out-of-gas.

Precompiled contracts and externally-owned addresses do not have version. If a message-call transaction or CALL / CALLCODE / STATICCALL / DELEGATECALL touches a new externally-owned address or a non-existing precompiled contract address, it is always created with version field being 0.

In the future we may need to associate more information into an account, and we already have some EIP/ECIPs that define new additional fields in the account state RLP. In this section, we define the parsing strategy when additional fields are added.

This section defines how other specifications might use this account versioning. Note that currently we only define the usage template for base layer.

Account versioning is usually applied directly to a hard fork meta. Specifications in the hard fork are grouped by the virtual machine type, for example, EVM and eWASM. For each of them, we define:

If a meta specification includes specifications that provide additional account state RLP fields, we also define:

Currently nearly all full node implementations uses config parameters to decide which virtual machine version to use. Switching virtual machine version is simply an operation that changes a pointer using a different set of config parameters. As a result, this scheme has nearly zero impact to performance.

This scheme can also be helpful when we deploy on-chain WebAssembly virtual machine. In that case, WASM contracts and EVM contracts can co-exist and the execution boundary and interaction model are clearly defined as above.

In contract creation transaction, define version as 256-bit integer. After hard fork block, a contract is always signed with a version.

If version is 0, encode and sign the contract creation transaction with 9 fields, nonce, gasprice, startgas, to, value, data, v, r, s. If version is not 0, encode and sign the contract creation transaction with 10 fields, nonce, gasprice, startgas, to, value, data, v, r, s, version.

v, r, s are as defined by EIP-155. A contract creation transaction is valid if it is signed with 10 fields and with version field to 0.

The transaction would be executed with the code’s version in version supplied, and deploys contract of version. If version is not supported or validation does not pass, return out-of-gas.

Define two new opcodes VCREATE and VCREATE2 at 0xf6 and 0xf7 respectively. VCREATE takes 4 stack arguments (version, value, input offset, input size), and VCREATE2 takes 5 stack arguments (version, endowment, memory_start, memory_length, salt). Note that except the stack item version, other arguments are the same as CREATE and CREATE2.

The two new opcodes behave identically to CREATE and CREATE2, except that it deploys contracts with version specified by stack item version.

The network at all times maintains a constant list within the client of all deployable versions (which can be different from supported versions). Upon VCREATE and VCREATE2, if the specified version is not on the list of deployable versions, return out-of-gas.