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 and network protocol upgrades on the Ethereum Classic network in a hard-fork code-named to enable maximum compatibility across these networks.” Spurious Dragon Byzantium Atlantis 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 of ETC predictable issuance rate (Change difficulty adjustment to target mean block time including uncles) EIP 100 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 (REVERT instruction in the Ethereum Virtual Machine) EIP 140 The REVERT instruction provides 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. a way to stop execution and revert state changes, (New opcodes RETURNDATASIZE and RETURNDATACOPY) EIP 211 . 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. A mechanism to allow returning arbitrary-length data inside the EVM (New opcode STATICCALL) EIP 214 This proposal adds a (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; new opcode that can be used to call another contract it is a pure function that returns an output and does nothing else. Precompiled contracts (Precompiled contract for BIGINT modular exponentiation) EIP 198 This precompiled contract is for . 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). efficient RSA verification inside of the EVM for easier execution of zkSNARKS Precompiled contracts (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128) EIP 196 (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128) EIP 197 that are currently too expensive to verify within block gas limits. These precompiled contracts will and still be flexible enough for further research into zkSNARKS. zkSNARKS offer Privacy and Scalability solutions decrease gas costs A higher level of performance on Ethereum Classic (State-trie clearing) EIP 161 This EIP is focused on “debloating” blockchain state size by removing empty accounts, providing optimizations such as faster sync times (Contract-code size limit) EIP 170 <a href="https://medium.com/media/a8006af07b7d866f0c2378f2230a61d9/href">https://medium.com/media/a8006af07b7d866f0c2378f2230a61d9/href</a> This EIP where large pieces of account code can be accessed repeatedly at a fixed gas cost. , larger than any currently deployed contract. prevents an attack scenario The size limit is set to 24576 bytes (Embedding transaction status code in receipts) EIP 658 With the obsoletion of EIP98 and the introduction of REVERT in , there is no clear mechanism for callers to determine whether a transaction succeeded and the state changes contained in it were applied. , 0 indicating failure (due to any operation that can cause the transaction or top-level call to revert) and 1 indicating success. EIP 140 This EIP replaces the the intermediate state root with a status code Each change is documented in an EIP. The Technical specifications for each EIP can be found at those documents respectively: (Change difficulty adjustment to target mean block time including uncles) EIP 100 (REVERT instruction in the Ethereum Virtual Machine) EIP 140 (State-trie clearing) EIP 161 (Contract-code size limit) EIP 170 (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128) EIP 196 (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128) EIP 197 (Precompiled contract for BIGINT modular exponentiation) EIP 198 (New opcodes RETURNDATASIZE and RETURNDATACOPY) EIP 211 (New opcode STATICCALL) EIP 214 (Embedding transaction status code in receipts) EIP 658 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 here <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
