diff --git a/EIPS/eip-1013.md b/EIPS/eip-1013.md index 2aa87d149b5e26..04471b86df0301 100644 --- a/EIPS/eip-1013.md +++ b/EIPS/eip-1013.md @@ -3,7 +3,7 @@ eip: 1013 title: "Hardfork Meta: Constantinople" author: Nick Savers (@nicksavers) type: Meta -status: Draft +status: Final created: 2018-04-20 requires: 145, 1014, 1052, 1234, 1283 --- @@ -17,8 +17,8 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Cons - Codename: Constantinople - Aliases: Metropolis/Constantinople, Metropolis part 2 - Activation: - - Block >= TBD on the Ethereum mainnet - - Block >= 4,230,000 on the Ropsten testnet + - `Block >= 7_280_000` on the Ethereum mainnet + - `Block >= 4_230_000` on the Ropsten testnet - Included EIPs: - [EIP 145](./eip-145.md): Bitwise shifting instructions in EVM - [EIP 1014](./eip-1014.md): Skinny CREATE2 diff --git a/EIPS/eip-1014.md b/EIPS/eip-1014.md index f2c0575c3e375b..052cef73a8f611 100644 --- a/EIPS/eip-1014.md +++ b/EIPS/eip-1014.md @@ -4,7 +4,7 @@ title: Skinny CREATE2 author: Vitalik Buterin (@vbuterin) category: Core type: Standards Track -status: Accepted +status: Final created: 2018-04-20 --- @@ -14,13 +14,13 @@ Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_star 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 2374eec45f726d..c37eba9b4d7786 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: Accepted +status: Final 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. diff --git a/EIPS/eip-1234.md b/EIPS/eip-1234.md index e9767df903ad1e..5cf44307ef3793 100644 --- a/EIPS/eip-1234.md +++ b/EIPS/eip-1234.md @@ -5,7 +5,7 @@ author: Afri Schoedon (@5chdn) discussions-to: https://ethereum-magicians.org/t/eip-1234-constantinople-difficulty-bomb-delay-and-block-reward-adjustment/833 type: Standards Track category: Core -status: Accepted +status: Final created: 2018-07-19 --- diff --git a/EIPS/eip-1283.md b/EIPS/eip-1283.md index 52838fe7939448..85842338062514 100644 --- a/EIPS/eip-1283.md +++ b/EIPS/eip-1283.md @@ -3,7 +3,7 @@ eip: 1283 title: Net gas metering for SSTORE without dirty maps author: Wei Tang (@sorpaas) discussions-to: https://github.com/sorpaas/EIPs/issues/1 -status: Accepted +status: Final type: Standards Track category: Core created: 2018-08-01 @@ -27,7 +27,7 @@ available to most implementations, and require as little change in implementation structures as possible. * *Storage slot's original value*. -* *Storage slot's current value*. +* *Storage slot's current value*. * Refund counter. Usages that benefits from this EIP's gas reduction scheme includes: @@ -255,7 +255,7 @@ When *original value* is 0, we want to prove that: * **Case II**: If the *final value* ends up being a non-zero value, we want to charge `20000 + 200 * (N-1)` gas, because it requires writing this slot to disk. - + #### Base Case We always start at state A. The first SSTORE can: @@ -264,7 +264,7 @@ We always start at state A. The first SSTORE can: `200 * N == 200 * 1`. * Go to state B: 20000 gas is deducted. We satisfy *Case II* because `20000 + 200 * (N-1) == 20000 + 200 * 0`. - + #### Inductive Step * From A to A. The previous gas cost is `200 * (N-1)`. The current @@ -277,7 +277,7 @@ We always start at state A. The first SSTORE can: * From B to A. The previous gas cost is `20000 + 200 * (N-2)`. The current gas cost is `200 - 19800 + 20000 + 200 * (N-2)`. It satisfy *Case I*. - + ### Original Value Not Being Zero When *original value* is not 0, we want to prove that: @@ -289,7 +289,7 @@ When *original value* is not 0, we want to prove that: refund in actual defintion. * **Case III**: If the *final value* ends up being a changed non-zero value, we want to charge `5000 + 200 * (N-1)` gas. - + #### Base Case We always start at state X. The first SSTORE can: @@ -301,7 +301,7 @@ We always start at state X. The first SSTORE can: * Go to state Z: The absolute gas used is `5000 - 15000` where 15000 is the refund. We satisfy *Case II* because `5000 - 15000 + 200 * (N-1) == 5000 - 15000 + 200 * 0`. - + #### Inductive Step * From X to X. The previous gas cost is `200 * (N-1)`. The current gas diff --git a/EIPS/eip-145.md b/EIPS/eip-145.md index 2fd4657437e504..e3cc659122ac53 100644 --- a/EIPS/eip-145.md +++ b/EIPS/eip-145.md @@ -4,7 +4,7 @@ title: Bitwise shifting instructions in EVM author: Alex Beregszaszi (@axic), Paweł Bylica type: Standards Track category: Core -status: Accepted +status: Final created: 2017-02-13 ---