Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change I_a to the code's version #2131

Merged
merged 1 commit into from
Jun 21, 2019
Merged

Change I_a to the code's version #2131

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 34 additions & 17 deletions EIPS/eip-1702.md
View file
Open in desktop
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