Automatically merged updates to draft EIP(s) 1702 (ethereum#2130)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

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