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.
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.
We introduce one new instruction:
EXTBALANCE (tbd) with arguments (target_address), returning balanceEXTBALANCE 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
operation 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.
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.
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:
accessed_addresses list could be required to track 256 bit accounts when an invalid address
is accessed.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 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.
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 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.
TBD
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 and related rights waived via CC0.