Aztlan, which was initially scheduled for next March, was postponed after encountering errors. The upgrades will be activated around June 10th, called “Phoenix Day”.
The Aztlan and Phoenix upgrades are scheduled to be activated on the main net at the same time, at the height of block 10,500,839, around June 10th, 2020. This will only be possible if Ethereum Classic developers do not find errors or other problems during the testing period.
In early February, the Ethereum Classic Cooperative (ECC) development team reported that, while implementing the Aztlan hard fork for Parity-Ethereum and Multi-Geth, certain defects were discovered, which implies that the written specification fails to meet the original intentions. These problems were discovered after the Aztlan proposal had been moved to the “accepted” status, which led to its transfer to the “Last Call” status.
A “status” is the given level of development of the proposals to improve the network while they are discussed by Ethereum Classic developers, volunteers, and users. The process includes accepting, rejecting or withdrawing the draft proposal. Once a draft is accepted, it can give way to the “Last Call” status, before being activated or permanently replaced.
The developers said that the solution is not complicated and raised two alternatives, one of which was to make a “fix” including a second hard fork in parallel with Phoenix, activated in the same block and that will occur on “Phoenix Day”, as developers have called that key date. The second option was to start from scratch, removing Aztlan and programming a new hard fork replacement in an indefinite time.
The “fix” option was chosen unanimously, which implies that two upgrades will be scheduled in the same block, with the combination of these two forks having the same effect as if Aztlan had been implemented correctly in the first place, as scheduled for next March.
Wei Tang, the lead developer of Parity, said that the testing networks of Ethereum Classic, Mordor and Kotti have already had immovable scars due to Aztlan’s specification errors. He believes that chanting “code is law” every day is useless when having irresponsible hard forks damage the security of the network. He explains that chanting “code is law” is based on good security judgments and decisions by the parties involved, under the principle of minimizing trust.
Improvements Including Upgrades
With Aztlan (ECIP-1061), support will be added for a subset of changes that affect the protocol introduced into the Ethereum network by the Ethereum Foundation, through the Istanbul hard fork. Another proposed change with Ethereum Classic’s Aztlan upgrade will add the pre-compilation Blake2 F compression function.
Another improvement included in Aztlan will reduce pre-compilation gas costs. Besides, a ChainID operation code will be added. EIP-2008, on its part, will reduce gas costs for the Calldata function, while EIP 2200 balances the cost of SSTORE gas with SLOAD gas cost considerations.
On the other hand, the improvements to Phoenix (ECIP-1078) include compatibility with earlier versions such as ECP-1884 and support for the main Ethereum network.
Four changes will be added with Phoenix: EIP-2200 (structured definitions for net gas measurement), EIP-1283 (net gas measurement for SSTORE without dirt) to be added with EIP-1706 (net gas measurement for SSTORE without dirt), and ECIP-1080 (standalone self-balance).
Last January 12th, Ethereum Classic completed its Agharta hard fork, which enabled the upgrades of the Constantinople and Petersburg protocols from the Ethereum network to the Ethereum Classic network to allow maximum compatibility between these networks.
By Alexander Salazar
