From 6a0a792731c16d92d56e0525dd0abff7b498d7b7 Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Fri, 26 Apr 2024 10:54:56 -0600 Subject: [PATCH] Add EIP: EOF - Prepare for Address Space Extension Merged by EIP-Bot. --- EIPS/eip-7676.md | 120 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 EIPS/eip-7676.md diff --git a/EIPS/eip-7676.md b/EIPS/eip-7676.md new file mode 100644 index 0000000000000..6638d1a105c36 --- /dev/null +++ b/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 + +## 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).