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

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

@@ -116,7 +116,7 @@ with `version` field being `0`.
 ### Additional Fields in Account State RLP
 
 In the future we may need to associate more information into an
-account, and we already have some EIPs that define new additional
+account, and we already have some EIP/ECIPs that define new additional
 fields in the account state RLP. In this section, we define the
 parsing strategy when additional fields are added.
 
@@ -140,22 +140,22 @@ 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.
+enabled unless the extension specification 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)
+- [44-VERTXN: Account Versioning Extension for Contract Creation
+  Transaction](https://specs.that.world/44-vertxn/)
+- [45-VEROP: Account Versioning Extension for CREATE and
+  CREATE2](https://specs.that.world/45-verop/)
 
 ## 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.
+This section defines how other EIP/ECIPs might use this account
+versioning specification. 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:
+Account versioning is usually applied directly to a hard fork
+meta. EIP/ECIPs 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 scalar less than `2^256` that uniquely
   identifies this version. Note that it does not need to be
@@ -168,7 +168,7 @@ for example, EVM and eWASM. For each of them, we define:
 * **Features**: all additional features that are enabled upon this
   version.
 
-If a meta EIP includes EIPs that provide additional account state RLP
+If a meta EIP/ECIP includes EIP/ECIPs that provide additional account state RLP
 fields, we also define:
 
 * **Account fields**: all account fields up to the end of this meta
@@ -187,16 +187,18 @@ state. The design above gets account versioning by making the contract
 needed to be provided by contract creation transaction, and there is
 no restrictions on formats of code for any version. If we want to
 support multiple newest VMs (for example, EVM and WebAssembly running
-together), then this will requires extensions such as EIP-2138 and
-EIP-2139.
+together), then this will requires extensions such as 44-VERTXN and
+45-VEROP.
 
 Alternatively, account versioning can also be done through:
 
-* **EIP-1707** and **EIP-1712**: This makes an account's versioning
-  soly dependent on its code header prefix. If with only EIP-1707, it
-  is not possible to certify any code is valid, because current VM
-  allows treating code as data. This can be fixed by EIP-1712, but the
-  drawback is that it's potentially backward incompatible.
+* **[26-VER](https://specs.that.world/26-ver/)** and
+  **[40-UNUSED](https://specs.that.world/40-unused/)**: This makes an
+  account's versioning soly dependent on its code header prefix. If
+  with only 26-VER, it is not possible to certify any code is valid,
+  because current VM allows treating code as data. This can be fixed
+  by 40-UNUSED, but the drawback is that it's potentially backward
+  incompatible.
 * **EIP-1891**: Instead of writing version field into account RLP
   state, we write it in a separate contract. This can accomplish the
   same thing as this EIP and potentially reduces code complexity, but
@@ -229,6 +231,16 @@ defined as above.
 
 To be added.
 
+## References
+
+The source of this specification can be found at 
+[43-VER](https://specs.that.world/43-ver/). This specification is 
+also realized in:
+
+* Ethereum Classic Improvement Proposals as
+  [ECIP-1040](https://ecips.ethereumclassic.org/ECIPs/ecip-1040).
+
+
 ## Copyright
 
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).