The launch of Berlin, the second step of the Istanbul upgrade, should occur at some point in 2020. Ethereum core developers split Istanbul into two phases because two of the EIPs up for discussion require extensive testing and development before launch. At the moment, core devs have approved and raised two EIPs to accepted status. There are two other proposed EIPs that may be ready in time for Berlin.

Accepted EIP-2315 implements simple subroutines for the EVM which could lower gas costs and make states analysis easier EIP 2537 (which superseded EIP-1962) implements a single BLS curve to make it easier to deploy and manage rollup contracts and zk-SNARKs/STARKs

Proposed EIP-2046 reduces the gas cost for static calls made to precompiled contracts EIP-2565 will re-price the ModExp precompile (EIP-198) to enable more cost-efficient verification of RSA signatures, verifiable delay functions (VDFs), and primality checks, among other functions

Istanbul Phase II notably excludes any EIPs related to the difficulty bomb (i.e., the Ethereum "ice age"). The core developers concluded, "there's no major reason do it now" because the difficulty bomb is only necessary once Ethereum 2.0 and its Proof-of-Stake (PoS) consensus mechanism are activated. Overlooking an Ice Age EIP for now also prevents any further delays in Berlin's development phase.

Core devs and the greater Ethereum community also excludes the EIP-1057, the proposal for the now-infamous ProgPoW (short for Progressive Proof-of-Work). It aimed to alter Ethereum's hashing algorithm to close the performance efficiency gap between generalized and specialized mining hardware (otherwise known as ASICs). While GPU miners and some core devs favored the proposal, many in the community were vehemently against it. Therefore, all sides agree to a href=" "not include ProgPoW/a in any upcoming forks as no protocol changes are worth triggering a network split

Learn more: Berlin EIPs spreadsheet

EIP-1559 was authored by Vitalik Buterin and Eric Conner, among others. It aims to replace Ethereum's "first-price auction" fee model with a base network fee that could change based on network demand. The goal is to create a more efficient fee market and simplify the gas payment process for client and application software, removing the potential for users to pay unnecessarily high gas fees. EIP-1559 also proposes burning the base network fee to help keep this fee low and ETH inflation in check.

Phase 1 will introduce 64 independent shard chains to the ETH 2.0 network. Shard chains will not execute state or keep track of account balances, as the phase intends to only test the construction and validity of shard chains with the Beacon chain. ETH 1.0 will continue to run in parallel with ETH 2.0 throughout this phase.

A proposal for merging the current Ethereum network with Ethereum 2.0 first introduced by Vitalik Buterin. The proposal intends to remove the Proof-of-Work (PoW) chain by moving everything onto the Beacon Chain on an accelerated schedule. This accelerated merge requires stateless clients on Ethereum 1.x, which would remove the need for most nodes to store the entire state altogether.

The final phase of Serenity will add full-functionality to shard chains, enabling them to execute transactions and maintain account balances. It also introduces the eWASM virtual machine, which will replace the EVM.

