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

meowsbits · 2019-02-11T17:53:33Z

Abstract

Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the Byzantium hardfork. The proposed changes include:

Byzantium EVM opcodes and precompiled contracts, namely opcodes REVERT (EIP 206/140), RETURNDATASIZE (EIP 211), RETURNDATACOPY (EIP 211), and STATICCALL (EIP 214/116); and precompiled contracts for modular exponentiation, elliptic curve addition, scalar multiplication, and pairing (EIPs 198, 212/197, 213/196)
Replacing the intermediate state root field in transaction receipts with the contract return status (EIP 658).

This document proposes block X,XXX,XXX as the upcoming block height at which to implement these changes in the network, placing the expected date of protocol hardfork date on XXXX-XX-XX.

ECLIP document rendered view: https://github.com/etclabscore/ECLIPs/blob/55c44609b989781ec198855eabeb347c3fc6f2b6/ECLIPs/ECLIP-etcbyz.md

See here for background comments around this idea: ethereumproject/ECIPs#95. But keep in mind that that proposal specs Constantinople EVM changes as well, while those features of that proposal have been dropped here for reasons.

TODO: Assign a number
TODO: Cooperate w/ other stakeholding dev teams to determine an agreeable timeline
- parity-tech/parity-ethereum
- IOHK (Mantis), deprecated?
- ethereumclassic/go-ethereum
- ~~ethereumproject/go-ethereum~~
- ~~etclabscore/go-ethereum~~
TODO: Internal: define priorities for ethoxy/multi-geth rollout readiness
TODO: Internal: define priorities for evm-rs (SputnikVM) readiness
TODO: Come up w/ a codename for the fork?

Along w/ a few other minor grammatical tweaks

BelfordZ · 2019-02-11T20:14:58Z

how about we switch to calling forks numbers, and start with this one being zero.

:)

meowsbits · 2019-02-11T21:49:54Z

oh i like where your heads at. what about about 2019.1? (first fork this year))

ECLIPs/ECLIP-etcbyz.md

zmitton · 2019-02-12T12:06:01Z

ECLIPs/ECLIP-etcbyz.md

+
+__On Immutability__: Introducing new opcodes in the VM has the potential to change behavior of existing contracts; in the case where previously an arbitrary invalid bytecode series (yielding _invalid opcode_) would now be assigned a meaning, and thus could generate or return a value other than _invalid_. In essence, this means "making music where there was only noise before." There is a concern that this behavior change contradicts an essential promise of Immutability, since an existing failing smart contract is liable to become a succeeding (not failing) contract. In counterargument to this concern are two critical points:
+
+1. account states remain changed


Do you mean "unchanged"? Like this is not a DAO refund scenario?

Otherwise I dont think I follow. Also whats the connection with DELEGATECALL? just the fact that they added an unused opcode?

lol, yeap, __un__changed

and yea, just sayin that there's a precedent for this kind of change, so an argument against this kind of change should have been taken up with vitalik 4 months before the dao fork

zmitton · 2019-02-12T12:10:43Z

ECLIPs/ECLIP-etcbyz.md

+1. account states remain changed
+2. the "Homestead" hardfork established a precedent for this type of change, having introduced the `DELEGATECALL` opcode at block 1,150,000.
+
+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.


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.

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.

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

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.

@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.

ECLIPs/ECLIP-etcbyz.md

Prioritize the actual outcomes of the proposed features, not first the case of interoperability. Rel #2 (comment)

Rel #2 (comment)

Fixes EIP658 name; Tx status code -> receipt status code Co-Authored-By: meowsbits <45600330+meowsbits@users.noreply.github.com>

Prioritize the actual outcomes of the proposed features, not first the case of interoperability. Rel #2 (comment)

Rel #2 (comment)

classiclab

A couple of comments about the stakeholders:
-This will require careful planning and outreach to different members of the ecosystem, and input from bus dev and marketing. Let's address this on a parallel track so that the core team can focus on the code.
-The move to multi-geth is a big change, which will likely generate resistance from some corners of the community. Nevertheless, we will lead the effort. When it comes to ethereumclassic, we don't have a basis for cooperating with them on this project at this stage. They are welcome to follow our lead, but we're not going to be dependent upon them.
-We will have to include ethereumproject, as it is remains the canonical client. I think over time, there will be a way to do this.

