diff --git a/EIPS/eip-1702.md b/EIPS/eip-1702.md index 9601c2986831fe..604fb25133bad7 100644 --- a/EIPS/eip-1702.md +++ b/EIPS/eip-1702.md @@ -98,100 +98,23 @@ Precompiled contracts and externally-owned addresses do not have `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. - -For contract deployment transaction, run the following additional -steps. - -* 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). -* Execute the code with the *code's version* being `version`. -* Apply the deployment routine defined as below. - -Apply the following cause on contract deployment for all `CREATE`, -`CREATE2` and contract deployment transaction's deployment phrase. - -* If the *code's version* is zero, then `CREATE` and `CREATE2` will - always deploy contract with version zero. -* If the *code's version* 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`, -`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 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. - -### 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. +In relation to the above "Specification" section, 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 base layer account versioning. + +Note that this section is provided only for documentation +purpose. When "enabling EIP-1702", those extensions should not be +enabled unless the extension EIP is also included. + +- [EIP-2138: Account Versioning Extension for Contract Creation + Transaction](https://github.com/ethereum/EIPs/pull/2138) +- [EIP-2139: Account Versioning Extension for CREATE and + CREATE2](https://github.com/ethereum/EIPs/pull/2139) ## Usage Template