EIP-2488 Deprecate the CALLCODE opcode
Hegota Declined for Inclusion · EVM & execution · EIP status Stagnant · created 2019-12-20
A proposal to effectively deprecate the unused early EVM opcode CALLCODE (0xf2) by making it always return failure (0) after the fork block.
Why it is needed
CALLCODE is an EVM opcode that has existed since Ethereum's first release, Frontier. Within weeks to months of launch it became clear that it could not achieve its original design goal, and the problem was corrected in early 2016 when DELEGATECALL (EIP-7) was introduced in the Homestead upgrade. Since then CALLCODE has gone entirely unused, but every EVM implementation still bears the burden of supporting it. This EIP proposes to effectively deprecate CALLCODE by making it always return failure. Clients that aim to sync the full history from genesis see no improvement, but light clients and clients that plan to sync from a later point can reduce their implementation burden.
What changes
Today
- CALLCODE (0xf2) remains in the EVM, so every client has to keep maintaining an implementation
- The opcode is effectively unused, but the implementation burden remains the same
- Light clients also have to support an opcode they never use
After EIP-2488
- After the fork block, CALLCODE always returns 0 (failure)
- The calling contract gets a chance to detect the failure and respond to it
- Light clients and clients that sync from a later point can reduce their implementation burden
Who is affected
- Client teams: Light clients and clients that sync from a later point can reduce their CALLCODE implementation burden. There is no improvement for clients that sync from genesis.
- Contract developer: Contracts that use CALLCODE need to be checked, because calls will always fail after the fork. The author expects that no valuable contracts will be affected.
- Ordinary users: CALLCODE is an effectively unused opcode, so users will notice almost no change.
In depth
Specification: always return 0 after the fork
The specification is one line. If block.number is greater than or equal to FORK_BLOCK, the CALLCODE (0xf2) opcode always returns 0, and this value signals call failure. The concrete FORK_BLOCK value is not set in the original text. Because the opcode itself is not removed, execution does not abort with an exception when it encounters CALLCODE, and the calling contract receives the return value 0, recognizes the failure, and can continue with its next action.
Why return failure instead of removing it
It would also have been possible to remove the opcode entirely and abort execution with an exception when it is encountered. However, returning failure gives the calling contract a chance to look at the result and respond or attempt recovery. This is why the Abstract calls this approach a somewhat backwards-compatible deprecation.
From CALLCODE to DELEGATECALL
CALLCODE was included in the Frontier release, but within the first few weeks to months it became clear that it could not achieve its intended design goal. The problem was corrected in early 2016 with the introduction of DELEGATECALL (EIP-7) in the Homestead update. Since then CALLCODE has gone entirely unused, but it continues to burden EVM implementations.
Who benefits
Clients that aim to sync from genesis must process historical blocks, so this change does not improve their situation. Light clients and clients that plan to sync from a later point do benefit. This means the practical gain from deprecation lies with implementations aiming to be lightweight rather than with full nodes.
Backwards compatibility and incomplete sections
This proposal is a breaking change that alters existing behavior, so it could break contracts. The author expects that no valuable contracts will be affected, but the original text still contains a TODO saying this claim needs to be verified. The Security Considerations, Test Cases, and Implementation sections are all empty, marked TBA (to be announced), so the specification is incomplete.
Document status and fork discussion outcome
The status of this EIP is Stagnant, meaning it has stalled for a long time without progress. It was also not adopted in the fork inclusion discussion. On the 09.10 ACDE #245 call, EIP-2488 was dropped from consideration for Hegota, and it received a unanimous low rating (0.0 to 0.8) from all clients, together with EIP-8219, EIP-8182, and EIP-7645.