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 is, `CREATE` and `CREATE2` will always deploy contract that has the
same `version` as the *code's version*. 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 ### Validation
A new phrase, *validation* is added to contract deployment (by A new phrase, *validation* is added to contract deployment (by
@ -177,20 +182,13 @@ fields, we also define:
## Rationale ## Rationale
This introduces account versioning via a new RLP item in account This introduces account versioning via a new RLP item in account
state. The first design above gets account versioning by making the state. The design above gets account versioning by making the contract
contract *family* always have the same version. In this way, versions *family* always have the same version. In this way, versions are only
are only needed to be provided by contract creation transaction, and needed to be provided by contract creation transaction, and there is
there is no restrictions on formats of code for any version. If we no restrictions on formats of code for any version. If we want to
want to support multiple newest VMs (for example, EVM and WebAssembly support multiple newest VMs (for example, EVM and WebAssembly running
running together), then this requires alternative design in contract together), then this will requires extensions such as EIP-2138 and
creation transaction section EIP-2139.
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.
Alternatively, account versioning can also be done through: Alternatively, account versioning can also be done through: