forked from ethereum/EIPs
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add EIP: EOF - Prepare for Address Space Extension
Merged by EIP-Bot.
- Loading branch information
Showing
1 changed file
with
120 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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 <!-- TODO --> | ||
|
||
## 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). |