From 5ebc5df9ece056ad6068388af701a892d91c88a7 Mon Sep 17 00:00:00 2001 From: Wei Tang Date: Fri, 21 Jun 2019 05:10:05 +0200 Subject: [PATCH] Automatically merged updates to draft EIP(s) 1702 (#2131) 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 | 53 ++++++++++++++++++++++++++++++++---------------- 1 file changed, 35 insertions(+), 18 deletions(-) diff --git a/EIPS/eip-1702.md b/EIPS/eip-1702.md index 588bbc2f..9601c298 100644 --- a/EIPS/eip-1702.md +++ b/EIPS/eip-1702.md @@ -48,6 +48,17 @@ items: `nonce`, `balance`, `storageRoot`, `codeHash`, and items. When `version` is not zero, the account is RLP-encoded with 5 items. +### Contract Execution + +When fetching an account code from state, we always fetch the +associated version field together. We refer to this as the *code's +version* below. The code of the account is always executed in the +*code's version*. + +In particular, this means that for `DELEGATECALL` and `CALLCODE`, the +version of the execution call frame is the same as +delegating/receiving contract's version. + ### Contract Deployment In Ethereum, a contract has a deployment method, either by a contract @@ -58,7 +69,7 @@ transaction. 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 calling `address`. +same `version` as the *code's version*. ### Validation @@ -71,18 +82,14 @@ that has to be passed. If the validation phrase fails, deployment does not proceed and return out-of-gas. -### Contract Execution - -VM version used in contract execution is determined via calling -`address` (`I_a` in yellow paper). - ### Contract Creation Transaction Define `LATEST_VERSION` in a hard fork to be the latest supported VM version. A contract creation transaction is always executed in -`LATEST_VERSION`. Before a contract creation transaction is executed, -run *validation* on the contract creation code. If it does not pass, -return out-of-gas. +`LATEST_VERSION` (which means the *code's version* is +`LATEST_VERSION`), and deploys contracts of `LATEST_VERSION`. Before a +contract creation transaction is executed, run *validation* on the +contract creation code. If it does not pass, return out-of-gas. ### Precompiled Contract and Externally-owned Address @@ -112,14 +119,23 @@ 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. -Apply the following cause on contract deployment for all `CREATE`, -`CREATE2` and contract deployment transaction. +For contract deployment transaction, run the following additional +steps. -* If the `version` of caller (determined by `I_a`) is zero, then - `CREATE` and `CREATE2` will always deploy contract with version zero. -* If the `version` of caller (determined by `I_a`) 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). +* 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 @@ -149,8 +165,9 @@ 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 in `version` supplied. If `version` -is not supported or *validation* does not pass, return out-of-gas. +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`