From 156233fab3feefaedab54898c05c3781b66744fc Mon Sep 17 00:00:00 2001 From: Wei Tang Date: Sat, 15 Feb 2020 21:53:43 +0100 Subject: [PATCH] Automatically merged updates to draft EIP(s) 1702 (#2518) 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 | 23 +++++++++-------------- 1 file changed, 9 insertions(+), 14 deletions(-) diff --git a/EIPS/eip-1702.md b/EIPS/eip-1702.md index db69cfaf..e0241d9d 100644 --- a/EIPS/eip-1702.md +++ b/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 EIP/ECIPs that define new additional +account, and we already have some EIPs that define new additional fields in the account state RLP. In this section, we define the parsing strategy when additional fields are added. @@ -143,18 +143,18 @@ purpose. When "enabling EIP-1702", those extensions should not be enabled unless the extension specification is also included. - [44-VERTXN: Account Versioning Extension for Contract Creation - Transaction](https://specs.that.world/44-vertxn/) + Transaction](https://specs.corepaper.org/44-vertxn/) - [45-VEROP: Account Versioning Extension for CREATE and - CREATE2](https://specs.that.world/45-verop/) + CREATE2](https://specs.corepaper.org/45-verop/) ## Usage Template -This section defines how other EIP/ECIPs might use this account +This section defines how other EIPs 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/ECIPs in the hard fork are grouped by the virtual machine +meta. 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 scalar less than `2^256` that uniquely @@ -168,7 +168,7 @@ type, 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/ECIP includes EIP/ECIPs that provide additional account state RLP +If a meta EIP includes EIPs that provide additional account state RLP fields, we also define: * **Account fields**: all account fields up to the end of this meta @@ -192,8 +192,8 @@ together), then this will requires extensions such as 44-VERTXN and Alternatively, account versioning can also be done through: -* **[26-VER](https://specs.that.world/26-ver/)** and - **[40-UNUSED](https://specs.that.world/40-unused/)**: This makes an +* **[26-VER](https://specs.corepaper.org/26-ver/)** and + **[40-UNUSED](https://specs.corepaper.org/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 @@ -234,12 +234,7 @@ 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). - +[43-VER](https://specs.corepaper.org/43-ver/). ## Copyright