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

Set status to ACCEPTED for EIP1014, EIP1052 #1692

Closed
wants to merge 1 commit into from
Closed

Set status to ACCEPTED for EIP1014, EIP1052 #1692

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
22 changes: 11 additions & 11 deletions EIPS/eip-1014.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
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: Draft
status: Accepted
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