Add EIP: EOF - Prepare for Address Space Extension

Merged by EIP-Bot.

EIPS/eip-7676.md

@@ -0,0 +1,120 @@
+---
+eip: 7676
+title: EOF - Prepare for Address Space Extension
+description: Update EOF opcodes so addresses are not trimmed during execution
+author: Danno Ferrin (@shemnon)
+discussions-to: https://ethereum-magicians.org/t/eof-prepare-for-address-space-extension/19537
+status: Draft
+type: Standards Track
+category: Core
+created: 2024-04-03
+requires: 3540, 3670, 7069
+---
+
+## Abstract
+
+Operations in the Legacy EVM trim off the top 12 bytes of an address operand before evaluation. This
+EIP changes the handling of those opcodes within EOF so that no trimming occurs and the top twelve
+bytes need to be zero or an exceptional halt is raised.
+
+## Motivation
+
+There have been proposals to extend Ethereum Addresses from 160 bits to 256, such as one that would
+use the extra bits for state expiry (such as the ethereum magicians forum topic "Increasing the
+address size from 20 to 32 bytes"). One issue ground the work to a halt: EVM opcodes that accept
+addresses trim all but the lowest 20 bytes out from the operand before processing. EVM Reference
+tests verify this behavior in the 'stBadOpcode/invalidAddr.json' tests.
+
+The EVM Object Format presents an opportunity to remove this address masking in a backwards
+compatible way, by baking it into the format definition from the start.
+
+Most of the work is already in place. The following 5 operations have already been banned from
+EOF: `EXTCODESIZE`, `EXTCODECOPY`, `EXTCODEHASH`, `CALLCODE`, and `SELFDESTRUCT`. Three call
+operations, `CALL`, `DELEGATECALL`, and `STATICCALL` are being revamped
+in [EIP-7069](./eip-7069.md). That leaves only one operation, `BALANCE`, with issues.
+
+When future uses of address space extension are specified it is expected that the exceptional halt
+behavior will be modified.
+
+## Specification
+
+We introduce one new instruction:
+
+- `EXTBALANCE` (`tbd`) with arguments `(target_address)`, returning `balance`
+
+`EXTBALANCE` will pop one stack item off of the stack, the address of another account or contract.
+The balance of that account or contract will be pushed onto the stack.
+
+If `EXTBALANCE` is invoked with any of the high 12 bytes in `target_address` set to a non-zero value
+the operation will cause an exceptional halt. All gas in the current frame will be consumed on
+failure, no gas schedule change is needed.
+
+The gas cost of `EXTBALANCE` will be costed according to the gas schedule for the `BALANCE`
+oepration specified in [EIP-2929](./eip-2929.md). This means if the account is not
+in `accessed_addresses` then it is charged 2600 gas and added to `accessed_addresses`. If the
+account is in `accessed_addresses` then 100 gas is charged. The `accessed_addresses` is shared with
+all other operands described in [EIP-2929](./eip-2929).
+
+Also, for the `EXTCALL`, `EXTDELEGATECALL`, and `EXTSTATICCALL` operations a new step is added just
+before the memory expansion check: halt with exceptional failure if any of the high 96 bits of
+the `target_address` are set.
+
+It is anticipated that future EIPs will alter the behavior in a way that will not result in an
+exceptional halt. Contract implementors should not depend on the exceptional halt.
+
+## Rationale
+
+### New Opcode
+
+There is no need to ban the `BALANCE` opcode as it does not cause any problems that would require
+banning it within an EOF container. Adding a new opcode also allows the existing opcode to behave
+the same in EOF and legacy code, reducing potential friction points for end user confusion and bugs.
+
+### Revert on invalid address
+
+There are two alternative ways to handle accounts with high bits set. The specification calls for
+an exceptional halt, but the alternative was to treat the account as empty. The reason the "empty
+account" approach was rejected is twofold:
+
+- The `accessed_addresses` list could be required to track 256 bit accounts when an invalid address
+  is accessed.
+- The `EXTCALL` series instructions could still send balance to those addresses and such accounts
+  would then hold an (inaccessible) balance that would need to be reflected in the merkle trie.
+
+### No change in gas costing
+
+Because the BALANCE operation already needs to check `accessed_addresses` there is already a good
+amount of processing that must go into the operation. Hence, no changes to the gas schedule are
+needed to prevent abuse of the failures. Such incremental costs will be dominated by costs related
+to reverts and address checking for valid accounts.
+
+## Backwards Compatibility
+
+Preparing for Address Space Expansion is explicitly done inside the scope of EOF with the intent
+that it will not require changes in old contracts, but with the caveat that old contracts may not be
+able to use addresses in the expanded space.
+
+Future EIPs should be mindful when adding new operation with an address operand or parameter to how
+it interacts with EOF and legacy contracts. Authors should ensure that such additions remain in
+harmony with this EIP.
+
+## Test Cases
+
+Test cases similar to `invalidAddr.json`  tests in the standard reference tests will need to be
+written for the EOF tests, except they would check for halts on invalid addresses.
+
+## Reference Implementation
+
+TBD <!-- TODO -->
+
+## Security Considerations
+
+This EIP only defines a revert behavior for previously stripped addresses. Compilers will need to be
+aware of the need to mask addresses coming in from call data. Some of this is already present in
+existing Solidity ABI standards, but more care should be taken in examining the flow
+around `EXTBALANCE` and code for `EXTCALL` operations to ensure that compiled code strips the high
+bytes.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).