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

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 2020-02-15 21:53:43 +01:00 committed by GitHub
parent 66e1f04a60
commit 156233fab3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -116,7 +116,7 @@ with `version` field being `0`.
### Additional Fields in Account State RLP
In the future we may need to associate more information into an
account, and we already have some EIP/ECIPs that define new additional
account, and we already have some EIPs that define new additional
fields in the account state RLP. In this section, we define the
parsing strategy when additional fields are added.
@ -143,18 +143,18 @@ purpose. When "enabling EIP-1702", those extensions should not be
enabled unless the extension specification is also included.
- [44-VERTXN: Account Versioning Extension for Contract Creation
Transaction](https://specs.that.world/44-vertxn/)
Transaction](https://specs.corepaper.org/44-vertxn/)
- [45-VEROP: Account Versioning Extension for CREATE and
CREATE2](https://specs.that.world/45-verop/)
CREATE2](https://specs.corepaper.org/45-verop/)
## Usage Template
This section defines how other EIP/ECIPs might use this account
This section defines how other EIPs might use this account
versioning specification. Note that currently we only define the usage
template for base layer.
Account versioning is usually applied directly to a hard fork
meta. EIP/ECIPs in the hard fork are grouped by the virtual machine
meta. 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 scalar less than `2^256` that uniquely
@ -168,7 +168,7 @@ type, for example, EVM and eWASM. For each of them, we define:
* **Features**: all additional features that are enabled upon this
version.
If a meta EIP/ECIP includes EIP/ECIPs that provide additional account state RLP
If a meta EIP includes EIPs that provide additional account state RLP
fields, we also define:
* **Account fields**: all account fields up to the end of this meta
@ -192,8 +192,8 @@ together), then this will requires extensions such as 44-VERTXN and
Alternatively, account versioning can also be done through:
* **[26-VER](https://specs.that.world/26-ver/)** and
**[40-UNUSED](https://specs.that.world/40-unused/)**: This makes an
* **[26-VER](https://specs.corepaper.org/26-ver/)** and
**[40-UNUSED](https://specs.corepaper.org/40-unused/)**: This makes an
account's versioning soly dependent on its code header prefix. If
with only 26-VER, it is not possible to certify any code is valid,
because current VM allows treating code as data. This can be fixed
@ -234,12 +234,7 @@ To be added.
## References
The source of this specification can be found at
[43-VER](https://specs.that.world/43-ver/). This specification is
also realized in:
* Ethereum Classic Improvement Proposals as
[ECIP-1040](https://ecips.ethereumclassic.org/ECIPs/ecip-1040).
[43-VER](https://specs.corepaper.org/43-ver/).
## Copyright