update eip-1014 according to coredev decision #1375

holiman · 2018-09-03T07:24:59Z

This updates EIP 1014 with a third option for address calculation, the formula that was accepted at the coredev-call on Aug 10, 2018.
See #1014 (comment)

eip-automerger · 2018-09-03T07:27:54Z

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

EIP 1014 requires approval from one of (@vbuterin)

axic · 2018-09-04T18:52:13Z

Shouldn't the different options be moved into the Rationale section, while leaving the final one under Specification ?

axic · 2018-09-21T22:34:11Z

@Souptacular @5chdn @chfast is this the last version agreed on the call? If so, can this be merged?

holgerd77 · 2018-09-24T14:14:26Z

EIPS/eip-1014.md

@@ -12,6 +12,8 @@ created: 2018-04-20

 Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using `sha3(msg.sender ++ salt ++ init_code)[12:]` instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.



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.

holgerd77 · 2018-09-24T14:19:29Z

Some examples would be very helpful here for having the basic hash creation verified, optimally also providing both the complete contract code and the init code for the contract.

holiman · 2018-09-24T14:23:07Z

I agree. I'll try to update this PR with the comments from @axic (remove unused formulas) and some examples
Plus explain difference between code and initcode, plus reference EIP 684 regarding collisions, and also explain why single-tx delete+overwrite is impossible, due to nonce != 0 and selfdestruct cleanup only happens post execution

holiman · 2018-09-24T15:46:05Z

