EXTCODEHASH opcode
EIP-1052 proposes a new opcode, EXTCODEHASH, which returns the keccak256 hash of a contract's bytecode. This opcode is useful for contracts that need to perform checks on a contract's bytecode but do not necessarily need the bytecode itself. For instance, a contract may want to check if another contract's bytecode is one of a set of permitted implementations or perform analyses on code and whitelist any contract with matching bytecode if the analysis passes.
The EXTCODEHASH opcode 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 or is empty, 0 is pushed to the stack. In case the account does not have code, the keccak256 hash of empty data is pushed to the stack. The gas cost of the EXTCODEHASH is 400, which 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.
The EXTCODEHASH opcode distinguishes accounts without code and non-existing accounts, which is consistent with the way accounts are represented in the state trie. This also allows smart contracts to check whether an account exists. There are no backwards compatibility concerns with this opcode. Test cases are provided to ensure the correct implementation of the opcode. The implementation of the opcode is yet to be determined.
Video
Original
Abstract
This EIP specifies a new opcode, which returns the keccak256 hash of a contract's code.
Motivation
Many contracts need to perform checks on a contract's bytecode, but do not necessarily need the bytecode itself. For instance, a contract may want to check if another contract's bytecode is one of a set of permitted implementations, or it may perform analyses on code and whitelist any contract with matching bytecode if the analysis passes.
Contracts can presently do this using the EXTCODECOPY
(0x3c
) 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 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 or is empty (as defined by EIP-161) 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.
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
(0x31
), EXTCODESIZE
(0x3b
) and
EXTCODECOPY
(0x3c
).
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
- The
EXTCODEHASH
of the account without code isc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470
what is the keccack256 hash of empty data. - The
EXTCODEHASH
of non-existent account is0
. - The
EXTCODEHASH
of an precompiled contract is eitherc5d246...
or0
. - If
EXTCODEHASH
ofA
isX
, thenEXTCODEHASH
ofA + 2**160
isX
. - The
EXTCODEHASH
of an account that selfdestructed in the current transaction. - The
EXTCODEHASH
of an account that selfdestructed and later the selfdestruct has been reverted. - The
EXTCODEHASH
of an account created in the current transaction. - The
EXTCODEHASH
of an account that has been newly created and later the creation has been reverted. - The
EXTCODEHASH
of an account that firstly does not exist and later is empty. - The
EXTCODEHASH
of an empty account that is going to be cleared by the state clearing rule.
Implementation
TBD
Copyright
Copyright and related rights waived via CC0.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all