ECLIPs/ECLIP-etcbyz.md

BelfordZ · 2019-02-18T22:57:00Z

ECLIPs/ECLIP-etcbyz.md

+__On Immutability__: Introducing new opcodes in the VM has the potential to change behavior of existing contracts; in the case where previously an arbitrary invalid bytecode series (yielding _invalid opcode_) would now be assigned a meaning, and thus could generate or return a value other than _invalid_. In essence, this means "possibly making music where there was only noise before." There is a concern that this behavior change contradicts an essential promise of Immutability, since an existing failing smart contract is liable to become a succeeding (not failing) contract, albeit in a hypothetical case of extreme coincidence and gross misuse of an opcode. In counterargument to this concern are two critical points:
+
+1. account states remain unchanged
+2. the "Homestead" hardfork established a precedent for this type of change, having introduced the `DELEGATECALL` opcode at block 1,150,000.


Suggested change

2. the "Homestead" hardfork established a precedent for this type of change, having introduced the `DELEGATECALL` opcode at block 1,150,000.

2. if a person used one of the unimplemented opcodes originally, the behaviour was undefined. In this right - the immutability property remains since the behaviour will be equally undefined once the op code is implemented.

what if we make another ECLIP and propose that transactions using invalid / unused opcodes are to be deemed invalid transactions and never included in blocks.

ECLIPs/ECLIP-etcbyz.md

BelfordZ · 2019-02-18T23:07:31Z

Great work and thanks @meowsbits for putting this together. Lets build some bridges and slurp in some awesome features long the way :)

BelfordZ · 2019-02-18T23:13:21Z

Assign a number - 6969, naturally.
Come up w/ a codename for the fork? zero

Fixes typo. Co-Authored-By: meowsbits <45600330+meowsbits@users.noreply.github.com>

Makes sentence more assertive. Co-Authored-By: meowsbits <45600330+meowsbits@users.noreply.github.com>

meowsbits · 2019-02-19T13:16:59Z

Just want to give everyone this information that we've found a edge case scenario related to the new EXTCODEHASH opcode that can cause geth, aleth and parity to disagree on consensus execution. This edge case can only be triggered when an empty account is present.

• Because EIP-161 is applied on ETH, no empty account can be present during execution, so it's not an issue for the upcoming Constantinople hard fork.
• However, because EIP-161 is not enabled on ETC, it means that a contract execution can meet an empty account. Therefore, it means that applying EXTCODEHASH alone on ETC is not safe.

So a heads up to everyone -- please do not apply EIP-1052 without EIP-161!

@sorpaas

This will require changes to the ECLIP. Either we'll have to include EIP161 (State Trie Clearing) or remove EIP1052. I would recommend the former.

sorpaas · 2019-02-19T13:53:17Z

@meowsbits Many in ETH community would even admit that EIP-161 is not really a well-defined specification, and it has caused a lot of troubles for Byzantium and Constantinople because of the definition of "empty". So please be careful with this choice.

I would rather advice let's fix the client or the spec to make sure things work without EIP-161. Or let's fix EIP-161 before deploying it on ETC.

YazzyYaz · 2019-02-19T16:05:04Z

Trying to understand, is the plan to support three versions of geth and multi-geth? Or will multi-geth be the main focus? You are referring to the ethereumproject/go-ethereum client so not sure which one is being supported.

Also, for such a major upgrade, it's important to coordinate with Parity and IOHK. Mantis isn't deprecated yet.

BelfordZ · 2019-02-19T22:02:09Z

@sorpaas What problems are we inviting down the road if we deviate from how EIP161 was done?

As nice as it would be to have this HF happen sooner than later, exploring ways of gently upgrading eip161 before proceeding sounds like a good plan to me.

zmitton · 2019-02-20T22:53:56Z

one thing Im confused is why 161 wouldnt be applied on multigeth. If it's in geth woudn't it be in multigeth by default? Unless you and wei activly took it out

meowsbits · 2019-02-21T14:44:37Z

