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

Jump to bottom

Update 1702 to be more clear about variant I/II and extensions #2130

Merged
merged 4 commits into from
Jun 21, 2019
Merged

Update 1702 to be more clear about variant I/II and extensions #2130

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
95ad920
Update 1702 to be more clear about variant I/II and extensions
sorpaas Jun 21, 2019
2b23dc2
Fix spelling
sorpaas Jun 21, 2019
2283c97
Add usage template
sorpaas Jun 21, 2019
3c602dd
Change "Future Specification" -> "Extensions"
sorpaas Jun 21, 2019
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
135 changes: 101 additions & 34 deletions EIPS/eip-1702.md
View file
Open in desktop
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