EIP-1013: Finalize all Constantinople hard-fork EIPs

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

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
 

EIPS/eip-1052.md

@@ -3,7 +3,7 @@ eip: 1052
 title: EXTCODEHASH opcode
 author: Nick Johnson <[email protected]>, Paweł Bylica <[email protected]>
 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.

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
 ---
 

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

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
 ---