mirror of
https://github.com/status-im/EIPs.git
synced 2025-02-04 19:13:48 +00:00
Automatically merged updates to draft EIP(s) 1702 (#2130)
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
EIP Automerge Bot
parent
725f3679be
commit
c603dccfef
135
EIPS/eip-1702.md
135
EIPS/eip-1702.md
@ -60,31 +60,6 @@ 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
|
||||
|
||||
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.
|
||||
|
||||
Apply the following cause on contract deployment for all `CREATE`,
|
||||
`CREATE2` and contract deployment transaction.
|
||||
|
||||
* If the `version` of caller (determined by `I_a`) is zero, then
|
||||
`CREATE` and `CREATE2` will always deploy contract with version zero.
|
||||
* If the `version` of caller (determined by `I_a`) 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`.
|
||||
|
||||
### Validation
|
||||
|
||||
A new phrase, *validation* is added to contract deployment (by
|
||||
@ -109,10 +84,65 @@ version. A contract creation transaction is always executed in
|
||||
run *validation* on the contract creation code. If it does not pass,
|
||||
return out-of-gas.
|
||||
|
||||
#### Alternative Design
|
||||
### Precompiled Contract and Externally-owned Address
|
||||
|
||||
This provides an alternative design that allows contract to be created
|
||||
in multiple versions.
|
||||
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
|
||||
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.
|
||||
|
||||
Apply the following cause on contract deployment for all `CREATE`,
|
||||
`CREATE2` and contract deployment transaction.
|
||||
|
||||
* If the `version` of caller (determined by `I_a`) is zero, then
|
||||
`CREATE` and `CREATE2` will always deploy contract with version zero.
|
||||
* If the `version` of caller (determined by `I_a`) 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.
|
||||
|
||||
### Extending Contract Creation Transaction
|
||||
|
||||
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`,
|
||||
@ -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
|
||||
### Extending `CREATE` and `CREATE2`
|
||||
|
||||
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`.
|
||||
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
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user