Prior information is available on the releases page.
The ETH1 page lists Working Groups and areas of focus.
Pro-fork: The community has embraced the concept of hard forks, with the understanding that new major changes can be challenging but rewarding.
Regular cadence: Forks have increasingly been moving toward a traditional software release-schedule. Regular small hard forks allow upgrades to be included in more timely and manageable way that large infrequent forks, as described here
The fork will ideally follow an EIP-centric approach outlined here. This approach will allow EIPs to mature independently of forking schedule. When mature, they can be added to the next scheduled fork.
Steps for EIPs: 1. Endorsement (by major clients, developers and community stakeholders) 2. Implementation (merged into major clients) 3. Testing 4. Acceptance (Allocate to a specific hard fork)
|Fork number||Block number||Date (yyyy-mm-dd)||Name|
|9||9200000||2019-12-31 (tentative)||Muir Glacier|
|13||TBC||TBC||Devcon names thereafter|
A good summary of the initial forks can be seen in the StackExchange response here
The first block in the Ethereum mainnet.
Addition of the ice-age to the protocol to make a hard fork required in the future. This promoted planned upgrades. More details here here.
Upgrades to improve contracts and networking, outlined in the meta-EIP here
A challenging fork for the community in which, after a hack of a high profile contract, accounts were refunded as outlined here. This hard fork is notable in that the unmodified chain was mined by a number of people, who now maintain the separate Ethereum Classic chain in which the hack was never refunded.
This fork increased the cost of EVM opcodes that were computationally expensive relative to financial cost. The opcodes were the basis of a spam attack, and the upgrade also made changes to mitigate the effect of the attack.
Described in the Ethereum Foundation blog here
This fork closely followed Tangerine Whistle and implemented additional changes to mitigate the effect of the spam attack, among other improvements.
This fork included a number of specific upgrades to allow richer funtionality between contracts and some features to allow specific features related to elliptic curves.
Initially planned for Q1 of 2019, this fork was delayed to allow for evaluation of one of the EIPs. The fork went ahead without that EIP (EIP-1283) and was referred to by some as the Petersburg fork. More here.
Noteable in this upgrade were changes to allow layer 2 solutions to pre-define the addresses of future contracts. This allows state channels to deploy contracts that could be deployed on-chain, but may not be required to.
- EIP 145 Bitwise shifting instructions in the EVM
- EIP 1052 EXTCODEHASH opcode
- EIP 1014 Skinny CREATE2
- EIP 1234 Constantinople Difficulty Bomb Delay and Block Reward Adjustment
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
The Ethereum Foundation blog here.
The Cat Herders blog here.
An update to delay the difficulty bomb, see the wiki page here.
See the wiki page here.
See the wiki page here.
Named after the devcon location sequence Upgrades will include features that: - Improve and maintain the mainnet ('ETH1') - Integrate the mainnet with the scaling upgrade ('Serenity/ETH2'). - Mainnet to recognise the Beacon Chain (phase 0) - Mainnet to inherit the finality of the Beacon Chain - Mainnet to be added as one shard under the scope of the Beacon Chain - Addition of more shards, with interoperability between shards
Serenity / ETH2
See the ETH2 Specs Github Repo here.
The ETH2 Project Management repo here.