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

ECLIP-?: Byzantium EVM upgrades (and Tx Receipt status) #2

Closed
wants to merge 10 commits into from

Revise motivation section

Prioritize the actual outcomes of the proposed features, not
first the case of interoperability.

Rel #2 (comment)
  • Loading branch information...
meowsbits committed Feb 12, 2019
commit b07af653d3054004c35864ad5ea6ef4bcbfcc541
Copy path View file
Copy path View file
@@ -20,7 +20,9 @@ For more information on the opcodes and their respective EIPs and implementation

### Motivation

To enable and maintain interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s). This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepencies.
To enhance the EVM's capabilities by adding 5 opcodes and 4 precompiled contracts, all of which have been in use on the ETH network since 2017-10-16. Adoption of the "receipt status" feature provides a helpful method for Dapp developers to access the successful or failed state a contact. This would (re)establish a greater level of interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s), and make a wider array of tooling available for the ETC network (eg. Solidity version, several contract debugging tools).

This protocol specification notably omits the scheduled features of the anticipated _Constantinople_ fork, which would be expected to include various further EVM upgrades. The reasoning for this omission hinges on a hedge toward battle-testing of those changes in light of multiple delays of that fork ([here](https://medium.com/ethereum-cat-herders/a-post-mortem-report-the-constantinople-ethereum-hard-fork-postponement-dd780d7ae63d), a postmortem of the latest delay) due to security and implementation discrepencies.

### Specification

ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.