From 02af592e96d9b712f51069ba0b4f9c1e70d394ae Mon Sep 17 00:00:00 2001 From: Wei Tang Date: Thu, 7 Nov 2019 22:12:29 +0100 Subject: [PATCH] Automatically merged updates to draft EIP(s) 1702 (#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 | 52 +++++++++++++++++++++++++++++------------------- 1 file changed, 32 insertions(+), 20 deletions(-) diff --git a/EIPS/eip-1702.md b/EIPS/eip-1702.md index f2b7501b12d386..db69cfaf15e3f9 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 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/).