I have pushed some updates to this PR now. Please review (I still haven't added any examples though). cc @SergioDemianLerner

axic · 2018-09-25T22:10:35Z

Can #1247 merged first?

axic · 2018-09-27T19:42:56Z

Needs a rebase. Also should clarify how 0xff and salt are treated (endianess, width). @karalabe has raised these questions too, I think on the original PR.

holgerd77 · 2018-09-28T08:27:31Z

@holiman If you give a short answer on the question from @axic on 0xff and possible salt values, we or someone from the community might also be able to stick some first examples together which can be incorporated here.

holiman · 2018-09-28T08:55:14Z

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

Example 5

address 0x00000000000000000000000000000000deadbeef
salt 0x00000000000000000000000000000000000000000000000000000000cafebabe
code 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef
result: 0x1d8bfDC5D46DC4f61D6b6115972536eBE6A8854C

holiman · 2018-09-28T09:08:55Z

Added examples, rebased, added comment about salt. I don't understand the question about endianness for 0xff ??

holiman · 2018-09-28T09:12:34Z

ping @vbuterin PTAL

chfast · 2018-09-28T14:25:39Z

EIPS/eip-1014.md

-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.
+
+The coredev-call at 2018-08-10 decided to use the formula above. 


Move it to Rationale?

chfast · 2018-09-28T14:25:59Z

EIPS/eip-1014.md

+
+### 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'.


Should be init_code.

vbuterin · 2018-09-28T15:24:21Z

I don't understand the question about endianness for 0xff ??

Yeah, me neither. 0xff is a single byte.

Salt is always 32 bytes.

Edit: this example from @holiman is correct.

Example 0

address 0x0000000000000000000000000000000000000000
salt 0x0000000000000000000000000000000000000000000000000000000000000000
code 0x00
result: 0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38

SergioDemianLerner · 2018-09-28T23:20:01Z

EIPS/eip-1014.md

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


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

So how it can improve EXTCODEHASH ?

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.

SergioDemianLerner · 2018-09-28T23:30:27Z

One issue that is still unaddressed is who pays the cost of hashing (if it turns out that it has significance compared to other costs)

It was raised by @holiman here:
#1014 (comment)

And I proposed a simple solution here: #1014 (comment)

vbuterin · 2018-09-29T00:26:07Z

One issue that is still unaddressed from is who pays the cost of hashing (if it turns out that it has significance compared to other costs)

Ah I see; yes, this is genuinely an important point.

And I proposed a simple solution here: #1014 (comment)

That solution seems fine to me.

axic · 2018-09-29T02:43:13Z

I don't understand the question about endianness for 0xff ??

Whether 0xff is an actual single byte or a stack item with the value of 0xff. In general I think the EIP is vague and could be improved regarding clarity.

holiman · 2018-09-29T06:29:32Z

Re the cost of hashing, I'll do some benchmarks. However, I think all initcode is already hashed today, for making a key to the lookup on valid-jumpdest-map. So that key can be reused, even though I suspect it may be is hashed twice right now (for geth I know it is)

holgerd77 · 2018-09-29T12:27:27Z

Hello @holiman Martin, having problems getting the examples to run, I am getting different hashes.

I assume the code field you provide in the examples is the initCode?

If so: can you rename this to initCode?
If not: how can I transform this? Can you still add some explanation of this to the EIP text?

Update with some contextual links:

Deploying a smart contract with just bytecode, Stack Exchange
The Structure of an LLL Contract - Part 2, media.consensys.net
Life Cycle of an Ethereum Transaction, Medium, blockchannel

vbuterin · 2018-09-29T12:36:54Z

I'd support changing the first paragraph to:

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. 0xff is included as a single byte, address always as exactly 20 bytes, salt always as exactly 32 bytes (so the data hashed is always exactly 85 bytes long).

Possibly add to the end:

Additionally, an extra GSHA3WORD * ceil(len(init_code) / 32) gas is charged.

holgerd77 · 2018-09-29T14:20:06Z

Update: ok, failing hash creation was (as most of the time 😄) a bug on the implementation side, now fixed this and can confirm that all examples are working.

I've created an example json file from these over on ethereumjs-util (currently still within an open PR) if someone want to reuse.

Nevertheless would pledge to rename code to init_code in the examples to avoid confusion. Also is there any reason for these mixed capital- and non-capital-letters in the result value definitions (I have now taken the lowercase version for our example json file)?

holiman · 2018-09-29T14:42:44Z

I'll

rename code to initcode
update text with @vbuterin's text

Re upper/lowercase, I printed it from golang which automatically checksums addresses on String().

I don't think we should add gascost for initcode until it's been discussed and ok:ed by allcoredevs.

Until then, I'll try to benchmark it and see if it's an issue

holiman · 2018-09-30T11:58:52Z

Fixed, ptal

rmeissner · 2018-10-01T09:08:05Z

Since there are additional gas costs involved now, could the expected gas costs be part of the tests?

holiman · 2018-10-02T11:56:16Z

For reference - discussion here: https://gitter.im/ethereum/AllCoreDevs?at=5bb315de6e5a401c2d037971

I have now updated the PR again, to include cost per byte. Yes, that should be included in testcases, I guess...

holiman · 2018-10-02T12:18:23Z

Testcases updated

holiman · 2018-10-03T13:35:58Z

This PR has been sitting a long time, and the EIP that is "current" contains errors. I'm going to admin-merge this, since,

It seems to be approved, at least implicitly, but the eip author @vbuterin
The gascost changes seems to have been met with approval from the allcoredev gitter room
It's very bad to have a stale EIP that does not contain what the actual clients have implemented or should implement

holiman requested a review from vbuterin September 3, 2018 07:25

holiman mentioned this pull request Sep 24, 2018

Skinny CREATE2 #1014

Merged

holgerd77 reviewed Sep 24, 2018

View reviewed changes

jwasinger mentioned this pull request Sep 28, 2018

add generateAddress2 for CREATE2 ethereumjs/ethereumjs-util#146

Merged

holgerd77 mentioned this pull request Sep 28, 2018

EIP 1014 CREATE2 ethereumjs/ethereumjs-monorepo#329

Merged

holiman added 2 commits September 28, 2018 10:57

update eip-1014 according to coredev decision

8aab71a

Updates and examples

6985e8c

holiman force-pushed the fix_create2 branch from 1ae8d18 to 6985e8c Compare September 28, 2018 09:05

comment about salt

f6775aa

minor fix

344dd2b

holiman added 2 commits September 28, 2018 12:17

add example of empty code

0e1a240

Merge branch 'master' into fix_create2

5d83a9d

chfast reviewed Sep 28, 2018

View reviewed changes

zilm13 mentioned this pull request Sep 28, 2018

Constantinople ethereum/ethereumj#1149

Closed

5 tasks

SergioDemianLerner reviewed Sep 28, 2018

View reviewed changes

holiman added 2 commits September 30, 2018 13:57

fix reviewer comments

53c72c6

Merge branch 'fix_create2' of github.com:holiman/EIPs into fix_create2

9ddb022

Merge branch 'master' into fix_create2

ec978fd

eip1014: add cost-per-byte to CREATE2

edf0f1c

holiman added 2 commits October 2, 2018 13:56

Merge branch 'master' into fix_create2

1260664

eip1014: added gas to examples

b3fb4ea

gumb0 mentioned this pull request Oct 2, 2018

Charge for hashing init code in CREATE2 ethereum/aleth#5295

Merged

pipermerriam mentioned this pull request Oct 2, 2018

changes to CREATE2 ethereum/py-evm#1346

Closed

Merge branch 'master' into fix_create2

fa52665

holiman merged commit 1d50630 into ethereum:master Oct 3, 2018

whilei mentioned this pull request Oct 5, 2018

CREATE2 opcode support ETCDEVTeam/etcommon-rs#67

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

update eip-1014 according to coredev decision #1375

update eip-1014 according to coredev decision #1375

holiman commented Sep 3, 2018

eip-automerger commented Sep 3, 2018

axic commented Sep 4, 2018

axic commented Sep 21, 2018

holgerd77 Sep 24, 2018

holgerd77 commented Sep 24, 2018

holiman commented Sep 24, 2018 •

edited

Loading

holiman commented Sep 24, 2018

axic commented Sep 25, 2018

axic commented Sep 27, 2018

holgerd77 commented Sep 28, 2018

holiman commented Sep 28, 2018 •

edited

Loading

holiman commented Sep 28, 2018

holiman commented Sep 28, 2018

chfast Sep 28, 2018

chfast Sep 28, 2018

vbuterin commented Sep 28, 2018 •

edited

Loading

SergioDemianLerner Sep 28, 2018

SergioDemianLerner Sep 28, 2018

holiman Sep 29, 2018

SergioDemianLerner commented Sep 28, 2018 •

edited

Loading

vbuterin commented Sep 29, 2018

axic commented Sep 29, 2018 •

edited

Loading

holiman commented Sep 29, 2018

holgerd77 commented Sep 29, 2018 •

edited

Loading

vbuterin commented Sep 29, 2018

holgerd77 commented Sep 29, 2018

holiman commented Sep 29, 2018

holiman commented Sep 30, 2018

rmeissner commented Oct 1, 2018

holiman commented Oct 2, 2018

holiman commented Oct 2, 2018

holiman commented Oct 3, 2018

		@@ -12,6 +12,8 @@ created: 2018-04-20

		Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using `sha3(msg.sender ++ salt ++ init_code)[12:]` instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.


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

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

update eip-1014 according to coredev decision #1375

update eip-1014 according to coredev decision #1375

Conversation

holiman commented Sep 3, 2018

eip-automerger commented Sep 3, 2018

axic commented Sep 4, 2018

axic commented Sep 21, 2018

holgerd77 Sep 24, 2018

Choose a reason for hiding this comment

holgerd77 commented Sep 24, 2018

holiman commented Sep 24, 2018 • edited Loading

holiman commented Sep 24, 2018

axic commented Sep 25, 2018

axic commented Sep 27, 2018

holgerd77 commented Sep 28, 2018

holiman commented Sep 28, 2018 • edited Loading

holiman commented Sep 28, 2018

holiman commented Sep 28, 2018

chfast Sep 28, 2018

Choose a reason for hiding this comment

chfast Sep 28, 2018

Choose a reason for hiding this comment

vbuterin commented Sep 28, 2018 • edited Loading

SergioDemianLerner Sep 28, 2018

Choose a reason for hiding this comment

SergioDemianLerner Sep 28, 2018

Choose a reason for hiding this comment

holiman Sep 29, 2018

Choose a reason for hiding this comment

SergioDemianLerner commented Sep 28, 2018 • edited Loading

vbuterin commented Sep 29, 2018

axic commented Sep 29, 2018 • edited Loading

holiman commented Sep 29, 2018

holgerd77 commented Sep 29, 2018 • edited Loading

vbuterin commented Sep 29, 2018

holgerd77 commented Sep 29, 2018

holiman commented Sep 29, 2018

holiman commented Sep 30, 2018

rmeissner commented Oct 1, 2018

holiman commented Oct 2, 2018

holiman commented Oct 2, 2018

holiman commented Oct 3, 2018

holiman commented Sep 24, 2018 •

edited

Loading

holiman commented Sep 28, 2018 •

edited

Loading

vbuterin commented Sep 28, 2018 •

edited

Loading

SergioDemianLerner commented Sep 28, 2018 •

edited

Loading

axic commented Sep 29, 2018 •

edited

Loading

holgerd77 commented Sep 29, 2018 •

edited

Loading