Olympic was the final Ethereum proof-of-concept released before mainnet launch. Its stated purpose was to reward participants for testing the limits of the Ethereum design by “spamming the network with transactions and doing crazy things with the state.” The event included a competition that offered a pool of 25,000 ETH (a href=" "~0.03% of Ethereum's initial supply/a) for the top miner and developer participants. Broad testnet engagement unearthed critical bugs and simple optimizations in the live system that the core team was able to identify and resolve pre-mainnet. Ethereum core developers deprecated Olympic when Frontier launched in favor of Mordon, the Frontier-equivalent public testnet.

Frontier marked the official 1.0 release of the Ethereum mainnet and introduced a series of new characteristics, including a block reward, a temporary gas block limit, and Canary contracts. The Frontier launch enabled miners to start receiving real ETH as a reward for their efforts, with the initial block subsidy consisting of five ETH per valid block. Version 1.0 also featured a hardcoded gas limit of 5000 gas per block to prevent any issues with node installation. The gas limit lasted only a few days post-launch before being automatically removed. To avoid unwanted chain forks, Frontier contained Canary contracts as well. Canary contracts gave Ethereum core developers the ability to stop specific operations or transactions before a miner wandered off to an orphaned chain. These contracts meant the final execution of transactions remained centralized in Ethereum's early stages.

Homestead was the first planned hard fork of Ethereum and took place at block number 1,150,000. The upgrade removed the Canary contracts used in Frontier, thus eliminating the centralized process for executing transactions, and introduced the now widely-used Solidity smart contracts. It also included the (now deprecated) Mist wallet, the first user interface (UI) for storing and transacting tokens, as well as writing and deploying smart contracts.

Furthermore, Homestead was one of the first implementations of a href=" "Ethereum Improvement Proposals (EIPs)/a, and the upgrade introduced three new EIPs upon activation: EIP-2 (which included sub-proposals EIPs 2.1-2.4) ensured ACID compliance (all-or-nothing) for contract deployments and helped stabilize block times EIP-7 added the DELETECALL opcode EIP-8 equipped client software with the ability to accommodate future network protocol updates

The Spurious Dragon hard fork activated at block 2,675,000, which arrived on Nov. 22, 2019. The upgrade introduced four code changes: EIP-155 offered protection from replay attacks EIP-160 increase the price of the EXP opcode to make it more challenging to slow down the network with computationally intensive operations EIP-161 makes it possible to remove large numbers of empty accounts to reduced blockchain state size EIP-170 set a limit for the code size a smart contract can contain to prevent repetitive attacks on large pieces of code

Byzantium was the first phase of the proposed Metropolis upgrade and activated at block 4,370,000. The Byzantium hard fork included nine EIPs, with EIP-100, EIP-658, and EIP-649, introducing the most significant code changes. EIP-100 adjusted the difficulty formula to stabilize the ETH issuance rate EIP-658 added a new field to transaction receipts to indicate success or failure EIP-649 delayed the difficulty bomb (i.e., the Ethereum "ice age") by one year and reduced the block subsidy from five to three ETH Details on the remaining Byzantium EIPs are available here.

Constantinople, the second phase of Metropolis, was initially scheduled to go live at block 7,080,000 (January 16, 2019). But on January 15, 2019, security auditing firm ChainSecurity discovered a vulnerability in one of the accepted EIPs that would enable a reentrancy attack (i.e., the opportunity for an attacker to steal user funds similar to The DAO hack). Core Ethereum developers and some projects running on the network voted to delay Constantinople until the developers closed the security loophole.

After a month-long delay, Constantinople and its security patch, St. Petersburg, went live at block 7,280,000, introducing five new code changes to the network: EIP-145 added Bitwise shifting instructions to the EVM, making the execution of shifts in smart contracts significantly cheaper EIP-1052 expedited inter-smart contract verification (smart contract can verify each other via a hash rather than the entire code set) EIP-1014 improved state channel integrations to facilitate the connection to off-chain scaling solutions EIP-1283 reduced costs for executing multiple updates within a single transaction (aka the SSTORE opcode) EIP-1234 delayed the difficulty bomb for another year and reduced the mining reward from three to two ETH per block (the reduction is also known as the "Thirdening")

The first phase of Istanbul is set to activate at block 9,069,000, almost two months after its initially scheduled launch (Oct. 16, 2019). Istanbul Phase I intends to introduce six new EIPs upon activation to help optimize opcode computational costs, improve denial-of-service attack security, and enhance the performance of layer-2 solutions using a href=" "ZK-SNARKs/a or a href=" "ZK-STARKs/a, among other advancements. The accepted EIPs include: EIP-152 adds the ability to verify Zcash-to-Ethereum atomic swaps EIP-1108 reduces the costs for ZK-SNARKs EIP-1344 improves smart contract ability, especially those used by layer-2 solutions, to track the correct base chain during a hard fork EIP-1844 restructures the costs of specific a href=" "Ethereum Virtual Machine (EVM)/a opcodes to deter spamming attacks and to match each operation with its required level of computation EIP-2028 reduces the cost of calling data within transactions and the fees associated with ZK-SNARKs and ZK-STARKs EIP-2200 alters the cost of storage in the EVM and allows smart contracts to generate more creative functions

The Muir Glacier hard fork activated at block 9,200,000, which arrived on Jan. 2, 2020. The upgrade only included EIP-2384, which delayed Ethereum's inherent "Difficulty Bomb" for another 4,000,000 blocks (approximately 611 days) to prevent block times from increasing (and usability plummeting). Muir Glacier's abrupt arrival, less than a month after Istanbul, marked the third time Ethereum core developers opted to delay the Difficulty Bomb (aka Ice Age).

Learn more: Ethereum Muir Glacier Upgrade by the Ethereum Cat Herders

Serenity Phase 0 marks Ethereum's initial transition to Ethereum 2.0. This initial phase will introduce the Beacon Chain, which will serve as the backbone for Ethereum 2.0's sharded network architecture. As opposed to Ethereum's current Proof-of-Work (PoW) blockchain, the Beacon Chain will use Casper FFG, a specific variation of Proof-of-Stake (PoS), and a system of validators to confirm transactions and inhibit Sybil attacks.

Ethereum core developers split the Serenity upgrade into three phases to optimize the development process and limit deployment risks. The specifications for this first phase include: Beacon Chain is the core of the Ethereum 2.0 system; it manages the PoS protocol for itself and all of the individual shard chains. The Beacon chain will use Casper the Friendly Finality Gadget (Casper FFG) to ensure transaction finality. Fork Choice enables validators' clients to automatically select the right chain when the Phase 0 Serenity fork is initiated Deposit Contract allows Ethereum stakeholders to transfer funds from ETH 1.0 to ETH 2.0 and claim rights to a validator role on the new PoS chain Honest Validator dictates the expected behavior of an "honest validator and slashing specifications with respect to Phase 0 of ETH 2.0

It is essential to note the launch of Phase 0 will not immediately replace Ethereum 1.0 (also known as Ethereum 1.x). The two chains will coexist for at least until Serenity Phase 1.5 arrives, which marks when the current Ethereum chain will merge into the Ethereum 2.0 system a shard within the network. Running the legacy and future chains in parallel may cause ETH inflation to increase as both chains will simultaneously mint new tokens.