mirror of https://github.com/status-im/EIPs.git
fix reviewer comments
This commit is contained in:
parent
0e1a240f04
commit
53c72c6f13
|
@ -10,7 +10,9 @@ 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. The `salt` is a 32-byte stack item.
|
||||
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` 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.
|
||||
|
||||
|
@ -24,7 +26,6 @@ Allows interactions to (actually or counterfactually in channels) be made with a
|
|||
* 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.
|
||||
|
||||
### Clarifications
|
||||
|
||||
|
@ -49,13 +50,13 @@ It should also be noted that `SELFDESTRUCT` has no immediate effect on `nonce` o
|
|||
Example 0
|
||||
* address `0x0000000000000000000000000000000000000000`
|
||||
* salt `0x0000000000000000000000000000000000000000000000000000000000000000`
|
||||
* code `0x00`
|
||||
* init_code `0x00`
|
||||
* result: `0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38`
|
||||
|
||||
Example 1
|
||||
* address `0xdeadbeef00000000000000000000000000000000`
|
||||
* salt `0x0000000000000000000000000000000000000000000000000000000000000000`
|
||||
* code `0x00`
|
||||
* init_code `0x00`
|
||||
* result: `0xB928f69Bb1D91Cd65274e3c79d8986362984fDA3`
|
||||
|
||||
Example 2
|
||||
|
@ -67,23 +68,23 @@ Example 2
|
|||
Example 3
|
||||
* address `0x0000000000000000000000000000000000000000`
|
||||
* salt `0x0000000000000000000000000000000000000000000000000000000000000000`
|
||||
* code `0xdeadbeef`
|
||||
* init_code `0xdeadbeef`
|
||||
* result: `0x70f2b2914A2a4b783FaEFb75f459A580616Fcb5e`
|
||||
|
||||
Example 4
|
||||
* address `0x00000000000000000000000000000000deadbeef`
|
||||
* salt `0x00000000000000000000000000000000000000000000000000000000cafebabe`
|
||||
* code `0xdeadbeef`
|
||||
* init_code `0xdeadbeef`
|
||||
* result: `0x60f3f640a8508fC6a86d45DF051962668E1e8AC7`
|
||||
|
||||
Example 5
|
||||
* address `0x00000000000000000000000000000000deadbeef`
|
||||
* salt `0x00000000000000000000000000000000000000000000000000000000cafebabe`
|
||||
* code `0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef`
|
||||
* init_code `0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef`
|
||||
* result: `0x1d8bfDC5D46DC4f61D6b6115972536eBE6A8854C`
|
||||
|
||||
Example 6
|
||||
* address `0x0000000000000000000000000000000000000000`
|
||||
* salt `0x0000000000000000000000000000000000000000000000000000000000000000`
|
||||
* code `0x`
|
||||
* init_code `0x`
|
||||
* result: `0xE33C0C7F7df4809055C3ebA6c09CFe4BaF1BD9e0`
|
||||
|
|
Loading…
Reference in New Issue