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 (#2152) 

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-27 22:09:14 +02:00 committed by EIP Automerge Bot
parent 5ba53445cb
commit e68dfdec62
1 changed files with 12 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
EIPS/eip-1702.md
View File

@ -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
@ -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: