mirror of
https://github.com/status-im/EIPs.git
synced 2025-02-23 04:08:09 +00:00
15f61ed0fd
I have gone through and updated all existing EIPs to match this rule, including EIP-1. In some cases, people were using markdown citations, I suspect because the long-form was a bit verbose to inline. Since the relative path is quite short, I moved these to inline but I wouldn't be opposed to putting them back to citation format if that is desired by the authors. In doing the migration/cleanup, I found some EIP references to EIPs that don't actually exist. In these cases I tried to excise the reference from the EIP as best I could. It is worth noting that the Readme actually already had this rule, it just wasn't expressed properly in EIP-1 and the "Citation Format" section of the readme I think caused people a bit of confusion (when citing externally, you should use the citation format).
59 lines
1.6 KiB
Markdown
59 lines
1.6 KiB
Markdown
---
|
|
eip: 2488
|
|
title: Deprecate the CALLCODE opcode
|
|
author: Alex Beregszaszi (@axic)
|
|
discussions-to: https://ethereum-magicians.org/t/eip-2488-deprecate-the-callcode-opcode/3957
|
|
status: Draft
|
|
type: Standards Track
|
|
category: Core
|
|
created: 2019-12-20
|
|
requires: 7
|
|
---
|
|
|
|
## Abstract
|
|
|
|
Deprecate `CALLCODE` in a *somewhat* backwards compatible way, by making it always return failure.
|
|
|
|
## Motivation
|
|
|
|
`CALLCODE` was part of the Frontier release of Ethereum. In the first few weeks/months it became clear
|
|
that it cannot accomplish its intended design goal. This was rectified with introducing `DELEGATECALL`
|
|
([EIP-7](./eip-7.md)) in the Homestead update (early 2016).
|
|
|
|
`CALLCODE` became never utilized, but it still puts a burden on EVM implementations.
|
|
|
|
Disabling it will not improve the situation for any client whose goal is to sync from genesis, but would
|
|
help light clients or clients planning to sync from a later point in time.
|
|
|
|
## Specification
|
|
|
|
If `block.number >= FORK_BLOCK`, the `CALLCODE` (`0xf2`) instruction always returns `0`, which signals failure.
|
|
|
|
## Rationale
|
|
|
|
It would be possible just to remove the opcode and exceptionally abort if it is encountered.
|
|
However, by returning failure, the contract has a chance to act on it and potentially recover.
|
|
|
|
## Backwards Compatibility
|
|
|
|
This is a breaking change and has a potential to break contracts. The author expects no contracts of any value
|
|
should be affected.
|
|
|
|
TODO: validate this claim.
|
|
|
|
## Security Considerations
|
|
|
|
TBA
|
|
|
|
## Test Cases
|
|
|
|
TBA
|
|
|
|
## Implementation
|
|
|
|
TBA
|
|
|
|
## Copyright
|
|
|
|
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|