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

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

@@ -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