Add EIP: EOF - Prepare for Address Space Extension

EIPS/eip-7676.md

@@ -0,0 +1,99 @@
+---
+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 ethereum magicians forum topic "Increasing the address
+size from 20 to 32 bytes"). One issue ground this 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`, to be changed.
+
+When future uses of address space extension are specified it is expected that the exceptional halt
+behavior will be modified.
+
+## Specification
+
+The `BALANCE` operation, when invoked in code in an EOF container, will require the top 12 bytes of
+the operand to be zero.
+
+If `BALANCE` is invoked with any of the high 12 bytes 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.
+
+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.
+
+
+
+## Rationale
+
+There are two alternative ways to handle accounts with high bits set. The specification calls for
+exceptional halt, but the alternative was to treat the account as empty. The reason the "empty
+account" approach was rejected is twofold: 
+
+* The warm account 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.
+
+Because the BALANCE operation already needs to check the warmed account list there is already a good
+amount of processing that must go into the operation, so no change 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. If an existing operation is un-banned in EOF, it is recommended that a change
+similar to the changes specified to `BALANCE` are also applied to the operations.
+
+## 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
+
+## 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 `BALANCE`
+and code for `EXTCALL` operations to ensure that compiled code strips the high bytes.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).