Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add deprecate CALLCODE EIP #2488

Merged
merged 8 commits into from
Aug 29, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 58 additions & 0 deletions EIPS/eip-2488.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
---
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
axic marked this conversation as resolved.
Show resolved Hide resolved

Deprecate `CALLCODE` in a *somewhat* backwards compatible way, by making it always return failure.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Deprecate `CALLCODE` in a *somewhat* backwards compatible way, by making it always return failure.
Deprecate `CALLCODE` (`0xf2`) in a *somewhat* backwards compatible way, by making it always return failure.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this (and other comments) aligns with the new OPCODE referencing systeme that you recently proposed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, after leaving all of these suggestion comments, maybe the intent is that this style is only applied in the Specification section? If so, feel free to reject all of the suggestions that just add the parenthetical callcode.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EIP-1 has this (from #1968):

Screenshot

So it is not super clear. I would be inclined to say mentioning it at the first reference in the Specification is a reasonable option, otherwise it would become annoying.


## Motivation

`CALLCODE` was part of the Frontier release of Ethereum. In the first few weeks/months it became clear
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`CALLCODE` was part of the Frontier release of Ethereum. In the first few weeks/months it became clear
`CALLCODE` (`0xf2`) 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`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
that it cannot accomplish its intended design goal. This was rectified with introducing `DELEGATECALL`
that it cannot accomplish its intended design goal. This was rectified with introducing `DELEGATECALL` (`0xf4`)

([EIP-7](https://eips.ethereum.org/EIPS/eip-7)) in the Homestead update (early 2016).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
([EIP-7](https://eips.ethereum.org/EIPS/eip-7)) in the Homestead update (early 2016).
([EIP-7](./eip-7)) in the Homestead update (early 2016).

Relative paths will make the links work in GitHub, forks, branches, mirrors, etc.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolute paths are the standard required, it has been the case for years.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have been told in the past to use relative paths (I think it was @Arachnid, quite a while back). Perhaps we should discuss this elsewhere, but is there somewhere I can read to catch-up on any history of discussion on this issue?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Over the past 2 years there was an extensive amount of work, mostly by @fulldecent, to change every single link to the absolute. I cannot spend the time right now to dig up the issue numbers.

@Arachnid probably said that probably in 2016-2017. I also preferred the relative paths, but sentiment agreed with the absolute ones.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest this discussion is handled outside of this pull request.


`CALLCODE` became never utilized, but it still puts a burden on EVM implementations.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`CALLCODE` became never utilized, but it still puts a burden on EVM implementations.
`CALLCODE` (`0xf2`) 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/).