Add EIP: EOF - Prepare for Address Space Extension

EIPS/eip-7069.md

@@ -63,21 +63,22 @@ Execution semantics of `EXT*CALL`:
 3. If `value` is non-zero:
     - Halt with exceptional failure if the current frame is in `static-mode`.
     - Charge `CALL_VALUE_COST` gas.
-4. Peform (and charge for) memory expansion using `[input_offset, input_size]`.
-5. If `target_address` is not in the `warm_account_list`, charge `COLD_ACCOUNT_ACCESS - WARM_STORAGE_READ_COST` (2500) gas.
-6. If `target_address` is not in the state and the call configuration would result in account creation, charge `ACCOUNT_CREATION_COST` (25000) gas.
+4. Halt with exception if any of the high 96 bits of the `target_address` are set.
+5. Perform (and charge for) memory expansion using `[input_offset, input_size]`.
+6. If `target_address` is not in the `warm_account_list`, charge `COLD_ACCOUNT_ACCESS - WARM_STORAGE_READ_COST` (2500) gas.
+7. If `target_address` is not in the state and the call configuration would result in account creation, charge `ACCOUNT_CREATION_COST` (25000) gas.
     - The only such case in this EIP is if `value` is non-zero.
-7. Calculate the gas available to callee as caller's remaining gas reduced by `max(floor(gas/64), MIN_RETAINED_GAS)`.
-8. Fail with status code `1` returned on stack if any of the following is true (only gas charged until this point is consumed):
+8. Calculate the gas available to callee as caller's remaining gas reduced by `max(floor(gas/64), MIN_RETAINED_GAS)`.
+9. Fail with status code `1` returned on stack if any of the following is true (only gas charged until this point is consumed):
     - Gas available to callee at this point is less than `MIN_CALLEE_GAS`.
     - Balance of the current account is less than `value`.
     - Current call stack depth equals `1024`.
-11. Perform the call with the available gas and configuration.
-12. Push a status code on the stack:
+10. Perform the call with the available gas and configuration.
+11. Push a status code on the stack:
     - `0` if the call was successful.
     - `1` if the call has reverted (also can be pushed earlier in a light failure scenario).
     - `2` if the call has failed.
-13. Gas not used by the callee is returned to the caller.
+12. Gas not used by the callee is returned to the caller.
 
 Execution semantics of `RETURNDATALOAD`:
 

EIPS/eip-ase.md

@@ -0,0 +1,89 @@
+---
+eip: TBD
+title: EOF - Prepare for Address Space Extension
+description: Update EOF opcodes so addresses are not trimmed durring 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 propsals to extend Ethereum Addresses from 160 bytes to 256, such as one that would
+use the extra bits for state expiry (such ethereum magicians fourm topic "Increasing the addres
+sisze 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 fo the operand before processing. EVM Reference tests verify
+this behavior in the 'stBadOpcode/invalidAddr.json' tests.
+
+The EVM Object Framework 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 exeptional halt
+behavior will be modified.
+
+## Specification
+
+The `BALANCE` operation, when invoked in code in an EOF container, will reauire 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.
+
+Any new operation with an address operand on the stack, or any operation that is un-banned from EOF
+that has an address operand on the stack will have the same behavior as `BALANCE` when validating
+the address operand.
+
+## 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: first the warm account list could be required to track
+256 bit accounts when an invalid address is accessed. Second, the `EXTCALL` series instructions
+could still send balance to those addresses and such accounts would then hold an (inaccessble)
+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
+
+Only one operation shared between legacy and EOF is impacted. All other impacted operations are used
+in only one mode.
+
+## 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).