ECIP 1104: Mystique EVM and Protocol Upgrades Source

AuthorCody Burns
Discussions-Tohttps://github.com/ethereumclassic/ECIPs/discussions/440
StatusFinal
TypeMeta
Created2021-07-28

Simple Summary

Enable the outstanding Ethereum Foundation London network protocol upgrades on the Ethereum Classic network in a hard-fork code-named Mystique 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 London hardforks. The proposed changes for Ethereum Classic’s London upgrade include:

EIP Eth PR omit or include
3529 (Alternative refund reduction) #22733 Include
3541 (Reject new contracts starting with the 0xEF byte) #22809 Include
1559 (Fee market change) #22837 #22896 Omit
3198 (BASEFEE opcode) #22837 Omit
3228 (💣 delay) #22840 and #22870 Omit

The fee market change and bomb delay are omitted at this time as they are not applicable for Ethereum Classic. The fee market change puts the network at longterm risk since as ETC currently has a capped supply and fixed emmision epocs. The bomb was disarmed in ETC code base in a previous hardfork.

EIP Summaries and expected action

Included
  • EIP 3529 “Alternative refund reduction” Remove gas refunds for SELFDESTRUCT, and reduce gas refunds for SSTORE to a lower level where the refunds are still substantial, but they are no longer high enough for current “exploits” of the refund mechanism to be viable.
    • gas price should be adjusted on respective opcodes to reflect the new EVM standard
  • EIP 3541 “Reject new contracts starting with the 0xEF byte”: Disallow new code starting with the 0xEF byte to be deployed. Code already existing in the account trie starting with 0xEF byte is not affected semantically by this change.
    • No future contracts shall be deployed on chain with 0xEF prefix. Clients should respond with an error message citing ECIP 1104 as justification of rejection.
Omitted
  • EIP 1559 “Fee market change”: A transaction pricing mechanism that includes fixed-per-block network fee that is burned and dynamically expands/contracts block sizes to deal with transient congestion.
    • Undesirable to implement at this time as it would conflict with the current monetary policy set in ECIP-1017
  • EIP 3198 “BASEFEE opcode”: Adds an opcode that gives the EVM access to the block’s base fee.
    • It depends on EIP-1559. Behavior specifications for use in context without EIP-1559 are undefined.
  • EIP 3228 ”💣 delay”: Delays the difficulty bomb to show effect the first week of December 2021.
    • Not applicable to ETC due to difficulty bomb being defused

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

  • 5_520_000 on Mordor Classic PoW-testnet (Jan 13th 2022)
  • 5_578_000 on Kotti Classic PoA-testnet (Jan 23th 2022)
  • 14_525_000 on Ethereum Classic PoW-mainnet (Feb 13th 2022)

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

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 early 2021.

Specific to EIP 3529: Refunds are currently only applied after transaction execution, so they cannot affect how much gas is available to any particular call frame during execution. Hence, removing them will not break the ability of any code to execute, though it will render some applications economically nonviable.

Gas tokens will become valueless.

Specification

Technical specifications for each EIP can be found at those documents respectively:

Rationale

Interoperability: Establishing and maintaining interoperable behavior between Ethereum clients is essential for developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Mordor, Görli and Kotti).

Immutability: None of the introduced new opcodes in the EVM has the potential to change the behavior of existing contracts; in the case where previously an arbitrary invalid bytecode would have been deployed to the network, none of them would be able to modify the state of the Ethereum Classic networks retrospectively. Adding opcodes to the EVM increases its functionality and should be considered a feature upgrade rather than a modification.

Standards Compliance: In order to guarantee that every EOF-formatted contract in the state is valid, we need to prevent already deployed (and not validated) contracts from being recognized as such format. New code starting with the 0xEF byte will not be deployable, and contract creation will result in a failure. However, given bytecode is executed starting at its first byte, code deployed with 0xEF as the first byte is not executable anyway.

While this means no currently executable contract is affected, it does rejects deployment of new data contracts starting with the 0xEF byte.

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 London features currently and will be able to support the Mystique upgrade:

  • Core-Geth (maintained by ETC Core)
  • Hyperledger Besu (maintained by ConsenSys)

Copyright and related rights waived via CC0.