diff --git a/EIPS/eip-1702.md b/EIPS/eip-1702.md index e6096ee5..588bbc2f 100644 --- a/EIPS/eip-1702.md +++ b/EIPS/eip-1702.md @@ -60,31 +60,6 @@ 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 @@ -109,10 +84,65 @@ version. A contract creation transaction is always executed in run *validation* on the contract creation code. If it does not pass, return out-of-gas. -#### Alternative Design +### Precompiled Contract and Externally-owned Address -This provides an alternative design that allows contract to be created -in multiple versions. +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`. + +## Alternative Specification + +The above "Specification" section is commonly known as EIP-1702 +variant I, below we define an alternative design, commonly known as +EIP-1702 variant II. + +Applies all sections in "Specification" except "Contract Deployment", +and change it as below. + +### Contract Deployment + +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`. + +## Extensions + +In relation to the above "Specification" section (EIP-1702 variant I), +we have defined the base account versioning layer. The base account +versioning layer is already useful by itself and can handle most EVM +improvements. Below we define two specifications that can be deployed +separately, which improves functionality of variant I. + +### Extending Contract Creation Transaction + +The base account versioning layer only allows contract of the +newest version to be deployed via contract creation transaction. This +is a reasonable assumption for current Ethereum network, because most +of new features added to EVM are additions, and developers almost +never want to deploy contracts that are not of the newest version. In +this section, we provide an extension to allow multiple versions of +contracts to be deployed via contract creation transaction. Add an additional field `version` (256-bit integer) in contract creation transaction. So it becomes `nonce`, `gasprice`, `startgas`, @@ -122,13 +152,50 @@ 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 +### Extending `CREATE` and `CREATE2` -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`. +The base account versioning layer only allows contracts of the same +version to be deployed through `CREATE` and `CREATE2`. In this +section, we provide an extension to allow different versions of +contracts to be deployed via them, by providing two new opcodes, +`VCREATE` and `VCREATE2`. + +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. + +## Usage Template + +This section defines how other EIPs might use this account versioning +EIP. Note that currently we only define the usage template for base +layer. + +Account versioning is usually applied directly to a hard fork meta +EIP. EIPs in the hard fork are grouped by the virtual machine type, +for example, EVM and eWASM. For each of them, we define: + +* **Version**: a non-zero integer less than `2^256` that uniquely + identifies this version. Note that it does not need to be + sequential. +* **Parent version**: the base that all new features derived + from. With parent version of `0` we define the base to be legacy + VM. Note that once a version other than `0` is defined, the legacy + VM's feature set must be frozen. When defining an entirely new VM + (such as eWASM), parent version does not apply. +* **Features**: all additional features that are enabled upon this + version. ## Rationale