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

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

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

etclabscore/ECIPs

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

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

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

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.

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

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

Easier decentralized-application development

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

Opcodes

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

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

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

Precompiled contracts

• 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).

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.

A higher level of performance on Ethereum Classic

• EIP 161 (State-trie clearing)

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

• EIP 170 (Contract-code size limit)

<a href="https://medium.com/media/a8006af07b7d866f0c2378f2230a61d9/href">https://medium.com/media/a8006af07b7d866f0c2378f2230a61d9/href</a>

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.

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

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

• EIP 100 (Change difficulty adjustment to target mean block time including uncles)
• EIP 140 (REVERT instruction in the Ethereum Virtual Machine)
• EIP 161 (State-trie clearing)
• EIP 170 (Contract-code size limit)
• 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)
• EIP 198 (Precompiled contract for BIGINT modular exponentiation)
• EIP 211 (New opcodes RETURNDATASIZE and RETURNDATACOPY)
• EIP 214 (New opcode STATICCALL)
• EIP 658 (Embedding transaction status code in receipts)

The proposed blocks to implement these changes are as follows:

• 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

<a href="https://medium.com/media/d9240e63672c55469ddf3a06670149e9/href">https://medium.com/media/d9240e63672c55469ddf3a06670149e9/href</a>

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!

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

Our team links: Github, Medium, Twitter

Come chat with us on Discord