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

update eip-1014 according to coredev decision #1375

Merged
merged 13 commits into from
Oct 3, 2018
Merged

update eip-1014 according to coredev decision #1375

Changes from 6 commits
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
8aab71a
update eip-1014 according to coredev decision
holiman Sep 3, 2018
6985e8c
Updates and examples
holiman Sep 24, 2018
f6775aa
comment about salt
holiman Sep 28, 2018
344dd2b
minor fix
holiman Sep 28, 2018
0e1a240
add example of empty code
holiman Sep 28, 2018
5d83a9d
Merge branch 'master' into fix_create2
holiman Sep 28, 2018
53c72c6
fix reviewer comments
holiman Sep 30, 2018
9ddb022
Merge branch 'fix_create2' of github.com:holiman/EIPs into fix_create2
holiman Sep 30, 2018
ec978fd
Merge branch 'master' into fix_create2
holiman Sep 30, 2018
edf0f1c
eip1014: add cost-per-byte to CREATE2
holiman Oct 2, 2018
1260664
Merge branch 'master' into fix_create2
holiman Oct 2, 2018
b3fb4ea
eip1014: added gas to examples
holiman Oct 2, 2018
fa52665
Merge branch 'master' into fix_create2
holiman Oct 3, 2018
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
74 changes: 70 additions & 4 deletions EIPS/eip-1014.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,14 +10,80 @@ 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(msg.sender ++ salt ++ 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 `salt` is a 32-byte stack item.

Copy link
Contributor

Choose a reason for hiding this comment

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

Here still the wrong formula is cited.

It would also be good to have a short explanation of the difference between init_code and code added to the EIP.

The coredev-call at 2018-08-10 decided to use the formula above.
Copy link
Member

Choose a reason for hiding this comment

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

Move it to Rationale?



### Motivation

Allows interactions to (actually or counterfactually in channels) be made with addresses that do not exist yet on-chain but can be relied on to only possibly eventually contain code that has been created by a particular piece of init code. Important for state-channel use cases that involve counterfactual interactions with contracts.

#### Option 2
### Rationale about address formula

* Ensures that addresses created with this scheme cannot collide with addresses created using the traditional `keccak256(rlp([sender, nonce]))` formula, as `0xff` can only be a starting byte for RLP for data many petabytes long.
* Ensures that the hash preimage has a fixed size,

This also has the side-effect of being able to possibly reuse the `keccak256(init_code)` from earlier calculation, either within a client or via `EXTCODEHASH` if the init-code is deployed on-chain.

Copy link
Contributor

Choose a reason for hiding this comment

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

But the init_code is not the code that gets installed into the smart contract. That's the difference between code and init_code.

Copy link
Contributor

Choose a reason for hiding this comment

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

So how it can improve EXTCODEHASH ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So the thought was, that if it's a very large initcode, and the verification of a given contract needs to be cheap in gas, the init_code could be deployed on-chain.

If a contract A wants to verify a given contract address C, instead of feeding it the initcode and then force A do calculate the sha3(init_code), A could just use the EXTCODEHASH(D). Then A would know that yes, the initcode matches what's in D. Where D would be a piece of whitelisted init_code.

But yeah, maybe I should remove that. It was a 'hmm maybe this is useful for some scenario somewhere' kind of thing.

### Clarifications

The `initcode` is the code that, when executed, produces the runtime bytecode that will be placed into the state, and which typically is used by high level languages to implement a 'constructor'.
Copy link
Member

Choose a reason for hiding this comment

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

Should be init_code.


This EIP makes collisions possible. The behaviour at collisions is specified by [EIP 684](https://github.com/ethereum/EIPs/issues/684):

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

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/

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

Example 0
* address `0x0000000000000000000000000000000000000000`
* salt `0x0000000000000000000000000000000000000000000000000000000000000000`
* code `0x00`
* result: `0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38`

Example 1
* address `0xdeadbeef00000000000000000000000000000000`
* salt `0x0000000000000000000000000000000000000000000000000000000000000000`
* code `0x00`
* result: `0xB928f69Bb1D91Cd65274e3c79d8986362984fDA3`

Example 2
* address `0xdeadbeef00000000000000000000000000000000`
* salt `0x000000000000000000000000feed000000000000000000000000000000000000`
* code `0x00`
* result: `0xD04116cDd17beBE565EB2422F2497E06cC1C9833`

Example 3
* address `0x0000000000000000000000000000000000000000`
* salt `0x0000000000000000000000000000000000000000000000000000000000000000`
* code `0xdeadbeef`
* result: `0x70f2b2914A2a4b783FaEFb75f459A580616Fcb5e`

Example 4
* address `0x00000000000000000000000000000000deadbeef`
* salt `0x00000000000000000000000000000000000000000000000000000000cafebabe`
* code `0xdeadbeef`
* result: `0x60f3f640a8508fC6a86d45DF051962668E1e8AC7`

Use `keccak256(0xff ++ msg.sender ++ salt ++ init_code)[12:]`
Example 5
* address `0x00000000000000000000000000000000deadbeef`
* salt `0x00000000000000000000000000000000000000000000000000000000cafebabe`
* code `0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef`
* result: `0x1d8bfDC5D46DC4f61D6b6115972536eBE6A8854C`

Rationale: ensures that addresses created with this scheme cannot collide with addresses created using the traditional `keccak256(rlp([sender, nonce]))` formula, as 0xff can only be a starting byte for RLP for data many petabytes long.
Example 6
* address `0x0000000000000000000000000000000000000000`
* salt `0x0000000000000000000000000000000000000000000000000000000000000000`
* code `0x`
* result: `0xE33C0C7F7df4809055C3ebA6c09CFe4BaF1BD9e0`