Ethereum’s Istanbul hard fork is sometimes remembered through early reports about one or two proposed code changes. The finalized upgrade was broader. When Istanbul activated on mainnet at block 9,069,000 in December 2019, its canonical specification included six Ethereum Improvement Proposals (EIPs) affecting interoperability, gas pricing, calldata and storage accounting.
The final Istanbul package
EIP-1679 is the hard-fork meta-specification. It lists the proposals that reached activation: EIP-152, EIP-1108, EIP-1344, EIP-1884, EIP-2028 and EIP-2200. Earlier discussions and approvals were part of the process, but they should not be confused with the final protocol package.
EIP-152: BLAKE2 compression function
EIP-152 added a precompiled contract for the BLAKE2b compression function. The practical goal was interoperability with systems that use BLAKE2-based constructions, including privacy-focused protocols. A precompile lets contracts use a defined operation without implementing the entire primitive inefficiently in EVM bytecode.
EIP-1108: lower alt_bn128 precompile costs
This proposal reduced gas costs for elliptic-curve operations using alt_bn128. Those operations are important for some zero-knowledge proof systems. Lower, better-calibrated costs made privacy and scaling constructions less expensive to verify on Ethereum without changing what the cryptography itself guarantees.
EIP-1344: the ChainID opcode
EIP-1344 introduced an opcode that lets a contract obtain the chain identifier. Contracts could use that value when constructing domain-separated signatures or validating assumptions about the chain where they were executing. It addressed a practical gap between transaction-level replay protection and contract-level access to chain identity.
EIP-1884: repricing state-dependent operations
EIP-1884 increased the gas cost of several opcodes whose real resource burden had grown as Ethereum’s state expanded. The change illustrated an important property of protocol maintenance: gas prices are not promises that an operation will remain equally cheap forever.
The repricing also created compatibility risk. Contracts that assumed a fixed 2,300-gas stipend could be affected when a fallback path performed newly expensive operations. That is why hard-fork analysis has to consider deployed application behavior, not only node software.
EIP-2028: cheaper transaction calldata
EIP-2028 reduced the gas charged for non-zero bytes in transaction calldata. Cheaper data availability was particularly relevant to scaling systems that post compressed transaction data to Ethereum. The trade-off required analysis because larger blocks of data can affect propagation and network security.
EIP-2200: structured SSTORE metering
EIP-2200 revised gas accounting for the SSTORE operation, including rules for net metering and refunds when storage changes during a transaction. The proposal aimed to provide a structured basis for storage-cost behavior while enabling patterns such as reentrancy locks more efficiently.
Why the historical detail matters
Protocol upgrades move through discussion, draft specifications, client implementation, testnets and final activation. A report published in the middle of that process can be accurate about a meeting yet incomplete as a description of what ultimately changed on mainnet.
Istanbul also shows why developers should read the final meta-EIP and the individual specifications. Labels such as “performance upgrade” hide different security and compatibility consequences. Gas repricing may break assumptions; lower cryptographic costs may enable new applications; cheaper calldata may affect scaling economics.
For a wider introduction to runtime and tooling choices, see our guide to smart-contract programming languages. Istanbul is historical, but its lesson remains current: application developers need to track protocol specifications rather than treating deployed EVM behavior as immutable.
This retrospective reconstructs the historical URL from final primary specifications. It does not reuse the removed article and does not imply that Istanbul’s 2019 parameters describe Ethereum’s current protocol.
