Going to Atlantis: Ethereum Classic (ETC) ECIP-1054 Hard Fork

1,767 reads

The Definitive Guide to Ethereum Classic’s Next Hard Fork

The Atlantis ECIP-1054 Hard Fork has been announced with great reception amongst the stakeholders in the ETC ecosystem. The proposed changes will “Enable the outstanding Ethereum Foundation Spurious Dragon and Byzantium network protocol upgrades on the Ethereum Classic network in a hard-fork code-named Atlantis to enable maximum compatibility across these networks.”

reactions

You can find the Hard Fork proposal on ETC Labs Core Github:

etclabscore/ECIPs

reactions

The team is available for questions and further discussion on the ETC Labs Core Discord server.

reactions

The Hard Fork is targetted for block8_750_000 on the Ethereum Classic mainnet, expected some time in mid-September 2019

reactions

After this Hard Fork, the Ethereum Classic network will benefit from:

reactions

A more predictable issuance rate of ETC

EIP 100 (Change difficulty adjustment to target mean block time including uncles)

The current formula does not include the “uncle rate”, which can lead to higher issuance rate if the “uncle rate” is manipulated.

reactions

By adding this formula for calculating the exact number of included uncles:

reactions

adj_factor = max(1 + len(parent.uncles) - ((timestamp - parent.timestamp) // 9), -99)

The difficulty adjustment algorithm will now target a constant average rate of blocks produced that includes uncles

reactions

Easier decentralized-application development

The goal of Opcodes and Precompiled contracts is to make development of decentralized applications more efficient

reactions

Opcodes

reactions

EIP 140 (REVERT instruction in the Ethereum Virtual Machine)

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. There is currently no way to do this without consuming all remaining gas.

reactions

EIP 211 (New opcodes RETURNDATASIZE and RETURNDATACOPY)

A mechanism to allow returning arbitrary-length data inside the EVM. 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.

reactions

EIP 214 (New opcode STATICCALL)

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.

This allows contracts to make calls that are clearly non-state-changing, reassuring developers and reviewers that re-entrancy bugs or other problems cannot possibly arise from that particular call; it is a pure function that returns an output and does nothing else.

reactions

Precompiled contracts

reactions

EIP 198 (Precompiled contract for BIGINT modular exponentiation)

This precompiled contract is for efficient RSA verification inside of the EVM. The bit-based exponent calculation is done specifically to fairly charge for the often-used exponents of 2 (for multiplication) and 3 and 65537 (for RSA verification).

reactions

Precompiled contracts for easier execution of zkSNARKS

EIP 196 (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128)

EIP 197 (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128)

zkSNARKS offer Privacy and Scalability solutions that are currently too expensive to verify within block gas limits. These precompiled contracts will decrease gas costs and still be flexible enough for further research into zkSNARKS.

reactions

A higher level of performance on Ethereum Classic

This EIP is focused on “debloating” blockchain state size by removing empty accounts, providing optimizations such as faster sync times

reactions

EIP 170 (Contract-code size limit)

This EIP prevents an attack scenario where large pieces of account code can be accessed repeatedly at a fixed gas cost. The size limit is set to 24576 bytes, larger than any currently deployed contract.

reactions

EIP 658 (Embedding transaction status code in receipts)

With the obsoletion of EIP98 and the introduction of REVERT in EIP 140, there is no clear mechanism for callers to determine whether a transaction succeeded and the state changes contained in it were applied. This EIP replaces the the intermediate state root with a status code, 0 indicating failure (due to any operation that can cause the transaction or top-level call to revert) and 1 indicating success.

reactions

Each change is documented in an EIP. The Technical specifications for each EIP can be found at those documents respectively:

reactions

The proposed blocks to implement these changes are as follows:

reactions

1_039_000 on Kotti Classic PoA-testnet (early August 2019)

4_723_000 on Morden Classic PoW-testnet (early August 2019)

8_750_000 on Ethereum Classic PoW-mainnet (mid-September 2019)

There was a recent discussion with several stakeholders about Atlantis that has been recorded and available here

reactions

Interested in getting more involved with ETC? We’re focused on accelerating the development of Ethereum Classic and need your help! Reach out to us to see how you can get more involved today!

reactions

We’re hiring! — https://www.linkedin.com/jobs/view/1144896854/

reactions

Our team links: Github, Medium, Twitter

reactions

Come chat with us on Discord

reactions

Tags