Aztlan

Revision as of 15:20, 15 April 2020 by Sorpaas (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Aztlán EVM and Protocol Upgrades (Yingchun Edition) ECIP-1061 is a hard fork that has been cancelled in Ethereum Classic.[1]

Aztlan
Consensus upgrade
TypeHard fork
StatusCancelled
PreviousAgharta
NextPhoenix (old)
Ethereum family

SpecificationEdit

The hard fork enables the following EIPs:

  • EIP-152: Add Blake2 compression function F precompile
  • EIP-1108: Reduce alt_bn128 precompile gas costs
  • EIP-1344: Add ChainID opcode
  • EIP-1884: Repricing for trie-size-dependent opcodes
  • EIP-2028: Calldata gas cost reduction
  • EIP-2200: Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change

Hard forkEdit

The hard fork was scheduled from Etheruem Classic mainnet at block 10,500,839. Originaly this was thought to be in March, 2020, but the tool used to estimate this date was later re-calibrated and discovered the update would occur around June, 2020. After implementation of Aztlán on the Ethereum Classic testnets Kotti and Mordor, the hard fork was later cancelled due to issues discovered during the testnet implementation.

ReviewEdit

Trie access underpriceEdit

  • ConsiderationThis consideration is addressed in Phoenix (new) and it replaces this hard fork.

It is known that the reason to apply EIP-1884 on Ethereum is to fix a potential vulnerability related to trie access underprice. The decision not to apply EIP-1884 on Ethereum Classic effectively leaves the vulnerability open. While we don’t disclose the exact method for the effective attack here in order to protect public interest, you can read this paper to learn about backgrounds of the attack.

Incompatibility with EthereumEdit

  • Design failureThis design failure is addressed in Phoenix (old) and it supersedes this hard fork.

In Aztlan, interoperatibility with Ethereum is listed as one of the primary goal of this hard fork. Unfortunately, due to a design failure overlooked in the specification, it accomplishes the exact opposite.

This is primarily due to the new SELFBALANCE opcode included in EIP-1884. Aztlan stripped EIP-1884 due to backward compatibility reasons. However, by doing this, it also stripped SELFBALANCE. Not including this opcode means that any smart contracts compiled using Solidity or Vyper, using the Istanbul hard fork configuration, will not be able to function correctly on Ethereum Classic Aztlan. Those who wish to compile to Ethereum Classic must continue to use Constantinople or Byzantium hard fork configuration, and as a result, cannot take advantage of any Istanbul features.

Inconsistency in net gas meteringEdit

  • Design failureThis design failure is addressed in Phoenix (old) and it supersedes this hard fork.

Aztlan decided to include EIP-2200 for SSTORE net gas metering. However, it did not thoroughly consider the facts that EIP-2200 is designed with the full context of Istanbul hard fork, whose pre-conditions that Aztlan does not fulfill.

Net gas metering has a family of EIP specifications, including EIP-1283, EIP-1706 and EIP-2200. The specifications contain a parameter of "dirty gas", which is charged when a storage value has already been modified in the same transaction context. This value, as in the design intention, is expected to always equal to the value of SLOAD gas cost. In EIP-2200, this "dirty gas" is set to be 800, so as to accommodate EIP-1884’s gas cost change of SLOAD from 200 to 800. However, Aztlan does not include EIP-1884 but only applied EIP-2200, resulting in inconsistency in the EIP design intention, and may lead to unknown gas cost issues.

This has also led to confusions in implementations. For example, a contributor previously merged an incorrect version of Aztlan hard fork into Parity Ethereum. This, if left unspotted, will lead to consensus split on the whole Ethereum Classic network.

CriticismEdit

This hard fork enjoyed endorsements from several major Ethereum Classic groups until it was cancelled. Several criticism and controversies arose during its lifetime.

Process controversyEdit

It was criticized that the move of the hard fork did not follow proper ECIP process, because an objection by an ECIP editor was abruptly dismissed without explanations, of whether the agreed specification was ECIP-1061 or ECIP-1072.

Ignored safety concernsEdit

In November 2019, a developer raised concerns over safety issues of this hard fork[2]. However, the concerns were largely ignored by Aztlan supporters until two months later.

Blaming implementing specification bugsEdit

When the review[3] on Aztlan was published, some supporters of Aztlan blamed client implementations MultiGeth and OpenEthereum for "implementing the specification bugs".[4]

Mordor and Kotti chain splitEdit

EIP-2200 has an implicit dependency of EIP-1884. As a result, the specification of EIP-2200 did not specify whether it increases gas cost of SLOAD, because it's covered in EIP-1884. Aztlan, however, does not apply EIP-1884 but only EIP-2200. This left ambiguity in interpretations of EIP-2200 and caused chain split in Mordor and Kotti testnets. Supporters of Aztlan blamed specification writers for bugs, while the writer explained that Aztlan used EIP-1884 and EIP-2200 in a way that it's not supposed to function, and it's impractical for a specification to cover use cases that it's not designed to cover.

Due to release cycles of client implementations and later cancellation of Aztlan, the chain split of Mordor and Kotti lasted for several weeks.

ReferencesEdit