Skip to content

Commit

Permalink
Automatically merged updates to draft EIP(s) 1702 (ethereum#2131)
Browse files Browse the repository at this point in the history
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
  • Loading branch information
sorpaas authored and MadeofTin committed Nov 13, 2019
1 parent f4522dc commit 4be6e30
Showing 1 changed file with 34 additions and 17 deletions.
51 changes: 34 additions & 17 deletions EIPS/eip-1702.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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

Expand All @@ -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

Expand Down Expand Up @@ -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.

For contract deployment transaction, run the following additional
steps.

* 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.
`CREATE2` and contract deployment transaction's deployment phrase.

* 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:
* 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
Expand Down Expand Up @@ -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`

Expand Down

0 comments on commit 4be6e30

Please sign in to comment.