Ethereum Classic Agharta hard-fork proposal proceeds to Last Call
On October 24, 2019, ETC core developers and participating ecosystem stakeholders agreed upon the scope and timing of the Agharta hard-fork proposal. The Agharta hard-fork will be inclusive of the Ethereum Constantinople features making Ethereum Classic fully compatible with Ethereum.
Scope and Timeline
The scope of Agharta will only include the Ethereum Constantinople features. Features out of the scope of Constantinople would not be included but may be considered in proceeding upgrades. This scope of work will allow a timely and safe schedule to test and execute Agharta.
Multi-Geth, Parity, and Geth Classic client teams are confirmed to participate and support Agharta.
The agreed Testnet and Mainnet schedule is as follows
- Morden Testnet, Block
5_000_381
, about Nov/13th, 2019 - Mordor Testnet, Block
301_243
about Nov 20th, 2019 - Kotti Testnet, Block
1_705_549
about Dec/11th, 2019 - Classic Mainnet, Block
TBD
about Jan/15th, 2020
These are estimated dates and specific mainnet block numbers are to be announced shortly.
Agharta Features
Agharta will include:
- EIP 145 (Bitwise shifting instructions)
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)
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)
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.
Collaboration and Beyond
ETC Labs is committed to the continued development and growth of the Ethereum Classic ecosystem. We’re very proud to partner and collaborate with Chainsafe, SecondState, Whiteblock, Gitcoin, BloqCloud, Swarm, and the broader community of contributors around the EthereumStack.
Ethereum Classic and Ethereum are cousin chains and collaborating around the time of the DAO fork was certainly not desirable. However, both ecosystems have evolved and matured with only variable differences in vision. Ethereum Classic and Ethereum are evolving from the same ancestry, and further technical compatibility will provide a stronger bridge to collaborate on shared infrastructure as well as maintain our unique differences. The recent Atlantis hard-fork was to increase ETH Compatability and Agharta will be the second half of that goal.
References:
- ECIP-1056 (Agharta hard-fork spec.)
- EIP 145 (Bitwise shifting instructions)
- EIP 1014 (Skinny
CREATE2
opcode) - EIP 1052 (
EXTCODEHASH
opcode) - Oct 23 2019 core devs meeting