Update EIP-7784: Move to Review

Merged by EIP-Bot.

EIPS/eip-7784.md

@@ -1,24 +1,22 @@
 ---
 eip: 7784
 title: GETCONTRACT opcode
-description: Global byte code accessing by it's hash
+description: Global byte code accessing by its hash
 author: Tim Pechersky (@peersky)
 discussions-to: https://ethereum-magicians.org/t/eip-7784-getcontract-code/21325
-status: Draft
+status: Review
 type: Standards Track
 category: Core
 created: 2024-10-07
 ---
 
 ## Abstract
 
-Initially proposed in erc track, this EIP is now moved to core track, discussion kept in the same thread as they are related and can be seen as exclusive.
-
-This is a proposal to add a new opcode, `GETCONTRACT`. The `GETCONTRACT` opcode would return the address containing the bytecode by it's hash.
+This is a proposal to add a new opcode, `GETCONTRACT`. The `GETCONTRACT` opcode would return the address containing the bytecode by its hash.
 
 ## Motivation
 
-Content addressing by it's hash is a common pattern in database design. It allows to store and retrieve data by it's unique footprint in the storage. This pattern is widely used in the industry and it allows to abstract from actual storage location and allows to reuse the same bytecode in multiple contracts.
+Content addressing by hash is a common pattern in database design. It allows to store and retrieve data by its unique footprint in the storage. This pattern is widely used in the industry and it allows abstracting the actual storage location and allows reusing the same bytecode in multiple contracts.
 
 Today, existing contract discovery relies on addresses, which are non-deterministic and can be obfuscated through proxies. Indexing by bytecode hash provides a deterministic and tamper-proof way to identify and verify contract code, enhancing security and trust in the Ethereum ecosystem.
 
@@ -30,7 +28,7 @@ For developers relying on extensive code reuse, bytecode referencing protects ag
 
 For decentralized application (dApp) developers, a code index can save gas costs by allowing them to reference existing codebase instead of redeploying them, optimizing resource usage. This can be useful for dApps that rely on extensive re-use of same codebase as own dependencies.
 
-This also allows to build new core standards more conveniently, for example, [EIP-7702](./eip-7702) can use it as dependency, to allow users who want to set up one-time code on their EOAs by referring to `GETCONTRACT` instead of uploading the code itself or having to figure out where was the required code deployed.
+This also allows to build new core standards more conveniently, for example, [EIP-7702](./eip-7702) can use it as dependency, to allow users who want to set up one-time code on their EOAs by referring to `GETCONTRACT` instead of specifying potentially mutable address based functionality.
 
 ## Specification
 
@@ -42,11 +40,15 @@ This also allows to build new core standards more conveniently, for example, [EI
     * `codehash`: A single 32-byte code hash from the stack.
 * **Output:**
     * `address`:  If the `codehash` exists in the state, pushes the corresponding contract address onto the stack. Otherwise, pushes 0.
-* **Gas Cost:** ?? (TBD)
+* **Gas Cost:** 150
 * **Stack Effects:** Pops 1 item, pushes 1 item.
 * **Error Handling:**  If the `codehash` is invalid or the bytecode retrieval encounters an error, the instruction will revert.
 
-Every contract stored in EVM MUST be added to the state trie with the key being the keccak256 hash of the contract's bytecode, provided it is not already present and the contract did not invoke the `SELFDESTRUCT` opcode.
+Every contract stored in EVM MUST be added to the state trie with the key being the keccak256 hash of the contract's bytecode, provided it is:
+
+* not already present
+* The contract did not invoke the `SELFDESTRUCT` opcode.
+* The `EXTCODEHASH` return value IS NOT `0xeadcdba66a79ab5dce91622d1d75c8cff5cff0b96944c3bf1072cd08ce018329` (`keccak256(0xef01)`)
 
 
 ### Example Usage
@@ -65,16 +67,20 @@ function getContractAddress(bytes32 codehash) public view returns (address) {
 
 **Bytecode over Addresses**: Bytecode is deterministic and can be verified on-chain, while addresses are opaque and mutable.
 
-**EIP not ERC**: This EIP is proposed as a core standard, as it enables global index by default, abstracts developers from need to maintain the index, and can be used as a dependency for other EIPs.
-
 **Do not re-index**: There is small, yet non-zero probability of hash collision attack. Disallowing updates to indexed location of bytecode coupes with this.
 
+**Gas cost**: This operation is more complex than simple data retrieval, however lookup in the database by hash generally is simpler in complexity.
+
 ## Security Considerations
 
 **Malicious Code**: The index does NOT guarantee the safety or functionality of indexed contracts. Users MUST exercise caution and perform their own due diligence before interacting with indexed contracts.
 
 **Storage contents of registered contracts**: The index only refers to the bytecode of the contract, not the storage contents. This means that the contract state is not indexed and may change over time.
 
+**[EIP-7702](./eip-7702) delegation:** Temporary code delegation is disallowed to prevent case of registering a code hash that becomes unavailable. Standard explicitly disallows contracts with bytecode delegated via [EIP-7702](./eip-7702) from being indexed.
+
+**SELFDESTRUCT**: Contracts that `selfdestruct` are not indexed, as they will not have a codehash in the state trie.
+
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).