--- eip: 1702 title: Generalized Account Versioning Scheme author: Wei Tang (@sorpaas) discussions-to: https://github.com/sorpaas/EIPs/issues/2 status: Draft type: Standards Track category: Core created: 2017-12-30 --- ## Simple Summary Introduce account versioning for smart contracts so upgrading the VM or introducing new VMs can be easier. ## Abstract This defines a method of hard forking while maintaining the exact functionality of existing account by allowing multiple versions of the virtual machines to execute in the same block. This is also useful to define future account state structures when we introduce the on-chain WebAssembly virtual machine. ## Motivation By allowing account versioning, we can execute different virtual machine for contracts created at different times. This allows breaking features to be implemented while making sure existing contracts work as expected. Note that this specification might not apply to all hard forks. We have emergency hard forks in the past due to network attacks. Whether they should maintain existing account compatibility should be evaluated in individual basis. If the attack can only be executed once against some particular contracts, then the scheme defined here might still be applicable. Otherwise, having a plain emergency hard fork might still be a good idea. ## Specification ### Account State 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 integer. 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. ### Contract Deployment 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 calling `address`. #### Alternative Design This provides an alternative design that allows `CREATE`, `CREATE2` and contract creation transaction to deploy contract whose version are different. The client maintains a mapping `V` of currently supported version prefix (for example, `\0asm`) to `version` number. All version prefixes have the invariant that given any prefix in mapping `a` and `b`, `a` is not `b`'s prefix. Version numbers in `V` cannot be zero. Apply the following cause on contract deployment for all `CREATE`, `CREATE2` and contract deployment transaction. * If the `version` of caller (determined by `I_a`) is zero, then `CREATE` and `CREATE2` will always deploy contract with version zero. * If the `version` of caller (determined by `I_a`) is not zero, do the following checks and operations, and return out-of-gas if any of it fails: * Check that the code starts with an prefix in `V`, with `version` number. * Use `version`'s validation procedure to validate the *whole* code (with prefix). * Deploy the contract with `version`. ### Validation 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. ### Contract Execution VM version used in contract execution is determined via calling `address` (`I_a` in yellow paper). ### Contract Creation Transaction Define `LATEST_VERSION` in a hard fork to be the latest supported VM version. A contract creation transaction is always executed in `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. #### Alternative Design This provides an alternative design that allows contract to be created in multiple versions. Add an additional field `version` (256-bit integer) in contract creation transaction. So it becomes `nonce`, `gasprice`, `startgas`, `to`, `value`, `data`, `v`, `r`, `s`, `version`. When signing or recovering, sign ten items, with `v`, `r`, `s` as defined by EIP-155. The transaction would be executed in `version` supplied. If `version` is not supported or *validation* does not pass, return out-of-gas. ### Precompiled Contract and Externally-owned Address 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`. ## Rationale This introduces account versioning via a new RLP item in account state. The first design above gets account versioning by making the contract *family* always have the same version. In this way, versions are only needed to be provided by contract creation transaction, and there is no restrictions on formats of code for any version. If we want to support multiple newest VMs (for example, EVM and WebAssembly running together), then this requires alternative design in contract creation transaction section The second design above requires new versions of VMs follow a formatting -- that it always has a prefix. In this way, the version can be derived from the prefix, thus allowing a contract *family* to have multiple versions. It also makes it so that we can pin contract creation transaction using only one VM version, and it can deploy other VM versions. Alternatively, account versioning can also be done through: * **EIP-1707** and **EIP-1712**: This makes an account's versioning soly dependent on its code header prefix. If with only EIP-1707, it is not possible to certify any code is valid, because current VM allows treating code as data. This can be fixed by EIP-1712, but the drawback is that it's potentially backward incompatible. * **EIP-1891**: Instead of writing version field into account RLP state, we write it in a separate contract. This can accomplish the same thing as this EIP and potentially reduces code complexity, but the drawback is that every code execution will require an additional trie traversal, which impacts performance. ## Backwards Compatibility Account versioning is fully backwards compatible, and it does not change how current contracts are executed. ## Discussions ### Performance Currently nearly all full node implementations uses config parameters to decide which virtual machine version to use. Switching vitual 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. ### WebAssembly 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. ## Test Cases and Implementations To be added.