Ethereum Activated Constantinople and St. Petersburg at Block 7,280,000

Ethereum’s Constantinople and St. Petersburg upgrades activated on the main network at block 7,280,000 on February 28, 2019, changing the rules followed by miners, nodes and smart-contract execution.

Contemporaneous monitoring reported the activation at 19:57 UTC and found no evidence, at that early observation point, of a chain split caused by a significant group continuing under the old rules. That was an important but limited finding: it showed that the scheduled transition appeared orderly immediately after the fork, not that every node had upgraded or that no defect could emerge later.

The event mattered beyond a routine software release. Ethereum required economically independent miners, exchanges, wallet providers and node operators to coordinate around one block height. It also changed miner compensation and delayed the network’s built-in “difficulty bomb,” while adding tools intended to make some smart-contract operations cheaper or more capable.

Two upgrades at one block

The paired name reflected the upgrade’s unusual path. Constantinople had been postponed in January 2019 after a security concern was identified in EIP-1283, a proposal that changed gas accounting for storage operations. By February 28, the original Constantinople rules had already reached several test networks, so developers scheduled St. Petersburg at the same mainnet block.

The Petersburg specification made the ordering explicit: when both rule sets applied at block 7,280,000, Petersburg took precedence and disabled EIP-1283. The published rationale identified a potential reentrancy attack vector. The event-day record therefore supports a narrower statement than “all of Constantinople launched.” Four Constantinople proposals took effect, while the disputed storage-metering proposal did not.

What changed

EIP-145 added native bit-shift instructions to the Ethereum Virtual Machine. The specification priced those instructions at 3 gas, compared with 35 gas for arithmetic implementations of two comparable shift operations. EIP-1052 added EXTCODEHASH, allowing a contract to obtain the hash of another account’s code without copying the full bytecode.

EIP-1014 introduced CREATE2. Its practical significance was deterministic contract addressing: participants could interact with, or make commitments involving, an address before the corresponding contract had been deployed, provided the specified creation code was later used. The proposal identified state-channel designs as an important use case.

EIP-1234 changed proof-of-work economics. It set the base block reward at 2 ETH and moved the difficulty bomb back by 5 million blocks, described in the proposal as roughly a 12-month delay. Relative to the prior 3 ETH base reward, the change was a one-third reduction. That calculation applies only to the protocol’s base reward per mined block; uncle rewards, nephew rewards, transaction fees and changing block intervals mean it should not be treated as a one-third measurement of total issuance over every time window.

Why the activation mattered

For developers, the fork expanded the virtual machine while demonstrating that a security-sensitive proposal could be removed before mainnet activation. For miners, it immediately altered revenue from the base reward and postponed the rising difficulty that threatened to slow block production. For markets and service providers, an orderly transition reduced the immediate operational risk of incompatible chains, frozen withdrawals or confused accounting.

The strongest event-day conclusion remains technical rather than predictive. Block 7,280,000 put the four retained changes into effect, and contemporaneous observers saw the canonical chain continue without an evident split in the first minutes. The record does not establish a lasting effect on ether’s price, usage or security, and no such causal claim is necessary to explain the upgrade’s importance.