@zmitton the feature exists in multi-geth, it's just whether to enable it

meowsbits · 2019-02-21T15:05:28Z

To summarize, it seems the options are:

Leave out EIP161 and leave out EIP1052.
Leave out EIP161, but fix EIP1052->EIP1052.1 to handle cases when contract execution would meet an "empty" (which w/o EIP161 will not have been removed) account, allowing inclusion of EIP1052.1 in the HF.
Fix EIP161->EIP161.1 to be better defined and include it in the PR as a 'dependency' for EIP1052, which could then be optionally "fixed" -> EIP1052.1 or not.

My humble opinion at this point is that 2 seems the most enticing; EIP161 may be contentious anyways for asymptotic-immutablists since it modifies state.

meowsbits · 2019-02-21T15:08:34Z

lol, wait just a damn second.

This proposal doesn't include EIP1052 or EIP161. EIP1052 is for Constantinople. This prop is for Byzantium-related changes only, leaving this concern for another proposal and another time.

EDIT: I've updated the OP comment to include the document Abstract.

feature: getting started

ghost · 2019-03-05T13:20:34Z

ECLIPs/ECLIP-etcbyz.md

+__On Immutability__: Introducing new opcodes in the VM has the potential to change behavior of existing contracts; in the case where previously an arbitrary invalid bytecode series (yielding _invalid opcode_) would now be assigned a meaning, and thus could generate or return a value other than _invalid_. In essence, this means "possibly making music where there was only noise before." There is a concern that this behavior change contradicts an essential promise of Immutability, since an existing failing smart contract is liable to become a succeeding (not failing) contract, albeit in a hypothetical case of extreme coincidence and gross misuse of an opcode. In counterargument to this concern are two critical points:
+
+1. account states remain unchanged
+2. the "Homestead" hardfork established a precedent for this type of change, having introduced the `DELEGATECALL` opcode at block 1,150,000.


fwiw...i think there is an unavoidable risk that upgrades with hard forks may break some past smart contracts. If this is the case I think that "no hard forks" or "no innovation" isn't a solution either. If there is a "best practices" way for smart contract devs to keep them within a safe boundary that is their responsibility, similar to the responsibility of exchanges of using more confirmations to minimize double spend risks.

Having said that, the goal of ETC devs should still be to minimize such risk in changes and prioritize "backward compatibility" over change just for the sake of change.

Because this is largely subjective, I guess the ECIP (or new starIP) process, and then deployment by node operators and miners, is a good filter to judge that.

eyfl · 2019-03-13T18:06:05Z

should we take EIP100 into account?

soc1c · 2019-03-18T14:25:55Z

ECLIPs/ECLIP-etcbyz.md

+- Byzantium EVM opcodes and precompiled contracts, namely opcodes `REVERT` (EIP 206/140), `RETURNDATASIZE` (EIP 211), `RETURNDATACOPY` (EIP 211), and `STATICCALL` (EIP 214/116); and precompiled contracts for modular exponentiation, elliptic curve addition, scalar multiplication, and pairing (EIPs 198, 212/197, 213/196)
+- Replacing the intermediate state root field in transaction receipts with the contract return status (EIP 658).
+
+This document proposes block `X,XXX,XXX` as the upcoming block height at which to implement these changes in the network, placing the expected date of protocol hardfork date on _XXXX-XX-XX_.


This needs some thought. The release process should allow for a hard-fork on the testnets (Morden, Kotti) at least 4 weeks prior to the mainnet activation. Assuming Byzantium is well tested on Ethereum Foundation network, we can just rephrase this like

Suggested change

This document proposes block `X,XXX,XXX` as the upcoming block height at which to implement these changes in the network, placing the expected date of protocol hardfork date on _XXXX-XX-XX_.

This document proposes blocks:

- `X_XXX_XXX` on Ethereum Classic mainnet

- `X_XXX_XXX` on Morden Classic testnet

- `X_XXX_XXX` on Kotti Classic testnet

Edit: date should not be part of the proposal as it is a moving target naturally.

That said,

Ethereum Classic block 8_750_000 will be around Wed, Sept 18, 2019

