From 4667eb602d0792c885166910e463e2d19890d578 Mon Sep 17 00:00:00 2001 From: Wei Tang Date: Thu, 27 Jun 2019 22:09:14 +0200 Subject: [PATCH] Automatically merged updates to draft EIP(s) 1702 (#2152) 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 | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/EIPS/eip-1702.md b/EIPS/eip-1702.md index 939938b6f2b3f..5fbdd93fe7335 100644 --- a/EIPS/eip-1702.md +++ b/EIPS/eip-1702.md @@ -80,6 +80,11 @@ 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 *code's version*. +In other words, `CREATE` and `CREATE2` will execute the init code +using the current *code's version*, and deploy the contract of the +current *code's version*. This holds even if the to-be-deployed code +is empty. + ### Validation A new phrase, *validation* is added to contract deployment (by @@ -177,20 +182,13 @@ fields, we also define: ## Rationale This introduces account versioning via a new RLP item in account -state. The first design above gets account versioning by making the -contract *family* always have the same version. In this way, versions -are only 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 requires alternative design in contract -creation transaction section - -The second design above requires new versions of VMs follow a -formatting -- that it always has a prefix. In this way, the version -can be derived from the prefix, thus allowing a contract *family* to -have multiple versions. It also makes it so that we can pin contract -creation transaction using only one VM version, and it can deploy -other VM versions. +state. The design above gets account versioning by making the contract +*family* always have the same version. In this way, versions are only +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. Alternatively, account versioning can also be done through: