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

EIP-1702: Remove mentioning of alternative design in rationale and add clarification of contract creation #2152

Merged
merged 3 commits into from
Jun 27, 2019
Merged

EIP-1702: Remove mentioning of alternative design in rationale and add clarification of contract creation #2152

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6312ffc
EIP-1702: Remove mentioning of alternative design in rationale
sorpaas Jun 27, 2019
28a3f1f
Add clarification of contract creation
sorpaas Jun 27, 2019
b914af0
using -> of
sorpaas Jun 27, 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
26 changes: 12 additions & 14 deletions EIPS/eip-1702.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -80,6 +80,11 @@ 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 *code's version*.

In other words, `CREATE` and `CREATE2` will execute the init code
using the current *code's version*, and deploy the contract of the
current *code's version*. This holds even if the to-be-deployed code
is empty.

### Validation

A new phrase, *validation* is added to contract deployment (by
Expand Down Expand Up @@ -177,20 +182,13 @@ fields, we also define:
## Rationale

This introduces account versioning via a new RLP item in account
state. The first design above gets account versioning by making the
contract *family* always have the same version. In this way, versions
are only needed to be provided by contract creation transaction, and
there is no restrictions on formats of code for any version. If we
want to support multiple newest VMs (for example, EVM and WebAssembly
running together), then this requires alternative design in contract
creation transaction section

The second design above requires new versions of VMs follow a
formatting -- that it always has a prefix. In this way, the version
can be derived from the prefix, thus allowing a contract *family* to
have multiple versions. It also makes it so that we can pin contract
creation transaction using only one VM version, and it can deploy
other VM versions.
state. The design above gets account versioning by making the contract
*family* always have the same version. In this way, versions are only
needed to be provided by contract creation transaction, and there is
no restrictions on formats of code for any version. If we want to
support multiple newest VMs (for example, EVM and WebAssembly running
together), then this will requires extensions such as EIP-2138 and
EIP-2139.

Alternatively, account versioning can also be done through:

Expand Down