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
Istanbul was approached with a fork-centric approach, where EIPs were proposed for the fork, reviewed then accepted. This resulted in many EIPs being proposed, in various states of readiness. This approach limits the amount of review time per EIP.
Future forks 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.
Istanbul brings upgrades that will:
EIP-152 Adds the ability to verify the Equihash PoW within an ethereum contract. This will enable a relay and atomic-swap transactions between Zcash.
EIP-1108 Makes zk-SNARKs cheaper, allowing for cheaper scaling and privacy applications to be built. See Matter labs, Aztec, Rollup and Zether for examples.
EIP-1344 Adds a way for contracts to track the correct chain. To be used by contracts, especially those used by layer 2 (state channels, plasma), to follow the correct layer 1 chain, especially during a hard fork.
EIP-1884 Changes the cost of some EVM opcodes to prevent spamming attacks and to balance blocks better. The amount that must be paid for each operation in ethereum usually matches the computation required for that operation. This change increases some costs of some opcodes that are computationally intensive but currently cheap.
EIP-2028 Makes zk-SNARKs and zk-STARKs cheaper by reducing the cost of calling data within transactions. This will make layer 2 solutions able to increase throughput.
EIP-2200 Changes the calculation of cost of storage in the EVM and will enable contracts to introduce new functions including re-entry locks and same-contract multi-send.
Previous hard fork details are summarised in this stack exchange question here
|Fork number||Block number||Date||Name|
|9||TBD||TBD||Berlin (Devcon location)|
|11||TBC||TBC||Devcon names thereafter|
Official status of accepted EIPs (in the hard fork meta-EIP) here.
Ethereum Cat Herders tracking page here
James Hancock has created an automated Google Sheet that covers additional milestones here
38 EIPs were proposed in total. After initial discussions in various forums, they were informally/tentatively sorted into groups based a combination of support, clarity, implementation, testing.
Referenced in discussions for the fork but not formally in the Istanbul meta-EIP, and not included in Istanbul:
Below are some themes that were among the discussed potential changes.
|EIP||Title||Status||Status note||See discussion cluster|
|EIP-152||Blake 2b 'F' Precompile (Matt Luongo)||Accepted (Istanbul)||-||Elliptic curve|
|EIP-615||Subroutines and Static Jumps for the EVM||Withdrawn||Mix of issues: complexity, time shortage, funding and impact on tooling||Account versioning|
|EIP-663||Unlimited SWAP and DUP instructions||Tentatively accepted (Berlin)||Addresses similar stack-access problem as 615 (withdrawn). Three technical options are presented (needs refining). Tentatively accepted in decision 67.1||Account versioning|
|EIP-689||Address Collision of Contract Address Causes Exceptional Halt||Rejected/Withdrawn (not proposed)||Not needed. No hard fork required and is covered by issue 684||Independent|
|EIP-1057||ProgPoW, a Programmatic Proof-of-Work||Tentatively accepted (Berlin) in decision 66.3||Pending audit results||Independent|
|EIP-1108||Reduce alt_bn128 precompile gas costs||Accepted (Istanbul)||Accepted in decision 66.5||Elliptic curve|
|EIP-1109||PRECOMPILEDCALL opcode (Remove CALL costs for precompiled contracts)||Rejected/Withdrawn||Conflict with 2046 (which is Tentatively accepted (Berlin))||Elliptic curve|
|EIP-1283||Net gas metering for SSTORE without dirty maps||Rejected/Withdrawn||Replaced by newer verision, EIP-2200 (Accepted)||Storage writing|
|EIP-1344||ChainID opcode||Accepted (Istanbul)||Accepted in decision 66.1. Complements 1965 (which is rejected/withdrawn)||Chain metadata|
|EIP-1352||Specify restricted address range for precompiles/system contracts||Rejected/Withdrawn||Rejected in decision 67.2 due to lack of champion. No consensus on whether precompiles should be addressed via a range (1352) or by client-based-lists||Elliptic curve|
|EIP-1380||Reduced gas cost for call to self||Tentatively accepted (Berlin)||Tentatively accepted in decision 67.1||Independent|
|EIP-1559||Fee market change for ETH 1.0 chain||Withdrawn||Not completed in time. Concerns about effect on transaction propagation. Withdrawn in decision 67.4 due to lack of champion.||Independent|
|EIP-1702||Generalized Account Versioning Scheme||Tentatively accepted (Berlin)||Design-1 variant was been accepted in decision 63.2. Concerns about what specifically this is needed for.||Account versioning|
|EIP-1706||Disable SSTORE with gasleft lower than call stipend||Rejected/Withdrawn||Replaced by EIP-2200 (Accepted)||Storage writing|
|EIP-1707||Use Version Byte Prefix for Contract Account Versioning||Rejected/Withdrawn (not proposed)||Superceded by 1702 (which is tentatively accepted (Berlin))||Account versioning|
|EIP-1712||Disallow Deployment of Unused Opcodes||Rejected/Withdrawn (not proposed)||Superceded by 1702 (which is tentatively accepted (Berlin))||Account versioning|
|EIP-1803||Rename opcodes for clarity||Rejected/Withdrawn||Rejected in decision 67.2 due to lack of champion.||Independent|
|EIP-1829||Precompile for Elliptic Curve Linear Combinations||Rejected||Superceded by 1962 (which is Tentatively accepted (Berlin)). Rejected in decision 66.7||Elliptic curve|
|EIP-1848||Fork Names Standard||Rejected/Withdrawn (not proposed)||-||Independent|
|EIP-1884||Repricing for trie-size-dependent opcodes||Accepted (Istanbul)||Accepted in decision 68.2||Storage gas cost|
|EIP-1891||Contract-based Account Versioning||Rejected/Withdrawn (not proposed)||Superceded by 1702 (which is tentatively accepted (Berlin))||Account versioning|
|EIP-1930||CALLs with strict gas semantic. Revert if not enough gas available||Rejected/Withdrawn||-||Elliptic curve|
|EIP-1959||New Opcode to check if a chainID is part of the history of chainIDs||Withdrawn by Author in decision 64.1||Superceded by 1965 (which is rejected/withdrawn)||Chain metadata|
|EIP-1962||EC arithmetic and pairings with runtime definitions||Tentatively accepted (Berlin) in decision 66.5||-||Elliptic curve|
|EIP-1965||Method to check if a chainID is valid at a specific block Number||Rejected/Withdrawn||-||Chain metadata|
|EIP-1985||Sane limits for certain EVM parameters||Tentatively accepted (Berlin)||Tentatively accepted in decision 67.1||Independent|
|EIP-2014||Extended State Oracle||Rejected/Withdrawn||-||Chain metadata|
|EIP-2024||Proposal for supporting Blake2b and Blake2s||Rejected/Withdrawn (not proposed)||Accepted in decision 63.1, but then superceded by EIP-152||Elliptic curve|
|EIP-2025||Funding ETH1.X through a Developer Block Reward for 18 Months||Rejected/Withdrawn||Strong community resistance, concerns over governance mechanism and neutrality||Independent|
|EIP-2026||State Rent H - Fixed Prepayment for accounts||Rejected/Withdrawn||Not ready in time||State rent|
|EIP-2027||State Rent C - Net contract size accounting||Rejected/Withdrawn||Not ready in time||State rent|
|EIP-2028||Calldata gas cost reduction||Accepted (Istanbul)||Accepted in decision 66.5||Independent|
|EIP-2029||State Rent A - State counters contract||Rejected/Withdrawn||Not ready in time||State rent|
|EIP-2031||State Rent B - Net transaction counter||Rejected/Withdrawn||Not ready in time||State rent|
|EIP-2035||Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs||Rejected/Withdrawn||-||Storage gas cost|
|EIP-2045||add EIP for fractional gas costs||Tentatively accepted (Berlin)||Geth/Parity to be guided to implement EVM-One changes, benchmark and determine specific specific parameters for the EIP. Tentatively accepted in decision 67.1||Storage gas cost|
|EIP-2046||Reduced gas cost for static calls made to precompiles||Tentatively accepted (Berlin)||Tentatively accepted in decision 67.1||Elliptic curve|
|EIP-2200||Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change||Accepted (Istanbul)||Accepted in decision 66.2. Is an update version of (and replaces) 1283||Storage writing|
Some EIPs are complementary and some are mutually exclusive improvements that deprecate other proprosals. Below is a rough clustering to highlight these relationships.
To reduce the load on discussing each EIP independently in the dev calls, some EIP coordination happened in AllCoreDevs gitter here during the first week of June 2019.
The clusters (expanded below) were:
Link to Google Drawing here
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:
The next fork will be called Berlin and will primarily be composed of the EIPs that did not make it into Istanbul (those in the 'tentatively accepted' category).
The fork following Berlin 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.