status-im
/
EIPs
mirror of https://github.com/status-im/EIPs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 1702 (#2140) 

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
This commit is contained in:
Wei Tang 2019-06-24 17:20:07 +02:00 committed by EIP Automerge Bot
parent 4bde784976
commit 423d88fb75
1 changed files with 12 additions and 89 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

101
EIPS/eip-1702.md
View File

@ -98,100 +98,23 @@ Precompiled contracts and externally-owned addresses do not have
`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
different.
The client maintains a mapping `V` of currently supported version
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's deployment phrase.
* 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
(with prefix).
* Deploy the contract with `version`.
## Extensions
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.
In relation to the above "Specification" section, 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 base layer account versioning.
### Extending Contract Creation Transaction
Note that this section is provided only for documentation
purpose. When "enabling EIP-1702", those extensions should not be
enabled unless the extension EIP is also included.
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`,
`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 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`
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.
- [EIP-2138: Account Versioning Extension for Contract Creation
Transaction](https://github.com/ethereum/EIPs/pull/2138)
- [EIP-2139: Account Versioning Extension for CREATE and
CREATE2](https://github.com/ethereum/EIPs/pull/2139)
## Usage Template