Earlier this month, the Ethereum Foundation team lead Péter Szilágyi confirmed the date of the network’s upcoming upgrade, Istanbul. Ethereum’s eighth hard fork overall and the second one this year is slated to take place on Dec. 4.
Istanbul will introduce a number of improvements such as interoperability with Zcash, cheaper zero-knowledge layer two scalability solutions, and adjusted gas price for certain operations, marking another milestone along the road to Ethereum 2.0, a highly anticipated “ultimate” version of the network. How exactly does Istanbul fit into the grand scheme of things?
Forks, releases and phases
No complex open-source system is ever in its final state — software is always in motion, constantly being improved and updated. This is especially true for Ethereum, whose path toward becoming a distributed “world computer” and the platform for decentralized applications has been outlined at its inception as a series of consecutive milestones.
The current goal that the Ethereum developer community is pursuing is an advanced version of the network called Ethereum 2.0, Eth2 or Serenity. The upgrade is expected to see a number of drastic developments, such as transition from proof-of-work to a more energy-efficient proof-of-stake consensus algorithm, realization of a new scalability paradigm called sharding, and the introduction of a more efficient Ethereum Virtual Machine capable of executing high-performance smart contracts. Researcher Danny Ryan has formulated five overarching design goals for Ethereum 2.0: decentralization, resilience, security, simplicity and longevity.
Differences in the language used to describe the stages of network updates can be confusing: There are hard forks named after the world’s great cities, numbered phases, releases denoted by version codes, and poetic labels such as “serenity.” Yet, it ultimately comes down to a rather straightforward structure.
The largest increment of the development process is called a release. A single release can be enacted by the means of one or several hard forks — makeovers of the blockchain protocol that mark a complete departure from its old version.
To date, there have been three releases — the current one called Metropolis — which has been rolled out in two steps: Byzantium and Constantinople hard forks, with Istanbul still to go. Subsequent hard forks, Berlin (tentatively scheduled for June 2020) and London, will mark the advent of the fourth release, Ethereum 2.0, or, Serenity.
Hard forks enact changes to the currently operational Ethereum mainnet. The roadmap to Ethereum 2.0, however, stipulates the creation of separate new chains — such as the eventual existence of two active Ethereum chains with different consensus mechanisms. The rollout of the Ethereum 2.0 chain will come in a sequence of phases specified in the roadmap.
Istanbul: accepted improvements
The main governance vehicle that the Ethereum community relies on to move the network forward is Ethereum Improvement Proposals. They specify suggestions related to changes in the core protocol, client APIs (Application Programming Interfaces) and smart contract standards.
Authors normally seek to time proposals to the forking schedule and target specific hard forks announced in advance. There is currently a push in the community for switching to an “EIP-centric” approach in upgrading the system, where more frequent and smaller forks could allow proposals to develop at their own pace. Berlin, the hard fork slated to follow Istanbul, is expected to be the first in this paradigm.
Istanbul still follows the “fork-centric” approach, where many proposals in various stages of their life cycle were pitched and reviewed during All Core Devs calls. Developers classified EIPs as either desired and ready to go into the fork (accepted), desired but not yet ready (tentatively accepted, assumed go live with the next hard fork), or not desired (permanently rejected). Out of 38 EIPs presented, only six were accepted for inclusion, with another eight approved for the Berlin fork. Here is an outline of the accepted proposals:
EIP-152 brings the ability to verify the Equihash proof-of-work algorithm within an Ethereum contract, enabling interoperability between Zcash and Ethereum blockchains.
EIP-1108 reduces precompile gas costs, making a generation of non-interactive zero-knowledge proof, or zk-SNARKs, cheaper. This is good news for two reasons. One is that the change will enhance development of privacy-focused applications that use this type of cryptography.
More consequentially, using zk-SNARKs is a second-layer solution that can be instrumental in alleviating some of Ethereum’s scalability issues by moving a significant amount of computational work off-chain.
EIP-1344 adds an opcode that returns the current chain’s unique identifier, introducing a way for contracts to track the Ethereum chain they’re on. This will improve the system’s resilience to replay attacks on signed transactions.
EIP-1884 is perhaps the most debated of the accepted proposals, causing controversy since at least August this year. Introduced by Martin Holst Swende, a security lead at Ethereum Foundation, this proposal is aimed at repricing certain opcodes (instructions given to the Ethereum Virtual Machine executing smart contracts) in order to “obtain a good balance between gas expenditure and resource consumption.”
The problem that EIP-1884 is supposed to solve stems from some operations becoming more resource-intensive with the expansion of the Ethereum blockchain. At the moment, blocks with similar gas consumptions take vastly different amounts of time to finish, which is not only an issue in itself, but also can be a vector of a denial-of-service attack.
Friction emerged during the 69 Core Dev call on Aug. 23, where Parity Technologies’ Wei Tang expressed concerns over the possibility that the change of opcode costs would break some contracts that are already deployed. He argued that backward compatibility should be preserved, enabling old contracts to operate according to the original pricing.
Hudson Jameson, Ethereum Foundation’s community liaison, responded that there is a “precedent set that OPCODE prices can and will change so your contracts should not rely on the assumption that they will not change,” adding that the transition would leave people better prepared for the more drastic changes that are imminent.
EIP-1884 will affect a limited number of contracts across a variety of projects. Hubert Ritzdorf from blockchain security firm ChainSecurity has put together perhaps the most comprehensive list of such contracts that stand to be affected.
EIP-2028 reduces the cost of calling data in transactions, potentially leading to larger blocks and thus improved scalability of the network. This will also make layer two scalability solutions (such as zk-SNARKs) more accessible.
EIP-2200 implements net gas metering, changing the way the cost of storage in the EVM is calculated. This will enable new functions of contract storage and reduce some excessive costs.
Still in the works
Another high-profile proposal that the Ethereum community considered in the buildup to the Istanbul hard fork is EIP-1057, which seeks to replace the current Ethash mining algorithm with a new proof-of-work function called ProgPoW, short for Programmatic Proof-of-Work. Core devs have tentatively accepted the initiative, pending audit results, for inclusion in the Berlin hard fork.
The idea behind this algorithm update is to tune it for commodity hardware that uses graphics processing units, making mining more difficult for setups equipped with Application-Specific Integrated Circuit chips.
This measure is designed to restore some degree of decentralization to mining power distribution while leveling the field by making Ethereum mining more attractive to individual users and small enterprises not invested in specialized hardware. ASICs were a major driver behind industrialization of mining over the past few years, leading to massive, centralized mining clusters.
Earlier this year, Ethereum Foundation’s security lead Martin Holst Swende said that the introduction of ProgPoW would mitigate the degree of ASICs and other hardware accelerators’ dominance on the network. He added that another reason for the change is the security flaws inherent to Ethash.
Although there seems to be agreement among the core developers with regard to desirability of ProgPoW, not everyone in the community is happy about the prospect of the mining algorithm changing before the switch to proof-of-stake in Ethereum 2.0.
The most vocal dissenter so far has been Aragon, a project for managing decentralized autonomous organizations, whose community voted on Nov. 2 to oppose any changes to Ethash before the transition to Ethereum 2.0.
Despite some tension, there is no indication that a critical mass of Ethereum users is bitterly opposed to the proposed change, rendering it unlikely that the development will lead to a serious rift.
Should the independent audit attest to the robustness of the new algorithm, it will likely be enforced with the Berlin hard fork, now tentatively scheduled for June 2020, as Ethereum continues its march toward the coveted 2.0 version of the network.