Morden Classic block 4_723_000 will be around Wed, Aug 7, 2019

Kotti Classic block 1_039_000 will be around Wed, Aug 7, 2019

@soc1c can you make this as a suggestion? (cmd+g in the comment box)

Edit: date should not be part of the proposal as it is a moving target naturally.

Proposing:

Suggested change

This document proposes block `X,XXX,XXX` as the upcoming block height at which to implement these changes in the network, placing the expected date of protocol hardfork date on _XXXX-XX-XX_.

or?

No. I said date.

meowsbits · 2019-03-18T15:45:55Z

should we take EIP100 into account?

@chunfu-yang We certainly could consider it.

The reason it was not originally included in this spec was because the original impetus for this upgrade set was EVM compatibility, so we had filtered included EIPs according to whether or not they were EVM related.

soc1c · 2019-03-20T12:05:02Z

ECLIPs/ECLIP-etcbyz.md

@@ -0,0 +1,80 @@
+### ECLIP-?: Support for ETH Byzantium EVM and Protocol Upgrades
+
+    ECLIP: undecided


Please make this ECIP-1054 as per #9 (#5)

Suggested change

ECLIP: undecided

ECIP: 1054

soc1c · 2019-03-20T12:19:56Z

ECLIPs/ECLIP-etcbyz.md

+
+### Motivation
+
+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 of a contract. 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).


It's only 4 opcodes right? Also, the first one is not a sentence.

meowsbits · 2019-03-21T13:34:50Z

Has been replaced by #10, moving there instead.

Fix organization

meowsbits added 4 commits February 11, 2019 10:01

Init bare file

cd26a35

Init copy ECIP-1045

d9813d9

Swap ECIP for ECLIP, remove Const. from Header

5448cb5

Remove Constantinople specs and undefine ETA

55c4460

Along w/ a few other minor grammatical tweaks

meowsbits added the help wanted Extra attention is needed label Feb 11, 2019

meowsbits self-assigned this Feb 11, 2019

meowsbits requested review from BelfordZ, classiclab, jakelang, mersinvald, r8d8, shanejonas, sorpaas, stevanlohja, testhound and zmitton February 11, 2019 18:00

zmitton approved these changes Feb 12, 2019

View reviewed changes

meowsbits added a commit that referenced this pull request Feb 12, 2019

Revise motivation section

34634a1

Prioritize the actual outcomes of the proposed features, not first the case of interoperability. Rel #2 (comment)

meowsbits added a commit that referenced this pull request Feb 12, 2019

Fix typo, add note about strangeness of 'unbreaking opcode' case

d935e75

Rel #2 (comment)

meowsbits added a commit that referenced this pull request Feb 12, 2019

Add Rationale conclusion note about feature upgrade

0ea3bc8

Rel #2 (comment)

zmitton and others added 4 commits February 12, 2019 08:49

Update ECLIPs/ECLIP-etcbyz.md

9081155

Fixes EIP658 name; Tx status code -> receipt status code Co-Authored-By: meowsbits <45600330+meowsbits@users.noreply.github.com>

Revise motivation section

b07af65

Prioritize the actual outcomes of the proposed features, not first the case of interoperability. Rel #2 (comment)

Fix typo, add note about strangeness of 'unbreaking opcode' case

9dfa5dc

Rel #2 (comment)

Add Rationale conclusion note about feature upgrade

2108940

Rel #2 (comment)

meowsbits force-pushed the prop/etc-byzantium-upgrade branch from 0ea3bc8 to 2108940 Compare February 12, 2019 14:49

classiclab reviewed Feb 12, 2019

View reviewed changes

stevanlohja added the consensus Touches protocol consensus. label Feb 13, 2019

BelfordZ reviewed Feb 18, 2019

View reviewed changes

ECLIPs/ECLIP-etcbyz.md Outdated Show resolved Hide resolved

BelfordZ reviewed Feb 18, 2019

View reviewed changes

ECLIPs/ECLIP-etcbyz.md Outdated Show resolved Hide resolved

BelfordZ approved these changes Feb 18, 2019

View reviewed changes

BelfordZ and others added 2 commits February 19, 2019 07:06

Update ECLIPs/ECLIP-etcbyz.md

