⚠️ Draft Standards Track: Core

EIP-7676: EOF - Prepare for Address Space Extension

Update EOF opcodes so addresses are not trimmed during execution

Authors	Danno Ferrin (@shemnon)
Created	2024-04-03
Discussion Link	https://ethereum-magicians.org/t/eof-prepare-for-address-space-extension/19537
Requires	EIP-3540, EIP-3670, EIP-7069

Abstract
Motivation
Specification
Rationale
Backwards Compatibility
Test Cases
Reference Implementation
Security Considerations
Copyright

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. 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. 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.

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

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

Citation

Please cite this document as:

Danno Ferrin (@shemnon), "EIP-7676: EOF - Prepare for Address Space Extension [DRAFT]," Ethereum Improvement Proposals, no. 7676, April 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7676.