The Etherum 1.x page is a good starting point for an overview of Working Groups and areas of focus.
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)
- The Berlin fork follows Istanbul
- Some desired EIPs were not ready for Istanbul, and so were 'tentatively accepted' with the intention of considering them for Berlin
- Smaller frequent forks are preferred, so EIPs that were not 'tentatively accepted' will be considered for the fork after Berlin
Previous hard fork details are summarised in this stack exchange question here
|Fork number||Block number||Date||Name|
|11||TBC||TBC||Devcon names thereafter|
Details to follow after Istanbul fork is completed
The proposed EIPs will be derived from the 'Tentatively Accepted' EIPs from the Istanbul Meta-EIP here.
Starting list ('Endorsed' EIPs)
The following 8 EIPs were 'Tentatively Accepted' - EIP-663: Unlimited SWAP and DUP instructions - EIP-1057: ProgPoW, a Programmatic Proof-of-Work There is a pending audit, above and beyond standard security considerations, that should be evaluated prior to inclusion. - EIP-1380: Reduced gas cost for call to self - EIP-1702: Generalized account versioning scheme - EIP-1962: EC arithmetic and pairings with runtime definitions replaces EIP-1829 - EIP-1985: Sane limits for certain EVM parameters - EIP-2045: Particle gas costs for EVM opcodes - EIP-2046: Reduced gas cost for static calls made to precompiles
Review of the EIPs will be ongoing, those complete the following hurdles will progress 1. Endorsement (Community sentiment, developer agreement) 2. Implementation (merged into major clients) 3. Testing (Including final checks from the testing team) 4. Acceptance (Confirmation that the EIP will specifically go in the Berlin fork)
This diagram loosely captures the proposal history for Istanbul and Berlin. Below are some themes that are among the discussed potential changes.
- EVM stack: An improvement of the stack operation is proposed, affecting SWAP and DUP instructions
- Account versioning: Initially highly favoured in the lead up to Istanbul, largely because it was required for EIP-615. Then without a specific use case in mind it was thought that if needed a tailored solution should be implemented to ensure functionality is as desired. While still on the list for Berlin, it is up for discussion as to whether it will go ahead.
- Elliptic curves: Some specific curves implemented, with more general curve solutions still desired by community and left to be polished for the Berlin fork.
- Proof Of Work change: After long community discussion, a proof of work change will probably go ahead once auditing is complete and any issues rectified.
- Gas calculation: Creating a system that will enable more precise gas costing.
Individual EIP notes
The next fork will be called London, in keeping with the DevCon location sequence.
The fork will consist of EIPs mature enough to go in, following the EIP-centric development cycle. Forks will preferentially be small and on-time rather than large and late, with the knowledge that regular forks allow almost-ready EIPs a concrete timeline for incorporation.