Ethereum Sets Constantinople Instructions for Block 7,080,000

The Ethereum Foundation published operational instructions on January 11, 2019 for Constantinople, a backward-incompatible network upgrade then scheduled to activate at block 7,080,000. Developers estimated that the block would arrive on January 16, although the notice cautioned that variable block times could move activation one or two days in either direction.

The announcement mattered beyond software maintenance. Constantinople combined five Ethereum Improvement Proposals affecting smart-contract execution, storage pricing, future scaling techniques, mining difficulty and ether issuance. Because the new rules would begin at a predetermined block height, miners, exchanges and other node operators needed compatible software before the network reached that point.

Operators faced a coordination deadline

The Foundation directed operators toward Geth 1.8.20, Parity 2.1.11-stable, Harmony 2.3 Build 72, Pantheon 0.8.3 and Trinity 0.1.0-alpha.20, among other listed releases. Ordinary ether holders using exchanges, hosted wallets, mobile wallets or hardware wallets were told that no action was required unless their service provider issued separate instructions.

The distinction reflected how a protocol fork works. Nodes enforcing the old rules would continue following a pre-upgrade chain after block 7,080,000, leaving them incompatible with nodes enforcing Constantinople. The announcement therefore represented a request for coordinated adoption, not proof that every operator had already updated or that activation was guaranteed to proceed without incident.

CoinDesk’s January 11 reporting described cautious optimism among developers and miners while emphasizing the risks inherent in a system-wide change. Its reporting supported the existence of operational preparation and debate, but estimates of node readiness were contested and did not constitute a complete census of economically significant infrastructure.

Five proposals changed code and economics

Three proposals focused on execution capabilities. EIP-145 added native bitwise-shift instructions at a stated cost of 3 gas instead of the 35 gas needed for arithmetic implementations. EIP-1052 introduced `EXTCODEHASH`, allowing contracts to retrieve a hash of another contract’s code without copying the complete bytecode. EIP-1014 introduced `CREATE2`, permitting a contract address to be calculated from specified inputs before code was deployed there, an important building block for counterfactual state-channel designs.

EIP-1283 proposed net gas metering for `SSTORE`, the operation used to modify contract storage. Its aim was to align charges more closely with the storage work actually performed and enable coding patterns that existing gas costs made uneconomic.

EIP-1234 carried the clearest monetary consequence. Its specification delayed Ethereum’s difficulty bomb by approximately 12 months and reduced the base block reward from 3 ETH to 2 ETH, with uncle and nephew rewards adjusted accordingly. The base-reward change was a one-third reduction per block. It was not necessarily a one-third reduction in total issuance over a calendar period because realized issuance also depended on block frequency and uncle production.

What January 11 established

The verified event was the publication of a concrete activation plan and operator instructions. It did not establish that Constantinople had activated, that every node was ready, or that the proposals would produce particular market prices, application usage or security outcomes. No price claim is necessary to explain the importance of changing the consensus rules and miner compensation of a major public blockchain.

Later context, clearly separated

On January 15, 2019, after the event-date record, Ethereum developers postponed the planned activation following disclosure of a potential reentrancy risk associated with EIP-1283. That later intervention does not erase the significance of the January 11 instructions; it demonstrates why the announcement’s warnings about unexpected bugs and coordinated client updates were material. The postponement is included only to prevent readers from mistaking the January 11 plan for a completed January 16 activation.