Skip to content

Commit

Permalink
Automatically merged updates to draft EIP(s) 1702 (#2130)
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 eip-automerger committed Jun 21, 2019
1 parent 725f367 commit c603dcc
Showing 1 changed file with 101 additions and 34 deletions.
135 changes: 101 additions & 34 deletions EIPS/eip-1702.md
Original file line number Diff line number Diff line change
Expand Up @@ -60,7 +60,48 @@ 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`.

#### Alternative Design
### Validation

A new phrase, *validation* is added to contract deployment (by
`CREATE` / `CREATE2` opcodes, or by contract creation
transaction). When `version` is `0`, the phrase does nothing and
always succeeds. Future VM versions can define additional validation
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.

### Precompiled Contract and Externally-owned Address

Precompiled contracts and externally-owned addresses do not have
`version`. If a message-call transaction or `CALL` / `CALLCODE` /
`STATICCALL` / `DELEGATECALL` touches a new externally-owned address
or a non-existing precompiled contract address, it is always created
with `version` field being `0`.

## Alternative Specification

The above "Specification" section is commonly known as EIP-1702
variant I, below we define an alternative design, commonly known as
EIP-1702 variant II.

Applies all sections in "Specification" except "Contract Deployment",
and change it as below.

### Contract Deployment

This provides an alternative design that allows `CREATE`, `CREATE2`
and contract creation transaction to deploy contract whose version are
Expand All @@ -84,35 +125,24 @@ Apply the following cause on contract deployment for all `CREATE`,
* Use `version`'s validation procedure to validate the *whole* code
(with prefix).
* Deploy the contract with `version`.

## Extensions

### Validation
In relation to the above "Specification" section (EIP-1702 variant I),
we have defined the base account versioning layer. The base account
versioning layer is already useful by itself and can handle most EVM
improvements. Below we define two specifications that can be deployed
separately, which improves functionality of variant I.

A new phrase, *validation* is added to contract deployment (by
`CREATE` / `CREATE2` opcodes, or by contract creation
transaction). When `version` is `0`, the phrase does nothing and
always succeeds. Future VM versions can define additional validation
that has to be passed.
### Extending Contract Creation Transaction

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.

#### Alternative Design

This provides an alternative design that allows contract to be created
in multiple versions.
The base account versioning layer only allows contract of the
newest version to be deployed via contract creation transaction. This
is a reasonable assumption for current Ethereum network, because most
of new features added to EVM are additions, and developers almost
never want to deploy contracts that are not of the newest version. In
this section, we provide an extension to allow multiple versions of
contracts to be deployed via contract creation transaction.

Add an additional field `version` (256-bit integer) in contract
creation transaction. So it becomes `nonce`, `gasprice`, `startgas`,
Expand All @@ -122,13 +152,50 @@ 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.

### Precompiled Contract and Externally-owned Address

Precompiled contracts and externally-owned addresses do not have
`version`. If a message-call transaction or `CALL` / `CALLCODE` /
`STATICCALL` / `DELEGATECALL` touches a new externally-owned address
or a non-existing precompiled contract address, it is always created
with `version` field being `0`.
### Extending `CREATE` and `CREATE2`

The base account versioning layer only allows contracts of the same
version to be deployed through `CREATE` and `CREATE2`. In this
section, we provide an extension to allow different versions of
contracts to be deployed via them, by providing two new opcodes,
`VCREATE` and `VCREATE2`.

Define two new opcodes `VCREATE` and `VCREATE2` at `0xf6` and `0xf7`
respectively. `VCREATE` takes 4 stack arguments (version, value, input
offset, input size), and `VCREATE2` takes 5 stack arguments (version,
endowment, memory_start, memory_length, salt). Note that except the
stack item `version`, other arguments are the same as `CREATE` and
`CREATE2`.

The two new opcodes behave identically to `CREATE` and `CREATE2`,
except that it deploys contracts with version specified by stack item
`version`.

The network at all times maintains a constant list within the client
of all deployable versions (which can be different from supported
versions). Upon `VCREATE` and `VCREATE2`, if the specified `version`
is not on the list of deployable versions, return out-of-gas.

## 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.

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:

* **Version**: a non-zero integer less than `2^256` that uniquely
identifies this version. Note that it does not need to be
sequential.
* **Parent version**: the base that all new features derived
from. With parent version of `0` we define the base to be legacy
VM. Note that once a version other than `0` is defined, the legacy
VM's feature set must be frozen. When defining an entirely new VM
(such as eWASM), parent version does not apply.
* **Features**: all additional features that are enabled upon this
version.

## Rationale

Expand Down

0 comments on commit c603dcc

Please sign in to comment.