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
Copy path View file
@@ -0,0 +1,77 @@
### ECLIP-?: Support for ETH Byzantium EVM and Protocol Upgrades

ECLIP: undecided

This comment has been minimized.

Copy link
@soc1c

soc1c Mar 20, 2019

Contributor

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

Suggested change
ECLIP: undecided
ECIP: 1054
Title: Support for ETH Byzantium EVM and Protocol Upgrades
Status: Draft
Type: Standards Track
Author: Isaac Ardis <isaac.a@etclabs.org>
Created: 2019-02-11

### 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_.

This comment has been minimized.

Copy link
@soc1c

soc1c Mar 18, 2019

Contributor

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.

This comment has been minimized.

Copy link
@soc1c

soc1c Mar 18, 2019

Contributor

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

This comment has been minimized.

Copy link
@BelfordZ

BelfordZ Mar 18, 2019

Member

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

This comment has been minimized.

Copy link
@soc1c

soc1c Mar 19, 2019

Contributor

Done.

This comment has been minimized.

Copy link
@meowsbits

meowsbits Mar 19, 2019

Author Member

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?

This comment has been minimized.

Copy link
@soc1c

soc1c Mar 19, 2019

Contributor

No. I said date.


For more information on the opcodes and their respective EIPs and implementations, please see the __History__ section of this document.

### 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.
This conversation was marked as resolved by zmitton

This comment has been minimized.

Copy link
@zmitton

zmitton Feb 12, 2019

Contributor

To enable and maintain interoperability between Foundation and Classic Ethereum Virtual Machines ("EVM"s)

Copying the EF is not the strongest arg. might not sit well with the separatists

I'd start with the primary reason:
"To enhance the EVM's capabilities and ..."

and then maybe "make a wider array of existing Ethereum tooling compatible"

This comment has been minimized.

Copy link
@meowsbits

meowsbits Feb 12, 2019

Author Member

Yep, good point. Will do.


### Specification

As per associated EIPs's specifications and implementations, with feature-readiness determined by interoperability (implementation) of smart contracts utilizing the introduced opcode and precompiled contracts (implementation before technical specification in case of discrepency). Technical specifications for each EIP can be found at those documents respectively.

### Rationale

__Interoperability__: establishing and maintaining interoperable behavior between Ethereum clients is important for developers and end-user adoption, yielding benefits for all participating chains (eg. ETH and ETC).

__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:
This conversation was marked as resolved by zmitton

This comment has been minimized.

Copy link
@zmitton

zmitton Feb 12, 2019

Contributor

since an existing failing smart contract is liable to become a succeeding (not failing) contract

By extreme coincidence / gross previous misuse of opcode?

This comment has been minimized.

Copy link
@meowsbits

meowsbits Feb 12, 2019

Author Member

Yep.


1. account states remain changed

This comment has been minimized.

Copy link
@zmitton

zmitton Feb 12, 2019

Contributor

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?

This comment has been minimized.

Copy link
@meowsbits

meowsbits Feb 12, 2019

Author Member

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

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

This comment has been minimized.

Copy link
@BelfordZ

BelfordZ Feb 18, 2019

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

This comment has been minimized.

Copy link
@BelfordZ

BelfordZ Feb 18, 2019

Member

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.

This comment has been minimized.

Copy link
@DonaldMcIntyre

DonaldMcIntyre Mar 5, 2019

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.


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.


### 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_.

The `ethereumproject/go-ethereum` client implemented an API-only (non-consensus impacting) partial adoption of EIP-658 Transaction status code change via the [v5.5.0](https://github.com/ethereumproject/go-ethereum/releases/tag/v5.5.0) release, and this proposal would augment that change to extend through to the RLP encoding (and thus modify consensus protocol).
This conversation was marked as resolved by meowsbits

This comment has been minimized.

Copy link
@zmitton

zmitton Feb 12, 2019

Contributor
Suggested change
The `ethereumproject/go-ethereum` client implemented an API-only (non-consensus impacting) partial adoption of EIP-658 Transaction status code change via the [v5.5.0](https://github.com/ethereumproject/go-ethereum/releases/tag/v5.5.0) release, and this proposal would augment that change to extend through to the RLP encoding (and thus modify consensus protocol).
The `ethereumproject/go-ethereum` client implemented an API-only (non-consensus impacting) partial adoption of EIP-658 receipt status code change via the [v5.5.0](https://github.com/ethereumproject/go-ethereum/releases/tag/v5.5.0) release, and this proposal would augment that change to extend through to the RLP encoding (and thus modify consensus protocol).

ETC Labs Core plans to advocate and support the adoption of [ethoxy/multi-geth](https://github.com/ethoxy/multi-geth) as a fully-featured and maintenance-scheduled client for this fork and beyond.
This conversation was marked as resolved by meowsbits

This comment has been minimized.

Copy link
@BelfordZ

BelfordZ Feb 18, 2019

Member
Suggested change
ETC Labs Core plans to advocate and support the adoption of [ethoxy/multi-geth](https://github.com/ethoxy/multi-geth) as a fully-featured and maintenance-scheduled client for this fork and beyond.
ETC Labs Core advocates and supports the adoption of [ethoxy/multi-geth](https://github.com/ethoxy/multi-geth) as a fully-featured and maintenance-scheduled client for this fork and beyond.

### History

##### Byzantium changes

These changes were introduced in the `ethereum/go-ethereum` client via the [1.7 "Megara" release](https://github.com/ethereum/go-ethereum/releases/tag/v1.7.0).

These changes are catalogued via the EIP process in the following:

- EIP-658: Transaction receipts embedding status code instead of intermediate state root field - https://github.com/ethereum/EIPs/pull/658/files

- EIP-140: `REVERT` - https://github.com/ethereum/EIPs/pull/206/files

> The `REVERT` instruction provides a way to stop execution and revert state changes, without consuming all provided gas and with the ability to return a reason.

- EIP-211: `RETURNDATASIZE`, `RETURNDATACOPY` - https://github.com/ethereum/EIPs/pull/211/files

> A mechanism to allow returning arbitrary-length data inside the EVM has been requested for quite a while now. Existing proposals always had very intricate problems associated with charging gas. This proposal solves the same problem while at the same time, it has a very simple gas charging mechanism and requires minimal changes to the call opcodes. Its workings are very similar to the way calldata is handled already; after a call, return data is kept inside a virtual buffer from which the caller can copy it (or parts thereof) into memory. At the next call, the buffer is overwritten. This mechanism is 100% backwards compatible.

- EIP-214: `STATICCALL` - https://github.com/ethereum/EIPs/pull/214/files

> To increase smart contract security, this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present).
- EIP-198: Precompiled contract for modular exponentiation - https://github.com/ethereum/EIPs/pull/198/files

- EIP-212: Precompiled contract for elliptic curve pairing - https://github.com/ethereum/EIPs/pull/212/files

- EIP-213: Precompiled contracts for elliptic curve addition and scalar multiplication - https://github.com/ethereum/EIPs/pull/213/files

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