Automatically merged updates to draft EIP(s) 1052

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Paweł Bylica 2018-07-18 14:04:42 +02:00 committed by EIP Automerge Bot
parent 485b14afc8
commit 4746d22b07

View File

@ -1,7 +1,7 @@
---
eip: 1052
title: EXTCODEHASH opcode
author: Nick Johnson <arachnid@notdot.net>
author: Nick Johnson <arachnid@notdot.net>, Paweł Bylica <pawel@ethereum.org>
discussions-to: https://ethereum-magicians.org/t/extcodehash-opcode/262
status: Draft
type: Standards Track
@ -18,16 +18,57 @@ Many contracts need to perform checks on a contract's bytecode, but do not neces
Contracts can presently do this using the `EXTCODECOPY` opcode, but this is expensive, especially for large contracts, in cases where only the hash is required. As a result, we propose a new opcode, `EXTCODEHASH`, which returns the keccak256 hash of a contract's bytecode.
## Specification
A new opcode, `EXTCODEHASH`, is introduced, with number 0x3D. `EXTCODEHASH` takes one argument from the stack, and pushes the keccak256 hash of the code at that address to the stack.
A new opcode, `EXTCODEHASH`, is introduced, with number 0x3D. 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.
In case the account does not have code the keccak256 hash of empty data
(i.e. `c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`)
is pushed to the stack.
The gas cost of the `EXTCODEHASH` is 400.
## Rationale
As described in the motivation section, this opcode is widely useful, and saves on wasted gas in many cases.
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
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
`EXTCODECOPY`.
The `EXTCODEHASH` distincts accounts without code and non-existing accounts.
This is consistent with the way accounts are represented in the state trie.
This also allows smart contracts to check whenever an account exists.
## Backwards Compatibility
There are no backwards compatibility concerns.
## Test Cases
TBD
1. The `EXTCODEHASH` of the account without code is `c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`
what is the keccack256 hash of empty data.
2. The `EXTCODEHASH` of non-existent account is `0`.
3. The `EXTCODEHASH` of an precompiled contract is either `c5d246...` or `0`.
4. If `EXTCODEHASH` of `A` is `X`, then `EXTCODEHASH` of `A + 2**160` is `X`.
5. The `EXTCODEHASH` of an account that selfdestructed in the current transaction.
6. The `EXTCODEHASH` of an account that selfdestructed and later the selfdestruct has been reverted.
7. The `EXTCODEHASH` of an account created in the current transaction.
8. The `EXTCODEHASH` of an account that has been newly create and later the creation has been reverted.
9. The `EXTCODEHASH` of an account that firstly does not exist and later is empty.
10. The `EXTCODEHASH` of an empty account that is going to be cleared by the state clearing rule.
## Implementation
TBD