Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

EIP-1013: Finalize all Constantinople hard-fork EIPs #1642

Closed
wants to merge 5 commits into from
Closed

EIP-1013: Finalize all Constantinople hard-fork EIPs #1642

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
2b2975b
eip-1013: finalize constantinople hard-fork meta
5chdn Dec 9, 2018
42651d6
move all constantinople eips to final
5chdn Jan 21, 2019
6244561
fix Constantinople block number
5chdn Jan 21, 2019
f3fa54d
Merge branch 'master' into patch-3
5chdn Jan 21, 2019
251b4b8
Merge branch 'master' into patch-3
5chdn Jan 22, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions EIPS/eip-1013.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
---
Expand All @@ -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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this PR should also mark all these included EIPs as Final.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

- [EIP 145](./eip-145.md): Bitwise shifting instructions in EVM
- [EIP 1014](./eip-1014.md): Skinny CREATE2
Expand Down
20 changes: 10 additions & 10 deletions EIPS/eip-1014.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ title: Skinny CREATE2
author: Vitalik Buterin (@vbuterin)
category: Core
type: Standards Track
status: Accepted
status: Final
created: 2018-04-20
---

Expand All @@ -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
Expand All @@ -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

Expand All @@ -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

Expand Down
18 changes: 9 additions & 9 deletions EIPS/eip-1052.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ eip: 1052
title: EXTCODEHASH opcode
author: Nick Johnson <arachnid@notdot.net>, Paweł Bylica <pawel@ethereum.org>
discussions-to: https://ethereum-magicians.org/t/extcodehash-opcode/262
status: Accepted
status: Final
type: Standards Track
category: Core
created: 2018-05-02
Expand All @@ -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.

Expand All @@ -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.
Expand Down
2 changes: 1 addition & 1 deletion EIPS/eip-1234.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
---

Expand Down
14 changes: 7 additions & 7 deletions EIPS/eip-1283.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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:
Expand Down Expand Up @@ -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:
Expand All @@ -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
Expand All @@ -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:
Expand All @@ -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:
Expand All @@ -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
Expand Down
2 changes: 1 addition & 1 deletion EIPS/eip-145.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
---

Expand Down