From fb1b406d3ac6220cf41f3167325945d2f46aa672 Mon Sep 17 00:00:00 2001 From: Boris Mann Date: Fri, 11 Jan 2019 11:45:59 -0800 Subject: [PATCH] Set status to ACCEPTED for EIP1014, EIP1052 as both are going live in Constantinople --- EIPS/eip-1014.md | 22 +++++++++++----------- EIPS/eip-1052.md | 18 +++++++++--------- 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/EIPS/eip-1014.md b/EIPS/eip-1014.md index dc3aac23bbcedb..26ffc2c6fea04f 100644 --- a/EIPS/eip-1014.md +++ b/EIPS/eip-1014.md @@ -4,23 +4,23 @@ title: Skinny CREATE2 author: Vitalik Buterin (@vbuterin) category: Core type: Standards Track -status: Draft +status: Accepted created: 2018-04-20 --- ### Specification -Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using `keccak256( 0xff ++ address ++ salt ++ keccak256(init_code)))[12:]` instead of the usual sender-and-nonce-hash as the address where the contract is initialized at. +Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using `keccak256( 0xff ++ address ++ salt ++ keccak256(init_code)))[12:]` instead of the usual sender-and-nonce-hash as the address where the contract is initialized at. The `CREATE2` has the same `gas` schema as `CREATE`, but also an extra `hashcost` of `GSHA3WORD * ceil(len(init_code) / 32)`, to account for the hashing that must be performed. The `hashcost` is deducted at the same time as memory-expansion gas and `CreateGas` is deducted: _before_ evaluation of the resulting address and the execution of `init_code`. -- `0xff` is a single byte, -- `address` is always `20` bytes, -- `salt` is always `32` bytes (a stack item). +- `0xff` is a single byte, +- `address` is always `20` bytes, +- `salt` is always `32` bytes (a stack item). The preimage for the final hashing round is thus always exactly `85` bytes long. -The coredev-call at 2018-08-10 decided to use the formula above. +The coredev-call at 2018-08-10 decided to use the formula above. ### Motivation @@ -36,7 +36,7 @@ Allows interactions to (actually or counterfactually in channels) be made with a #### Gas cost -Since address calculation depends on hashing the `init_code`, it would leave clients open to DoS attacks if executions could repeatedly cause hashing of large pieces of `init_code`, since expansion of memory is paid for only once. This EIP uses the same cost-per-word as the `SHA3` opcode. +Since address calculation depends on hashing the `init_code`, it would leave clients open to DoS attacks if executions could repeatedly cause hashing of large pieces of `init_code`, since expansion of memory is paid for only once. This EIP uses the same cost-per-word as the `SHA3` opcode. ### Clarifications @@ -46,15 +46,15 @@ This EIP makes collisions possible. The behaviour at collisions is specified by > If a contract creation is attempted, due to either a creation transaction or the CREATE (or future CREATE2) opcode, and the destination address already has either nonzero nonce, or nonempty code, then the creation throws immediately, with exactly the same behavior as would arise if the first byte in the init code were an invalid opcode. This applies retroactively starting from genesis. -Specifically, if `nonce` or `code` is nonzero, then the create-operation fails. +Specifically, if `nonce` or `code` is nonzero, then the create-operation fails. -With [EIP 161](https://eips.ethereum.org/EIPS/eip-161) +With [EIP 161](https://eips.ethereum.org/EIPS/eip-161) > Account creation transactions and the CREATE operation SHALL, prior to the execution of the initialisation code, increment the nonce over and above its normal starting value by one -This means that if a contract is created in a transaction, the `nonce` is immediately non-zero, with the side-effect that a collision within the same transaction will always fail -- even if it's carried out from the `init_code` itself/ +This means that if a contract is created in a transaction, the `nonce` is immediately non-zero, with the side-effect that a collision within the same transaction will always fail -- even if it's carried out from the `init_code` itself/ -It should also be noted that `SELFDESTRUCT` has no immediate effect on `nonce` or `code`, thus a contract cannot be destroyed and recreated within one transaction. +It should also be noted that `SELFDESTRUCT` has no immediate effect on `nonce` or `code`, thus a contract cannot be destroyed and recreated within one transaction. ### Examples diff --git a/EIPS/eip-1052.md b/EIPS/eip-1052.md index dec0057db60af5..dea25fb802a74d 100644 --- a/EIPS/eip-1052.md +++ b/EIPS/eip-1052.md @@ -3,7 +3,7 @@ eip: 1052 title: EXTCODEHASH opcode author: Nick Johnson , Paweł Bylica discussions-to: https://ethereum-magicians.org/t/extcodehash-opcode/262 -status: Draft +status: Accepted type: Standards Track category: Core created: 2018-05-02 @@ -19,10 +19,10 @@ Contracts can presently do this using the `EXTCODECOPY` opcode, but this is expe ## Specification -A new opcode, `EXTCODEHASH`, is introduced, with number 0x3F. The `EXTCODEHASH` -takes one argument from the stack, zeros the first 96 bits -and pushes to the stack the keccak256 hash of the code of the account -at the address being the remaining 160 bits. +A new opcode, `EXTCODEHASH`, is introduced, with number 0x3F. The `EXTCODEHASH` +takes one argument from the stack, zeros the first 96 bits +and pushes to the stack the keccak256 hash of the code of the account +at the address being the remaining 160 bits. In case the account does not exist `0` is pushed to the stack. @@ -35,14 +35,14 @@ The gas cost of the `EXTCODEHASH` is 400. ## Rationale -As described in the motivation section, this opcode is widely useful, and saves +As described in the motivation section, this opcode is widely useful, and saves on wasted gas in many cases. -The gas cost is the same as the gas cost for the `BALANCE` opcode because the +The gas cost is the same as the gas cost for the `BALANCE` opcode because the execution of the `EXTCODEHASH` requires the same account lookup as in `BALANCE`. -Only the 20 last bytes of the argument are significant (the first 12 bytes are -ignored) similarly to the semantics of the `BALANCE`, `EXTCODESIZE` and +Only the 20 last bytes of the argument are significant (the first 12 bytes are +ignored) similarly to the semantics of the `BALANCE`, `EXTCODESIZE` and `EXTCODECOPY`. The `EXTCODEHASH` distincts accounts without code and non-existing accounts.