The ETH1 page is a good starting point for an overview of Working Groups and areas of focus.
Rough plan is April 2020 for next Hardfork, go up to Roadmap for more info.
Discussion thread for Hardfork Meta: https://ethereum-magicians.org/t/hardfork-meta-istanbul-discussion/3207
The list of EIPs in 1679 are the canonical status of EIPs
This will be maintained as an overview page, can also view the Istanbul GitHub Project in the ECH repo to track progress.
James Hancock has created an automated Google Sheet that covers additional milestones
The deadline for EIP proposals for Istanbul was May 17th. All of these EIPs intend to prepare for inclusion in Istanbul, but Core Dev acceptance, implementation, testing, audits, and other work needs to be done to prepare them. Each EIP has a "discussion-to" link where you can find more information, usually on the EthMagicians Core EIPs forum.
Follow along All Core Dev calls and the EIPs repo.
To reduce the load on discussing each EIP in the dev calls, some EIP coordination can happen in the AllCoreDevs gitter.
Future planned AMA dates: None. Propose a topic and a date in the channel if you have something you feels need better coordination.
Previous AMA dates for reference:
Elliptic curve cluster: Mon 3rd June UTC on Gitter
Account versioning cluster: Tues 4th June UTC on Gitter
Chain metadata cluster: Wed 5th June UTC on Gitter
Storage gas cost cluster: Thurs 6th June UTC on Gitter
Storage writing cluster Fri 7th June UTC on Gitter
Live All Core Devs Call:
There are a number of EIPs to process and make decisions on.
- Trivial EIPs without opposition and non-trivial EIPs with support and very clear plans for testing and implementation are Probable in this grouping.
- Non-trivial EIPs that need small modifications or have unclear implementation and testing plans are Possible.
- More complicated EIPs or those where there is unclear consensus or minimal implementation/testing plans Could happen.
- Those that are superceded or have some opposition and lack a voice Will not happen.
- This grouping is not definitive, or a source of truth. Edits to the wiki to move EIPs into different categories would be helpful.
11 Probable, if implementation and tests completed. (Trivial or polished EIPs)
7 Possible, with refinements based on feedback and implementation and testing
10 Could happen, with some very clear advocation, implementation and testing.
8 Will not happen, unless significant advocation seen.
Below is a one-glance table to summarise the current roadblock for each EIP. The table serves to remind what has been most recently discussed in various channels, including All Core Dev Calls. If a roadblock has been addressed, feel free to remove it from the table. If there are concerns about the suitability of an EIP or its fitness for consideration, please add a note here, but take discussions to the the forum listed in the individual EIP. 'Checkpoint issues', such as and EIP not yet having a major client implementation or not having yet submitted test cases are considered 'standard preparations', which are tracked for each EIP and are not included below.
|Cluster||EIP (strike == not for istanbul)||Any non-checkpoint issue preventing suitability for Istanbul?||Planned AMA or ACD call date||Step required|
|Account versioning||615 Subroutines and Static Jumps for the EVM||Authoring team (mainly Greg Colvin) may need volunteers to help generate tests or implementations.||None planned||Volunteers interested in seeing this EIP succeed (e.g. Feist from Trail of Bits?) could reach out to Greg to offer a hand|
|Account versioning||663 Unlimited SWAP and DUP instructions||Solves the same stack-access problem as 615, which is likely going ahead. Additionally, three technical options are presented and would need to be refined.||None planned||If 615 is cancelled, 663 may be desired. If so, select one of the three options.|
|-||Not needed. No hard fork required and is covered by issue 684||None planned||Non-istanbul client implementations|
|-||1057 ProgPoW, a Programmatic Proof-of-Work||Audit may find hardward/software issues. Danno notes that a small addition is required||None planned||Danno Ferrin to implement addition. Work on client implementations as if will go in. If audit happens and issue found, may need to delay to April hard fork.|
|Elliptic curve||1108 Reduce alt_bn128 precompile gas costs||Benchmarks incomplete||None planned||Zachary Williamson to re-run benchmarks. Mariano Conti is offering help if needed|
|Elliptic curve||1109 PRECOMPILEDCALL opcode (Remove CALL costs for precompiled contracts)||2046 conflicts with 1109.||Jordi Baylina will attend 21 June All Core Devs Call to support 1109||Alex Beregszaszi (2046), Jordi Baylina (1109) and elliptic curve stakeholders need to discuss|
|Storage writing||1283 Net gas metering for SSTORE without dirty maps||None||None planned||-|
|Chain metadata||1344 ChainID opcode||Can co-exist with 1965, which provides similar but complementary function||None planned||Any final concerns that this should not co-exist with 1965 should be directed to the forum|
|-||1352 Specify restricted address range for precompiles/system contracts||No consensus on whether precompiles should be addressed via a range (1352) or by client-based-lists||None planned||Anyone interested in seeing this go ahead should make their case here|
|-||1380 Reduced gas cost for call to self||Not yet discussed in gitter AMA or dev call. EIP title needs to be clearer||None planned||Update EIP title|
|-||1559 Fee market change for ETH 1.0 chain||Péter Szilágyi: May effect transaction propagation Rick Dudley: EIP may not be completed in time||None planned||Rick Dudley to work toward Istanbul and make patch for network propagation|
|Account versioning||1702 Generalized Account Versioning Scheme||The Design-1 variant has been accepted||None planned||-|
|Storage writing||1706 Disable SSTORE with gasleft lower than call stipend||May not be needed for 1283 (because account versioning happening), but may still be benificial for future changes||None planned||Interested parties to review the parity implementation|
|Account versioning||Not needed, given 1702 progressing.||None planned||-|
|Account versioning||Not needed, given 1702 progressing.||None planned||-|
|-||1803 Rename opcodes for clarity||Not yet discussed in gitter AMA or dev call||None planned|
|Elliptic curve||Not needed, given 1962 progressing.||None planned||-|
|-||1848 PR Fork Names Standard||Not yet discussed in gitter AMA or dev call||None planned|
|Storage gas cost||1884 Repricing for trie-size-dependent opcodes||SLOAD is affected by both 1884 and 2035||None planned||Martin Holst Swende (1884) and Alexey Akhunov (2035) to coordinate preferred SLOAD modification|
|Account versioning||Given 1702 progressing, 1891 is redundant.||None planned||-|
|Elliptic curve||1930 CALLs with strict gas semantic. Revert if not enough gas available||Not yet discussed in gitter AMA or dev call||None planned|
|Chain metadata||Not needed, given superceded by 1965 which is progressing.||None planned||-|
|Elliptic curve||1962 EC arithmetic and pairings with runtime definitions||-||21 June Dev Call||Implementations and testing|
|Chain metadata||1965 Method to check if a chainID is valid at a specific block Number||No issues||None planned||-|
|-||Not yet discussed in gitter AMA or dev call. Looks like this doesn't need a hard fork||None planned||Non-istanbul client implementations|
|Chain metadata||2014 Extended State Oracle||There are concerns that ChainID should be removed from the EIP||None planned||Parties interested in moving the EIP ahead should discuss in the forum|
|Elliptic curve||Superceded by 2129||None planned||-|
|-||2025 PR Funding ETH1.X through a Developer Block Reward for 18 Months||Minimal voices for or against have been heard||None planned||Would you like to see funding for improving core ethereum? Gather support on any forum you see fit and bring your evidence to the EIP notes!|
|State rent||2026 State Rent H - Fixed Prepayment for accounts||Not yet discussed in gitter AMA or dev call||None planned||POC Implementation WIP|
|State rent||2027 State Rent C - Net contract size accounting||Not yet discussed in gitter AMA or dev call||None planned||POC Implementation WIP|
|-||2028 Calldata gas cost reduction||No specific cost has been proposed||None planned||Authors to propose a specific cost|
|State rent||2029 State Rent A - State counters contract||Not yet discussed in gitter AMA or dev call||None planned||POC Implementation WIP|
|State rent||2031 State Rent B - Net transaction counter||Not yet discussed in gitter AMA or dev call||None planned||POC Implementation WIP|
|Storage gas cost||2035 Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs||SLOAD is affected by 1884 and 2035||None planned||Martin Holst Swende (1884) and Alexey Akhunov (2035) to coordinate preferred SLOAD modification|
|Storage gas cost||2045 add EIP for fractional gas costs||None||None planned||1. Casey to guide Geth/Parity to implement EVM-One changes to; 2) Enable benchmarks to; 3) Determine specific parameters for the EIP|
|Elliptic curve||2046 Reduced gas cost for static calls made to precompiles||2046 conflicts with 1109.||Any volunteer to discuss with Jordi (1109) on the next ACD call?||Alex Beregszaszi (2046), Jordi Baylina (1109) and elliptic curve stakeholders need to discuss|
|Elliptic curve||2129 Blake 2b 'F' Precompile (Matt Luongo)||None||None planned||Client implementations|
Some EIPs are complementary and some are mutually exclusive improvements that deprecate other proprosals. Below is a rough clustering to highlight these relationships.
Edits are welcome.
EIPs with minimal interactions with other proposals
Scaling, privacy, bridges to other chains, DNS certificate validation in ENS, forward compatibility with IPFS.
Curves enabled and possible uses:
Curves in the ecosystem not related to the Istanbul EIPs
Introduce new curves using elliptic curve arithmetic with either 1962 (preferred) or 1829
Both 1829 and 1962 allow for new curves to be added later without waiting for specific precomiples to be included in hard forks. 1829 Allows a class of eliptic curves (Edward curves) to be supported through a precompile for linear combinations. 1962 is a precompile that extends and formalises 1829. 1962 features (as compared to 1829) three main differences:
There were no supporting arguments in a recent discussion for 1829, and 1962 is progressing well, so 1829 will not be needed. 1962 requires either 1109 or 2046 to make calls economically viable (see below).
How to define a precompile? (address range with 1352 vs client-based lists of known precompiles)
1352 is still a maybe and the decision of "how do we define what a preompile is" is up for discussion. While it creates a nice range for defining what precompiles are, which may help with static analysis, there are some serious concerns on FEM about safety. It was clarified that 1352 is not required explicitly by either 1109 or 2046, so either of those can be chosen, but they may need to be modified to be clear about how the define a precompile. Action required: Decide if precompiles should be defined by range (push forward with 1352) or client based lists (shelve 1352).
Make precompile call costs cheaper, either by modifying an existing opcode (2046) or introducing a new opcode (1109)
The goal is to make precompiles cheaper. Both EIPs seek to make 1108, 2024 and 1962 cheaper by reducing the cost of calling a precompile. The decision of 1109 vs 2046 was undecided. The options for calling precompiles are either to create a new opcode (choose 1109) or to modify the semantics of STATICCALL if the destination is a precomile. Action required: Decide if we prefer a new opcode or to modify an old opcode.
Specific curve optimisations:
There is a lot of interest in enabling immediate use of specific curves. Alt_bn128 is enabled by 1108. 1108 also supplements 1829 which reduces the cost of addition, multiplication and and pairing checks.
Blake2b is enabled by 2024 which introduces a specific precompile for Blake2b for immediate use. Both 1108 and 2024 can coexist with 1962 without issue
In ACD call 63 (45min41s), James Preswitch outlined that 2024 is superceded by a new implementation with F-compression, with smaller codebase changes, with less work required by client teams. Maintained by Keep, who have implemented in Geth. It is faster than the dedicated Blake2b 2024. The 2s curve could be a nice-to-have, for future ZCash-Ethereum interop, but at the moment has no implementation and maybe could go in the April 2020 hard fork.
DOS attack mitigation
There was a discussion about DOS attacks from calls that result in disk loading being too cheap. It seems that as long as the opcode being made cheaper only applies to precompiles, then there is no risk.
1930 Adds the ability to make calls with specific amounts of gas, with a revert endpoint, through new variants of STATICCALL, DELEGATECALL and CALL. This may benefit EIPs that modify CALL/STATICCALL behaviour. The winner out of 1109 vs 2046 will need to be checked against 1930 to ensure behaviour is as expected.
Link to previous Core Dev gathering presentation on account versioning: https://git.that.world/talks/20190417-account-versioning.git/plain/presentation.pdf
Versioning enables eWASM to coexist with EVM in one block and makes future EVM upgrades safer. Included in the account versioning group is the EVM upgrade (615) that enables static jumps, which enable strong formal analysis of contracts
For Istanbul, we have some EIPs that propose to decrease operation costs. As part of the last hard fork postmortem, one of the main reason the re-entry bug happened is because EIP-1283 was the first to-be-on-mainnet EIP that includes gas cost decrement. Later in the discussion, it's generally agreed that if we ever want to do another gas/operation cost decrement, we'd either need extra assessment, or it needs to be combined with account versioning.
As a result, account versioning EIPs affect a larger portion of Istanbul EIPs than what's listed above.
EVM upgrade to enable static jumps:
Three account versioning proposals, only one must be selected
1702 flavours: 1 with-optional-code-prefix (Preferred) and 2 with-compulsory-code-prefix (not preferred)
Some opcodes are mispriced, and by repricing them more transations could fit into blocks.
A separate new counter that counts gas with more granularity prepares clients for how eWASM contracts meter gas.
Match gas cost with CPU-time cost: Current gas costs do not reflect the true CPU cost of operations. In particular, SLOAD and BALANCE are overpriced. 1884 Increases SLOAD and BALANCE gas costs, to properly reflect real relative CPU-time cost. A new opcode SELFBALANCE is also introduced.
Increase throughput without state bloat: To increase transaction throughput the price of computation opcodes (e.g ADD, SUB, MUL etc.) could be decreased by up to a factor of 10. The EIP leaves the gas cost of other opcodes the same (e.g those that affect the state size such as SSTORE, CREATE). To lower the cost of these computational opcodes, which are already priced close to 1 (the minimum possible value), the idea is to allow fractions of gas. 2045 introduces a new gas counter
particles which is an optional feature that some developers may chose to use when hunting for more optimised contracts. Optimisations in evmone could be implemented in Geth and Parity to reduce the real CPU time for these opcodes, allowing for the benchmarked ~10x reduction in some gas costs.
Other EIPs that affect storage gas costs might be:
1965 Adds a precompile to get the ChainID at a specific block number. This supercedes 1959, which introduces ChainID as a new opcode, but likely has reduced fork freedom.
1344 introduces ChainID via an opcode. Could theoretically co-exist with 1965, but provides similar functionality. Safe from replay vulnerabilities, but has additional considerations (as noted in the EIP rationale). There may be some utility in using both 1344 and 1965 at the time of a hard fork to allow transactions to traverse the fork more cleanly, as discussed in the forum
2014 Introduces an extensible contract system to bring more data to smart contracts, including block hashes and chain identifiers, using the contract ABI encoding. Might be used with 1965 or 1959 to check the validity of the chain identifier for a block. There are concerns in the EIP discussion thred that including a method for chain ID in this EIP is complex and not wise.
Maintain present-day ethereum by making optimisations that keep state size small
State rent proposal is planned as a gradual upgrade over multiple hard forks. Proposals by Alexey Akhunov.
Planned prototyping and implementation, in order of decreasing priority:
Newest at the top, likely EthCatHerders repo / Github project will be source of updates going forward