eef2e02

Fixes typo. Co-Authored-By: meowsbits <45600330+meowsbits@users.noreply.github.com>

Update ECLIPs/ECLIP-etcbyz.md

4113214

Makes sentence more assertive. Co-Authored-By: meowsbits <45600330+meowsbits@users.noreply.github.com>

BelfordZ referenced this pull request in BelfordZ/starIPs Mar 2, 2019

Merge pull request #2 from etclabscore/feature/getting-started

9264434

feature: getting started

ghost reviewed Mar 5, 2019

View reviewed changes

meowsbits mentioned this pull request Mar 11, 2019

#2 + EIP1707 Contract-prefixed EVM versioning #6

Closed

soc1c reviewed Mar 18, 2019

View reviewed changes

meowsbits mentioned this pull request Mar 18, 2019

#2 + EIP100: Change difficulty adjustment to target mean block time including uncles #8

Closed

soc1c reviewed Mar 20, 2019

View reviewed changes

r8d8 approved these changes Mar 20, 2019

View reviewed changes

soc1c mentioned this pull request Mar 20, 2019

ECIP-1054: Support for ETH Byzantium EVM and Protocol Upgrades #10

Merged

meowsbits closed this Mar 21, 2019

soc1c pushed a commit that referenced this pull request Oct 24, 2019

Merge pull request #2 from phyro/quickfix-organization

7df3d3c

Fix organization


		__On Immutability__: Introducing new opcodes in the VM has the potential to change behavior of existing contracts; in the case where previously an arbitrary invalid bytecode series (yielding _invalid opcode_) would now be assigned a meaning, and thus could generate or return a value other than _invalid_. In essence, this means "making music where there was only noise before." There is a concern that this behavior change contradicts an essential promise of Immutability, since an existing failing smart contract is liable to become a succeeding (not failing) contract. In counterargument to this concern are two critical points:

		1. account states remain changed

	2. the "Homestead" hardfork established a precedent for this type of change, having introduced the `DELEGATECALL` opcode at block 1,150,000.
	2. if a person used one of the unimplemented opcodes originally, the behaviour was undefined. In this right - the immutability property remains since the behaviour will be equally undefined once the op code is implemented.

-This document proposes block `X,XXX,XXX` as the upcoming block height at which to implement these changes in the network, placing the expected date of protocol hardfork date on _XXXX-XX-XX_.
+This document proposes blocks:
+- `X_XXX_XXX` on Ethereum Classic mainnet
+- `X_XXX_XXX` on Morden Classic testnet
+- `X_XXX_XXX` on Kotti Classic testnet

		@@ -0,0 +1,80 @@
		### ECLIP-?: Support for ETH Byzantium EVM and Protocol Upgrades

		ECLIP: undecided


		### Motivation

		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 of a contract. 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).

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

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

Conversation

meowsbits commented Feb 11, 2019 • edited Loading

Abstract

BelfordZ commented Feb 11, 2019

meowsbits commented Feb 11, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

classiclab left a comment

Choose a reason for hiding this comment

BelfordZ Feb 18, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BelfordZ commented Feb 18, 2019

BelfordZ commented Feb 18, 2019 • edited Loading

meowsbits commented Feb 19, 2019

sorpaas commented Feb 19, 2019 • edited Loading

YazzyYaz commented Feb 19, 2019

BelfordZ commented Feb 19, 2019

zmitton commented Feb 20, 2019

meowsbits commented Feb 21, 2019

meowsbits commented Feb 21, 2019

meowsbits commented Feb 21, 2019 • edited Loading

Choose a reason for hiding this comment

eyfl commented Mar 13, 2019

soc1c Mar 18, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

meowsbits commented Mar 18, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

meowsbits commented Mar 21, 2019

meowsbits commented Feb 11, 2019 •

edited

Loading

BelfordZ Feb 18, 2019 •

edited

Loading

BelfordZ commented Feb 18, 2019 •

edited

Loading

sorpaas commented Feb 19, 2019 •

edited

Loading

meowsbits commented Feb 21, 2019 •

edited

Loading

soc1c Mar 18, 2019 •

edited

Loading