diff --git a/EIPS/eip-1702.md b/EIPS/eip-1702.md index e6096ee500971a..588bbc2f784a2a 100644 --- a/EIPS/eip-1702.md +++ b/EIPS/eip-1702.md @@ -60,7 +60,48 @@ 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 +### 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. + +### 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`. + +## 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 @@ -84,35 +125,24 @@ Apply the following cause on contract deployment for all `CREATE`, * Use `version`'s validation procedure to validate the *whole* code (with prefix). * Deploy the contract with `version`. + +## Extensions -### Validation +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. -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. +### Extending Contract Creation Transaction -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. +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 - -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`. +### Extending `CREATE` and `CREATE2` + +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