After the successful Atlantis hard fork, Ethereum Classic (ETC) engineers have scheduled a core developer call for Thursday, October 24, 2019 at 1pm UTC to discuss the upcoming upgrade, Agharta.
The call will take place on the Ethereum Classic Discord on the #ecips channel. A voice chat will be created ad hoc.
Agharta is part of a series of upgrades the ETC blockchain is undergoing to make it fully compatible with the Ethereum standards. The series is comprised of:
- Atlantis (completed on September 12th, 2019): Included upgrades from the Spurious Dragon and Byzantium upgrades on Ethereum.
- Agharta (proposed for March of 2020): Includes upgrades from the Constantinople and Petersburg upgrades on Ethereum.
- Atzlán (projected for last quarter of 2020): Includes upgrades from the Istanbul upgrade on Ethereum.
Notable Feature
The most notable feature about the ETC Agharta hard fork is that it introduces a Generalized Account Versioning Scheme created by Ethereum and Ethereum Classic engineer, Wei Tang, as described in EIP-1702, which he authored.
As a summary, a Generalized Account Versioning Scheme is a versioning system of smart contract accounts which match the versions of the EVM.
The above means that the population of smart contracts at any time on ETC will have smart contract accounts versions, for example, in the form 0x0, 0x1, 0x2, 0x3 ,0x4, 0x5, etc. As the EVM accumulates new opcodes as they are added in the future, each addition will determine an EVM version in the same way, for example, 0x0, 0x1, 0x2, 0x3 ,0x4, 0x5, etc. This means that, at any given time, there will be several account versions and several EVMs stored and operating on the network at the same time.
If, for example, a stock of smart contracts has version 0x3, that means that all the smart contracts with that version will be executed by EVM version 0x3 which contains the opcodes that were in existence when those smart contracts were deployed. Similarly, smart contract account version 0x0, will work with EVM version 0x0, 0x1 with EVM 0x1, 0x2 with EVM 0x2, 0x3 with 0x3, and so on.
At the time of implementation of EIP-1702, all existing smart contracts and the EVM will automatically become version 0x0. From then on, smart contract account and EVM versions will be added progressively as the EVM is updated with new ECIPs with a format, for example, 0x1, 0x2, 0x3 ,0x4, 0x5, and so on indefinitely.
All of the above guarantees that all future changes to the ETC protocol and EVM will always be backward compatible, so smart contracts will never break, as there will always be an EVM version “living” in the blockchain that matches the version of all corresponding smart contracts stored and executed in the network.
Other Changes
As mentioned in ECIP-1056, Agharta adds “support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the Constantinople and Petersburg hardforks”.
The Proposed Changes Include Three Updates, in Addition to the Generalized Account Versioning Scheme
• EIP 145 – Bitwise shifting instructions:
Motivation:
“EVM is lacking bitwise shifting operators, but supports other logical and arithmetic operators. Shift operations can be implemented via arithmetic operators, but that has a higher cost and requires more processing time from the host. Implementing SHL and SHR using arithmetic cost each 35 gas, while the proposed instructions take 3 gas.”
• EIP 1014 – Skinny CREATE2 opcode:
Motivation:
“Allows interactions to (actually or counterfactually in channels) be made with addresses that do not exist yet on-chain but can be relied on to only possibly eventually contain code that has been created by a particular piece of init code. Important for state-channel use cases that involve counterfactual interactions with contracts.”
• EIP 1052 – EXTCODEHASH opcode:
Motivation:
“Many contracts need to perform checks on a contract’s bytecode, but do not necessarily need the bytecode itself. For instance, a contract may want to check if another contract’s bytecode is one of a set of permitted implementations, or it may perform analyses on code and whitelist any contract with matching bytecode if the analysis passes.
Contracts can presently do this using the EXTCODECOPY opcode, but this is expensive, especially for large contracts, in cases where only the hash is required. As a result, we propose a new opcode, EXTCODEHASH, which returns the keccak256 hash of a contract’s bytecode.”
Agharta Developer Call Goals
As ECIP-1056 is still in Draft mode, it needs to be either accepted, updated or rejected according to the ECIP process as described in ECIP-1000.
Additionally, each of the changes have to be discussed. This includes the account versioning scheme (EIP-1702), Bitwise shifting instructions (EIP 145), Skinny CREATE2 opcode (EIP 1014), and EXTCODEHASH opcode (EIP 1052).
Finally, all participants will discuss a timeline for the protocol upgrade. The initial proposed timeline is:
• Morden Classic and Kotti Classic testnets for January of 2020.
• Ethereum Classic mainnet for March of 2020.
Of course, anything else regarding the upgrade is open for discussion as well within the 60 minute time limit allocated.
Invitation
As the call is open and public in the Ethereum Classic Discord, all miners, mining pools, full node operators, wallet operators, and other ETC stakeholders and interested parties of the public are invited to participate in the call.
If you want to comment on the Github discussion about the Ethereum Classic’s Agharta upgrade, please go here: https://github.com/ethereumclassic/ECIPs/issues/131
Thanks to Talha Cross of ETC Labs Core for scheduling the developer call, and Wei Tang of the Multi-Geth team for reviewing the explanation in layman’s terms in this article about EIP-1702 a Generalized Account Versioning Scheme.
Code Is Law
