ECIP 1079: Phoenix EVM and Protocol Upgrades ("Aztlán redo") Source

AuthorBob Summerwill
Discussions-Tohttps://github.com/ethereumclassic/ECIPs/issues/263
StatusWithdrawn
TypeMeta
Created2020-01-19

NOTE

This ECIP was rendered unworkable when ECIP 1061: Aztlán EVM and Protocol Upgrades (Yingchun Edition) was activated to the Mordor testnet. It was no longer possible for the original Aztlán hardfork to be Withdrawn and replaced with this ECIP.

The most likely path forward at the time of writing is for ECIP 1078: Phoenix EVM and Protocol Upgrades (“Aztlán redo”) to be moved to Last Call and to have block numbers assigned and to proceed with activation on Mordor and Kotti testnets slightly later than the Aztlán activation but activating on the same block for ETC mainnet.

There will be a Core Devs Call: ECIP-1078 Phoenix Upgrade on Wednesday, February 05, 2019, 4pm UTC, 60 minutes max to make the final decision on this.

Simple Summary

This ECIP describes a hard-fork which would replace ECIP 1061: Aztlán EVM and Protocol Upgrades (Yingchun Edition) to “fix” two issues with ECIP-1061 where the written specification did not match the original intent.

Enable the outstanding Ethereum Foundation Istanbul network protocol upgrades on the Ethereum Classic network without any gas-cost assumptions in a hard-fork code-named Phoenix to enable maximum compatibility across these networks.

Abstract

Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the Istanbul hardforks. The proposed changes for Ethereum Classic’s Phoenix upgrade include:

  • Add Blake2 compression function F precompile
  • Reduce alt_bn128 precompile gas costs
  • Add ChainID opcode
  • Calldata gas cost reduction
  • Net gas metering for SSTORE without dirty maps
  • Addition of SELFBALANCE opcode

The network participants who took part in the ETC Core Developers call on 27th November 2019 were under the impression at the time that the scope we agreed (“Instanbul without the backward-compatibility breaking parts of EIP-1884”) - ECIP-1061 / ECIP-1072 - would move the ETC protocol to a place where it was 100% compatible with the ETH mainnet.

Wei Tang’s implementation of ECIP-1061 shortly afterwards revealed two flaws in the specification, together with recommendations on how to address those shortcomings.

This ECIP codifies those recommendations in the form of a replacement hard-fork which would happen instead of ECIP 1061: Aztlán EVM and Protocol Upgrades (Yingchun Edition) on a timeline still TDB.

Motivation

To enhance the Ethereum Virtual Machine’s (EVM) capabilities, various opcodes shall be added to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since end of 2019.

Specification

This document proposes the following blocks at which to implement these changes in the Classic networks:

  • TBD on Mordor Classic PoW-testnet
  • TBD Kotti Classic PoA-testnet
  • TBD on Ethereum Classic PoW-mainnet

At HARD_FORK_BLOCK, apply the following changes.

Rationale

ECIP 1061: Aztlán EVM and Protocol Upgrades (Yingchun Edition) as defined is “broken” and it would be inadvisable to activate on the ETC mainnet in its current state.

See EIP 1884: Repricing for trie-size-dependent opcodes for the original rationale for the gas-repricings for ETH.

These changes are sensible, but they broke 680 deployed Aragon smart contracts along with various other deployed smart contacts by applying the repricings retroactively and unconditionally.

The new SELFBALANCE opcode does not break backwards compatibility. For compatibility with ETH it is both necessary and desirable.

Short of imminent and catatrophic danger to the ETC network, making retroactive changes which break backwards compatibility is counter to ETC values and philosophy.

Gas-repricings to balance EVM gas prices with real world resource usage is entirely rational and is happening on the ETC protocol too, but will be done in a backwards-compatible ways wherever possible. Unconditional retroactive (“emergency”) repricings would only happen when the network has been halted or has been rendered unusable.

An example of such a situation occurred following the Shanghai attacks on ETH and ETC networks:

ECIP 1015: Long-term gas cost changes for IO-heavy operations to mitigate transaction spam attacks, which has ETC’s equivalent to ETH Tangerine Whistle, with both chains implementing EIP 150: Gas cost changes for IO-heavy operations.

Implementation

Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the Istanbul features currently:

  • Parity Ethereum
  • Multi-Geth
  • Hyperledger Besu

The author is unaware if any of these clients have implemented EIP-1706, but it is a very simple change, analogous to EIP-2200, which all the codebases have already implemented.

Similarly ECIP-1080 has not been implemented in any of these codebases, but is just a “remix” of code which they have already implemented.

This proposal is licensed under the Apache License, Version 2.0, based on specifications developed by Wei Tang within the Core Paper project (https://corepaper.org/).

Core Paper Copyright 2019-2020 Wei Tang.

Bob Summerwill, the author of this proposal attests that his is the sole author of this specific document based on Wei Tang’s work and that he is able to contribute this work to the ECIP process under the Apache 2.0 licence. He further attests that he neither holds nor is aware of any patents, trademarks, copyright issues or other IP hinderances associated with this work.