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

Add Rationale conclusion note about feature upgrade

  • Loading branch information...
meowsbits committed Feb 12, 2019
commit 210894061ebc7d89cb8f6d2877da351bb59ba16d
Copy path View file
@@ -39,6 +39,8 @@ __On Immutability__: Introducing new opcodes in the VM has the potential to chan

With these arguments in place, along with precedence and expectation for other continuing and varied consensus-impacting protocol upgrades (eg soft- and hard-forks), it follows that the definition of Immutability is not extended to guarantee perfect consistency for future _behavior_ of historical account states, but only to only to guarantee the immutability of the account states themselves.

This comment has been minimized.

Copy link
@zmitton

zmitton Feb 12, 2019

Contributor

From a semantic prospective adding an opcode would be classified as a "non-breaking-change". A feature upgrade. Might be worth pointing out. You do a good job of highlighting the cons to your own ECLIP but I think they all have good pro counter arguments.

This comment has been minimized.

Copy link
@sorpaas

sorpaas Mar 4, 2019

Contributor

That's false. Adding an opcode would always be a "breaking change", no matter if you consider old contracts that already contain this opcode, or consider hard fork as a whole.

This comment has been minimized.

Copy link
@zmitton

zmitton Mar 4, 2019

Contributor

It's a hard fork yes. But considering old contracts. This would be a feature upgrade not a major version change (i.e 0.1.0 not 1.0.0). Any new feature of software will always technically change behavior. But it's only when you look at extreme, un-supported, ways of using it.

Thats even true with the versioning proposal. Adding a 00 byte in front of a contract had a behavior before, it will have a different behavior now

This comment has been minimized.

Copy link
@sorpaas

sorpaas Mar 4, 2019

Contributor

Using semantic versioning to consider something as fragile as consensus upgrade is totally unhealthy. Ethereum community's experience tells us that we must consider all upgrades as breaking, regardless how small or how big you think it is. On top of that, we consider what invariant we want to preserve, and what doesn't matter. Otherwise it can easily bring in disaster. You need to especially look out for "extreme, un-supported, ways of using it" and consider them to make sure everything's okay.

Thats even true with the versioning proposal. Adding a 00 byte in front of a contract had a behavior before, it will have a different behavior now

Sure, but do I miss some points you try to claim? Account versioning would of course be a breaking change.

This comment has been minimized.

Copy link
@zmitton

zmitton Mar 5, 2019

Contributor

@sorpaas I'm all for being careful 👍. Im just saying that adding useful opcodes likely does not break any intended contract behavior. But I agree that as with any major changes, we should tread lightly and test well.


Adding opcodes and precompiled contracts to the EVM increases its functionality (only in an extremely rare case of gross misuse would be seen to _change_ it's functionality), and should be considered a feature upgrade rather than a modification.

### Implementation

Adoption of the content of this ECLIP requires a hard fork, and herein that adoption is proposed to be scheduled for block X,XXX,XXX roughly estimated to arrive _XXXX-XX-XX_.
ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.